subject:"2.6.21\-rc6\-mm1"

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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 ? )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-28 Thread 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 0x. 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-28 Thread 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 0x. 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-28 Thread 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/[EMAIL PROTECTED]/msg38200.html


- Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-28 Thread 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/[EMAIL PROTECTED]/msg38200.html


- Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-28 Thread 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 0x. 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-28 Thread 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 0x. 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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 ? )
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-27 Thread 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

On Fri, 27 Apr 2007 23:04:58 +0200
Helge Hafting <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 27, 2007 at 12:39:19AM +0200, Jiri Kosina wrote:
> > On Fri, 27 Apr 2007, Helge Hafting wrote:
> > 
> > > 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
> > > the machine tends to hang after some minutes work in X.  That hang is 
> > > unusual in that moving the mouse still move the X cursor, but everything 
> > > else stops and sysrq fails me. But that is another story.
> > [...]
> > > The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
> > 
> > Hi Helge,
> > 
> > thanks for the effort. If you take stock rc6-mm1 and revert just 
> > git-acpi.patch, doesn the machine behave correctly?
> 
> Just compiled & booted such a kernel - it came up fine!
> So it looks like USB is fine then, and the problem is in
> that ACPI patch.
> 

OK, thanks.  Len: we've established that 2.6.21-rc6-mm1's git-acpi.patch
causes this:

> 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - the
> machine tends to hang after some minutes work in X.  That hang is
> unusual in that moving the mouse still move the X cursor, but
> everything else stops and sysrq fails me. But that is another story.
> 
> rc6 boots, rc6-mm1 hangs at the "usbcore registered hiddev" message.
> Bisection:
> 1, 2, 3: the three first hangs at "usbcore registered hiddev"
> 4, 5, 6: the next three hangs at a message about ACPI  PCI[A]->IRQ17
> I decided to keep bisecting these hangers as "bad", I don't really know
> if this could be the same thing or completely different issues.  If they are
> different, then one problem will mask the other anyway, so
> calling every hanging kernel "bad" will at least find the first broken 
> patch.
> 7: boots up ok!
> 8,9,10: hangs at the aboce mentioned ACPI message
> The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-27 Thread 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 <[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 )
>  But also a new problem with USB keyboard/mouse
> 
>  BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
> 
>  Call Trace:
>  [] usbhid_lookup_quirk+0x63/0xea
>  [] hid_probe+0x4d/0xbad
>  [] default_wake_function+0x0/0xe
>  [] sysfs_new_dirent+0x79/0xaa
>  [] usb_match_one_id+0x26/0x82
>  [] usb_probe_interface+0x7d/0xa5
>  [] driver_probe_device+0xf6/0x17f
>  [] __driver_attach+0x0/0x93
>  [] __driver_attach+0x5a/0x93
>  [] bus_for_each_dev+0x43/0x6e
>  [] bus_add_driver+0x7b/0x19d
>  [] usb_register_driver+0x7e/0xe1
>  [] hid_init+0x28/0x4e
>  [] kernel_init+0x162/0x2d2
>  [] child_rip+0xa/0x12
>  [] acpi_ds_init_one_object+0x0/0x7c
>  [] kernel_init+0x0/0x2d2
>  [] child_rip+0x0/0x12
> 
>  input: ServerEngines SE USB Device as 
>  /devices/pci:00/:00:1d.2/usb4/4-2/4-2:1.0/input/input2
>  input: USB HID v1.11 Keyboard [ServerEngines SE USB Device] on 
>  usb-:00:1d.2-2
>  BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
> 
>  Call Trace:
>  [] usbhid_lookup_quirk+0x63/0xea
>  [] hid_probe+0x4d/0xbad
>  [] sysfs_new_dirent+0x79/0xaa
>  [] usb_match_one_id+0x26/0x82
>  [] usb_probe_interface+0x7d/0xa5
>  [] driver_probe_device+0xf6/0x17f
>  [] __driver_attach+0x0/0x93
>  [] __driver_attach+0x5a/0x93
>  [] bus_for_each_dev+0x43/0x6e
>  [] bus_add_driver+0x7b/0x19d
>  [] usb_register_driver+0x7e/0xe1
>  [] hid_init+0x28/0x4e
>  [] kernel_init+0x162/0x2d2
>  [] child_rip+0xa/0x12
>  [] acpi_ds_init_one_object+0x0/0x7c
>  [] kernel_init+0x0/0x2d2
>  [] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

2007-04-27 Thread Helge Hafting

On Fri, Apr 27, 2007 at 12:39:19AM +0200, Jiri Kosina wrote:
> On Fri, 27 Apr 2007, Helge Hafting wrote:
> 
> > 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
> > the machine tends to hang after some minutes work in X.  That hang is 
> > unusual in that moving the mouse still move the X cursor, but everything 
> > else stops and sysrq fails me. But that is another story.
> [...]
> > The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch
> 
> Hi Helge,
> 
> thanks for the effort. If you take stock rc6-mm1 and revert just 
> git-acpi.patch, doesn the machine behave correctly?

Just compiled & booted such a kernel - it came up fine!
So it looks like USB is fine then, and the problem is in
that ACPI patch.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-27 Thread VE \(HOME\)


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 )

But also a new problem with USB keyboard/mouse

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

Call Trace:
[] usbhid_lookup_quirk+0x63/0xea
[] hid_probe+0x4d/0xbad
[] default_wake_function+0x0/0xe
[] sysfs_new_dirent+0x79/0xaa
[] usb_match_one_id+0x26/0x82
[] usb_probe_interface+0x7d/0xa5
[] driver_probe_device+0xf6/0x17f
[] __driver_attach+0x0/0x93
[] __driver_attach+0x5a/0x93
[] bus_for_each_dev+0x43/0x6e
[] bus_add_driver+0x7b/0x19d
[] usb_register_driver+0x7e/0xe1
[] hid_init+0x28/0x4e
[] kernel_init+0x162/0x2d2
[] child_rip+0xa/0x12
[] acpi_ds_init_one_object+0x0/0x7c
[] kernel_init+0x0/0x2d2
[] child_rip+0x0/0x12

input: ServerEngines SE USB Device as 
/devices/pci:00/:00:1d.2/usb4/4-2/4-2:1.0/input/input2
input: USB HID v1.11 Keyboard [ServerEngines SE USB Device] on 
usb-:00:1d.2-2

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

Call Trace:
[] usbhid_lookup_quirk+0x63/0xea
[] hid_probe+0x4d/0xbad
[] sysfs_new_dirent+0x79/0xaa
[] usb_match_one_id+0x26/0x82
[] usb_probe_interface+0x7d/0xa5
[] driver_probe_device+0xf6/0x17f
[] __driver_attach+0x0/0x93
[] __driver_attach+0x5a/0x93
[] bus_for_each_dev+0x43/0x6e
[] bus_add_driver+0x7b/0x19d
[] usb_register_driver+0x7e/0xe1
[] hid_init+0x28/0x4e
[] kernel_init+0x162/0x2d2
[] child_rip+0xa/0x12
[] acpi_ds_init_one_object+0x0/0x7c
[] kernel_init+0x0/0x2d2
[] 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 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-27 Thread VE \(HOME\)


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 )

But also a new problem with USB keyboard/mouse

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

Call Trace:
[8044bbcb] usbhid_lookup_quirk+0x63/0xea
[8044ab12] hid_probe+0x4d/0xbad
[8021d7cd] default_wake_function+0x0/0xe
[8029d0b6] sysfs_new_dirent+0x79/0xaa
[80403411] usb_match_one_id+0x26/0x82
[80403fe6] usb_probe_interface+0x7d/0xa5
[80391cb9] driver_probe_device+0xf6/0x17f
[80391de4] __driver_attach+0x0/0x93
[80391e3e] __driver_attach+0x5a/0x93
[8039110c] bus_for_each_dev+0x43/0x6e
[80391433] bus_add_driver+0x7b/0x19d
[80403b06] usb_register_driver+0x7e/0xe1
[8064d2d3] hid_init+0x28/0x4e
[8063460b] kernel_init+0x162/0x2d2
[8020a338] child_rip+0xa/0x12
[80343d5c] acpi_ds_init_one_object+0x0/0x7c
[806344a9] kernel_init+0x0/0x2d2
[8020a32e] child_rip+0x0/0x12

input: ServerEngines SE USB Device as 
/devices/pci:00/:00:1d.2/usb4/4-2/4-2:1.0/input/input2
input: USB HID v1.11 Keyboard [ServerEngines SE USB Device] on 
usb-:00:1d.2-2

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

Call Trace:
[8044bbcb] usbhid_lookup_quirk+0x63/0xea
[8044ab12] hid_probe+0x4d/0xbad
[8029d0b6] sysfs_new_dirent+0x79/0xaa
[80403411] usb_match_one_id+0x26/0x82
[80403fe6] usb_probe_interface+0x7d/0xa5
[80391cb9] driver_probe_device+0xf6/0x17f
[80391de4] __driver_attach+0x0/0x93
[80391e3e] __driver_attach+0x5a/0x93
[8039110c] bus_for_each_dev+0x43/0x6e
[80391433] bus_add_driver+0x7b/0x19d
[80403b06] usb_register_driver+0x7e/0xe1
[8064d2d3] hid_init+0x28/0x4e
[8063460b] kernel_init+0x162/0x2d2
[8020a338] child_rip+0xa/0x12
[80343d5c] acpi_ds_init_one_object+0x0/0x7c
[806344a9] kernel_init+0x0/0x2d2
[8020a32e] 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 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

2007-04-27 Thread Helge Hafting

On Fri, Apr 27, 2007 at 12:39:19AM +0200, Jiri Kosina wrote:
 On Fri, 27 Apr 2007, Helge Hafting wrote:
 
  2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
  the machine tends to hang after some minutes work in X.  That hang is 
  unusual in that moving the mouse still move the X cursor, but everything 
  else stops and sysrq fails me. But that is another story.
 [...]
  The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch
 
 Hi Helge,
 
 thanks for the effort. If you take stock rc6-mm1 and revert just 
 git-acpi.patch, doesn the machine behave correctly?

Just compiled  booted such a kernel - it came up fine!
So it looks like USB is fine then, and the problem is in
that ACPI patch.

Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-27 Thread 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 [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 )
  But also a new problem with USB keyboard/mouse
 
  BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
 
  Call Trace:
  [8044bbcb] usbhid_lookup_quirk+0x63/0xea
  [8044ab12] hid_probe+0x4d/0xbad
  [8021d7cd] default_wake_function+0x0/0xe
  [8029d0b6] sysfs_new_dirent+0x79/0xaa
  [80403411] usb_match_one_id+0x26/0x82
  [80403fe6] usb_probe_interface+0x7d/0xa5
  [80391cb9] driver_probe_device+0xf6/0x17f
  [80391de4] __driver_attach+0x0/0x93
  [80391e3e] __driver_attach+0x5a/0x93
  [8039110c] bus_for_each_dev+0x43/0x6e
  [80391433] bus_add_driver+0x7b/0x19d
  [80403b06] usb_register_driver+0x7e/0xe1
  [8064d2d3] hid_init+0x28/0x4e
  [8063460b] kernel_init+0x162/0x2d2
  [8020a338] child_rip+0xa/0x12
  [80343d5c] acpi_ds_init_one_object+0x0/0x7c
  [806344a9] kernel_init+0x0/0x2d2
  [8020a32e] child_rip+0x0/0x12
 
  input: ServerEngines SE USB Device as 
  /devices/pci:00/:00:1d.2/usb4/4-2/4-2:1.0/input/input2
  input: USB HID v1.11 Keyboard [ServerEngines SE USB Device] on 
  usb-:00:1d.2-2
  BUG: at drivers/hid/usbhid/hid-quirks.c:480 usbhid_exists_dquirk()
 
  Call Trace:
  [8044bbcb] usbhid_lookup_quirk+0x63/0xea
  [8044ab12] hid_probe+0x4d/0xbad
  [8029d0b6] sysfs_new_dirent+0x79/0xaa
  [80403411] usb_match_one_id+0x26/0x82
  [80403fe6] usb_probe_interface+0x7d/0xa5
  [80391cb9] driver_probe_device+0xf6/0x17f
  [80391de4] __driver_attach+0x0/0x93
  [80391e3e] __driver_attach+0x5a/0x93
  [8039110c] bus_for_each_dev+0x43/0x6e
  [80391433] bus_add_driver+0x7b/0x19d
  [80403b06] usb_register_driver+0x7e/0xe1
  [8064d2d3] hid_init+0x28/0x4e
  [8063460b] kernel_init+0x162/0x2d2
  [8020a338] child_rip+0xa/0x12
  [80343d5c] acpi_ds_init_one_object+0x0/0x7c
  [806344a9] kernel_init+0x0/0x2d2
  [8020a32e] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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;
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

On Fri, 27 Apr 2007 23:04:58 +0200
Helge Hafting [EMAIL PROTECTED] wrote:

 On Fri, Apr 27, 2007 at 12:39:19AM +0200, Jiri Kosina wrote:
  On Fri, 27 Apr 2007, Helge Hafting wrote:
  
   2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
   the machine tends to hang after some minutes work in X.  That hang is 
   unusual in that moving the mouse still move the X cursor, but everything 
   else stops and sysrq fails me. But that is another story.
  [...]
   The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch
  
  Hi Helge,
  
  thanks for the effort. If you take stock rc6-mm1 and revert just 
  git-acpi.patch, doesn the machine behave correctly?
 
 Just compiled  booted such a kernel - it came up fine!
 So it looks like USB is fine then, and the problem is in
 that ACPI patch.
 

OK, thanks.  Lenco: we've established that 2.6.21-rc6-mm1's git-acpi.patch
causes this:

 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - the
 machine tends to hang after some minutes work in X.  That hang is
 unusual in that moving the mouse still move the X cursor, but
 everything else stops and sysrq fails me. But that is another story.
 
 rc6 boots, rc6-mm1 hangs at the usbcore registered hiddev message.
 Bisection:
 1, 2, 3: the three first hangs at usbcore registered hiddev
 4, 5, 6: the next three hangs at a message about ACPI  PCI[A]-IRQ17
 I decided to keep bisecting these hangers as bad, I don't really know
 if this could be the same thing or completely different issues.  If they are
 different, then one problem will mask the other anyway, so
 calling every hanging kernel bad will at least find the first broken 
 patch.
 7: boots up ok!
 8,9,10: hangs at the aboce mentioned ACPI message
 The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch
 
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-27 Thread 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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 jupiter2   [] 
> inetdev_event+0x48/0x283
>   Apr 26 11:09:34 jupiter2 [] 
> _spin_lock_bh+0x9/0x19
>   Apr 26 11:09:34 jupiter2 [] 
> rt_run_flush+0x7e/0xaf
>   Apr 26 11:09:34 jupiter2 [] 
> notifier_call_chain+0x29/0x56 
>   Apr 26 11:09:34 jupiter2 [] 
> dev_set_mac_address+0x53/0x59 
>   Apr 26 11:09:34 jupiter2 [] 
> bo

This was due to locking bustage in the net tree.  It should be fixed in 
2.6.21-rc7-mm2.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

On Fri, 27 Apr 2007 00:39:19 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> wrote:

> On Fri, 27 Apr 2007, Helge Hafting wrote:
> 
> > 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
> > the machine tends to hang after some minutes work in X.  That hang is 
> > unusual in that moving the mouse still move the X cursor, but everything 
> > else stops and sysrq fails me. But that is another story.
> [...]
> > The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch

linux-acpi: we have a problem.

> Hi Helge,
> 
> thanks for the effort. If you take stock rc6-mm1 and revert just 
> git-acpi.patch, doesn the machine behave correctly?
> 

It would be easier and would produce a clearer result to test just

2.6.21-rc7
+   2.6.21-rc7-mm2's origin.patch
+   2.6.21-rc7-mm2's acpi.patch

from
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

2007-04-26 Thread Jiri Kosina

On Fri, 27 Apr 2007, Helge Hafting wrote:

> 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
> the machine tends to hang after some minutes work in X.  That hang is 
> unusual in that moving the mouse still move the X cursor, but everything 
> else stops and sysrq fails me. But that is another story.
[...]
> The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch

Hi Helge,

thanks for the effort. If you take stock rc6-mm1 and revert just 
git-acpi.patch, doesn the machine behave correctly?

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result


Jiri Kosina wrote:

On Wed, 25 Apr 2007, Helge Hafting wrote:
  


I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is 
good.  It boots up without hanging, and my USB devices works too. Should 
I test rc7-mm1 then?



That would also be useful.

But really identifying offending patch using bisection would help most. 
And it should be pretty easy and not too much time consuming for you, as 
the bug triggers immediately upon boot in your case.
  

2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - the
machine tends to hang after some minutes work in X.  That hang is
unusual in that moving the mouse still move the X cursor, but
everything else stops and sysrq fails me. But that is another story.

rc6 boots, rc6-mm1 hangs at the "usbcore registered hiddev" message.
Bisection:
1, 2, 3: the three first hangs at "usbcore registered hiddev"
4, 5, 6: the next three hangs at a message about ACPI  PCI[A]->IRQ17
I decided to keep bisecting these hangers as "bad", I don't really know
if this could be the same thing or completely different issues.  If they are
different, then one problem will mask the other anyway, so
calling every hanging kernel "bad" will at least find the first broken 
patch.

7: boots up ok!
8,9,10: hangs at the aboce mentioned ACPI message
The (first) "hanging" patch in 2.6.21-rc6-mm1 is: git-acpi.patch

Helge Hafting








-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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
> >>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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-26 Thread Jay Vosburgh

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 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-26 Thread 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 ([EMAIL PROTECTED]) (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   [] 
inetdev_event+0x48/0x283

Apr 26 11:09:34 jupiter2 [] 
_spin_lock_bh+0x9/0x19
Apr 26 11:09:34 jupiter2 [] 
rt_run_flush+0x7e/0xaf
		Apr 26 11:09:34 jupiter2 [] notifier_call_chain+0x29/0x56 
		Apr 26 11:09:34 jupiter2 [] dev_set_mac_address+0x53/0x59 			
		Apr 26 11:09:34 jupiter2 [] 
bonding:alb_set_slave_mac_addr+0x41/0x6c
		Apr 26 11:09:34 jupiter2 [] 
bonding:alb_swap_mac_addr+0x91/0x165
		Apr 26 11:09:34 jupiter2 [] 
bonding:bond_change_active_slave+0x227/0x382

Apr 26 11:09:34 jupiter2 []
bonding:bond_select_active_slave+0xb7/0xe5
		Apr 26 11:09:34 jupiter2 [] 
bonding:bond_mii_monitor+0x3cd/0x41e
		Apr 26 11:09:34 jupiter2 [] 
bonding:bond_mii_monitor+0x0/0x41e

Apr 26 11:09:34 jupiter2 []
 run_timer_softirq+0x130/0x19f
		Apr 26 11:09:34 jupiter2[] __do_softirq+0x55/0xc4 
		Apr 26 11:09:34 jupiter2 [] call_softirq+0x1c/0x28

Apr 26 11:09:34 jupiter2 [] 
do_softirq+0x2c/0x7d
		Apr 26 11:09:34 jupiter2 [] 
smp_apic_timer_interrupt+0x49/0x5f

 Apr 26 11:09:34 jupiter2 [] 
mwait_idle+0x0/0x45
Apr 26 11:09:34 jupiter2 [] 
apic_timer_interrupt+0x66/0x70
		 Apr 26 11:09:34 jupiter2   [] mwait_idle+0x42/0x45 
		Apr 26 11:09:34 jupiter2 [] cpu_idle+0x51/0x70 
		Apr 26 11:09:34 jupiter2 [] start_kernel+0x242/0x24e

Apr 26 11:09:34 jupiter2 [] 
_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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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 ([EMAIL PROTECTED]) (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   [] 
inetdev_event+0x48/0x283
Apr 26 11:09:34 jupiter2 [] 
_spin_lock_bh+0x9/0x19
Apr 26 11:09:34 jupiter2 [] 
rt_run_flush+0x7e/0xaf
Apr 26 11:09:34 jupiter2 [] 
notifier_call_chain+0x29/0x56 
Apr 26 11:09:34 jupiter2 [] 
dev_set_mac_address+0x53/0x59 
Apr 26 11:09:34 jupiter2 [] 
bonding:alb_set_slave_mac_addr+0x41/0x6c
Apr 26 11:09:34 jupiter2 [] 
bonding:alb_swap_mac_addr+0x91/0x165
Apr 26 11:09:34 jupiter2 [] 
bonding:bond_change_active_slave+0x227/0x382
Apr 26 11:09:34 jupiter2 []
bonding:bond_select_active_slave+0xb7/0xe5
Apr 26 11:09:34 jupiter2 [] 
bonding:bond_mii_monitor+0x3cd/0x41e
Apr 26 11:09:34 jupiter2 [] 
bonding:bond_mii_monitor+0x0/0x41e
Apr 26 11:09:34 jupiter2 []
 run_timer_softirq+0x130/0x19f
Apr 26 11:09:34 jupiter2[] 
__do_softirq+0x55/0xc4 
Apr 26 11:09:34 jupiter2 [] 
call_softirq+0x1c/0x28
Apr 26 11:09:34 jupiter2 [] 
do_softirq+0x2c/0x7d
Apr 26 11:09:34 jupiter2 [] 
smp_apic_timer_interrupt+0x49/0x5f
 Apr 26 11:09:34 jupiter2 [] 
mwait_idle+0x0/0x45
Apr 26 11:09:34 jupiter2 [] 
apic_timer_interrupt+0x66/0x70
 Apr 26 11:09:34 jupiter2   [] 
mwait_idle+0x42/0x45 
Apr 26 11:09:34 jupiter2 [] 
cpu_idle+0x51/0x70 
Apr 26 11:09:34 jupiter2 [] 
start_kernel+0x242/0x24e
Apr 26 11:09:34 jupiter2 [] 
_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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang

I recompiled 2.6.21-rc6-mm1 from fresh sources.
It still hangs initializing USBm but this time your
patch applied.

I rebooted with your patch, and got:

Detailed lists of all the USB devices found
(printer,mouse,...)
Then usbcore registered various drivers, such as
usblp, usb-storage, libusual, usbserial, ipaq
These messages were intermixed with messages from
the md raid system initializing

The three last lines were:
sdhci: Secure digital host controller interface driver
sdhci: copyright Pierre Ossman
usbcore: registered new interface driver hiddev

And then the machine hung completely.  I'll have
a look at bisecting. :-(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang

I recompiled 2.6.21-rc6-mm1 from fresh sources.
It still hangs initializing USBm but this time your
patch applied.

I rebooted with your patch, and got:

Detailed lists of all the USB devices found
(printer,mouse,...)
Then usbcore registered various drivers, such as
usblp, usb-storage, libusual, usbserial, ipaq
These messages were intermixed with messages from
the md raid system initializing

The three last lines were:
sdhci: Secure digital host controller interface driver
sdhci: copyright Pierre Ossman
usbcore: registered new interface driver hiddev

And then the machine hung completely.  I'll have
a look at bisecting. :-(
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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 ([EMAIL PROTECTED]) (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  [8049b49e] 
inetdev_event+0x48/0x283
Apr 26 11:09:34 jupiter2 [804c8731] 
_spin_lock_bh+0x9/0x19
Apr 26 11:09:34 jupiter2 [80473df1] 
rt_run_flush+0x7e/0xaf
Apr 26 11:09:34 jupiter2 [8022bdd0] 
notifier_call_chain+0x29/0x56 
Apr 26 11:09:34 jupiter2 [804560cc] 
dev_set_mac_address+0x53/0x59 
Apr 26 11:09:34 jupiter2 [88006d8d] 
bonding:alb_set_slave_mac_addr+0x41/0x6c
Apr 26 11:09:34 jupiter2 [88007215] 
bonding:alb_swap_mac_addr+0x91/0x165
Apr 26 11:09:34 jupiter2 [88002029] 
bonding:bond_change_active_slave+0x227/0x382
Apr 26 11:09:34 jupiter2 [880024c9]
bonding:bond_select_active_slave+0xb7/0xe5
Apr 26 11:09:34 jupiter2 [88004182] 
bonding:bond_mii_monitor+0x3cd/0x41e
Apr 26 11:09:34 jupiter2 [88003db5] 
bonding:bond_mii_monitor+0x0/0x41e
Apr 26 11:09:34 jupiter2 [80228714]
 run_timer_softirq+0x130/0x19f
Apr 26 11:09:34 jupiter2[8022618a] 
__do_softirq+0x55/0xc4 
Apr 26 11:09:34 jupiter2 [8020a5ac] 
call_softirq+0x1c/0x28
Apr 26 11:09:34 jupiter2 [8020bead] 
do_softirq+0x2c/0x7d
Apr 26 11:09:34 jupiter2 [80213b2a] 
smp_apic_timer_interrupt+0x49/0x5f
 Apr 26 11:09:34 jupiter2 [802088a3] 
mwait_idle+0x0/0x45
Apr 26 11:09:34 jupiter2 [8020a056] 
apic_timer_interrupt+0x66/0x70
 Apr 26 11:09:34 jupiter2 EOI  [802088e5] 
mwait_idle+0x42/0x45 
Apr 26 11:09:34 jupiter2 [8020883f] 
cpu_idle+0x51/0x70 
Apr 26 11:09:34 jupiter2 [806369bd] 
start_kernel+0x242/0x24e
Apr 26 11:09:34 jupiter2 [80636146] 
_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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-26 Thread 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 ([EMAIL PROTECTED]) (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  [8049b49e] 
inetdev_event+0x48/0x283

Apr 26 11:09:34 jupiter2 [804c8731] 
_spin_lock_bh+0x9/0x19
Apr 26 11:09:34 jupiter2 [80473df1] 
rt_run_flush+0x7e/0xaf
		Apr 26 11:09:34 jupiter2 [8022bdd0] notifier_call_chain+0x29/0x56 
		Apr 26 11:09:34 jupiter2 [804560cc] dev_set_mac_address+0x53/0x59 			
		Apr 26 11:09:34 jupiter2 [88006d8d] 
bonding:alb_set_slave_mac_addr+0x41/0x6c
		Apr 26 11:09:34 jupiter2 [88007215] 
bonding:alb_swap_mac_addr+0x91/0x165
		Apr 26 11:09:34 jupiter2 [88002029] 
bonding:bond_change_active_slave+0x227/0x382

Apr 26 11:09:34 jupiter2 [880024c9]
bonding:bond_select_active_slave+0xb7/0xe5
		Apr 26 11:09:34 jupiter2 [88004182] 
bonding:bond_mii_monitor+0x3cd/0x41e
		Apr 26 11:09:34 jupiter2 [88003db5] 
bonding:bond_mii_monitor+0x0/0x41e

Apr 26 11:09:34 jupiter2 [80228714]
 run_timer_softirq+0x130/0x19f
		Apr 26 11:09:34 jupiter2[8022618a] __do_softirq+0x55/0xc4 
		Apr 26 11:09:34 jupiter2 [8020a5ac] call_softirq+0x1c/0x28

Apr 26 11:09:34 jupiter2 [8020bead] 
do_softirq+0x2c/0x7d
		Apr 26 11:09:34 jupiter2 [80213b2a] 
smp_apic_timer_interrupt+0x49/0x5f

 Apr 26 11:09:34 jupiter2 [802088a3] 
mwait_idle+0x0/0x45
Apr 26 11:09:34 jupiter2 [8020a056] 
apic_timer_interrupt+0x66/0x70
		 Apr 26 11:09:34 jupiter2 EOI  [802088e5] mwait_idle+0x42/0x45 
		Apr 26 11:09:34 jupiter2 [8020883f] cpu_idle+0x51/0x70 
		Apr 26 11:09:34 jupiter2 [806369bd] start_kernel+0x242/0x24e

Apr 26 11:09:34 jupiter2 [80636146] 
_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


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2007-04-26 Thread Jay Vosburgh

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 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 [EMAIL PROTECTED] 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, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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
 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 [EMAIL PROTECTED] 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, [EMAIL PROTECTED]
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 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,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result


Jiri Kosina wrote:

On Wed, 25 Apr 2007, Helge Hafting wrote:
  


I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is 
good.  It boots up without hanging, and my USB devices works too. Should 
I test rc7-mm1 then?



That would also be useful.

But really identifying offending patch using bisection would help most. 
And it should be pretty easy and not too much time consuming for you, as 
the bug triggers immediately upon boot in your case.
  

2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - the
machine tends to hang after some minutes work in X.  That hang is
unusual in that moving the mouse still move the X cursor, but
everything else stops and sysrq fails me. But that is another story.

rc6 boots, rc6-mm1 hangs at the usbcore registered hiddev message.
Bisection:
1, 2, 3: the three first hangs at usbcore registered hiddev
4, 5, 6: the next three hangs at a message about ACPI  PCI[A]-IRQ17
I decided to keep bisecting these hangers as bad, I don't really know
if this could be the same thing or completely different issues.  If they are
different, then one problem will mask the other anyway, so
calling every hanging kernel bad will at least find the first broken 
patch.

7: boots up ok!
8,9,10: hangs at the aboce mentioned ACPI message
The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch

Helge Hafting








-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

2007-04-26 Thread Jiri Kosina

On Fri, 27 Apr 2007, Helge Hafting wrote:

 2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
 the machine tends to hang after some minutes work in X.  That hang is 
 unusual in that moving the mouse still move the X cursor, but everything 
 else stops and sysrq fails me. But that is another story.
[...]
 The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch

Hi Helge,

thanks for the effort. If you take stock rc6-mm1 and revert just 
git-acpi.patch, doesn the machine behave correctly?

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang - bisection result

On Fri, 27 Apr 2007 00:39:19 +0200 (CEST) Jiri Kosina [EMAIL PROTECTED] wrote:

 On Fri, 27 Apr 2007, Helge Hafting wrote:
 
  2.6.21-rc6 boots up fine.  Both rc6 and rc7 has a different problem - 
  the machine tends to hang after some minutes work in X.  That hang is 
  unusual in that moving the mouse still move the X cursor, but everything 
  else stops and sysrq fails me. But that is another story.
 [...]
  The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch

linux-acpi: we have a problem.

 Hi Helge,
 
 thanks for the effort. If you take stock rc6-mm1 and revert just 
 git-acpi.patch, doesn the machine behave correctly?
 

It would be easier and would produce a clearer result to test just

2.6.21-rc7
+   2.6.21-rc7-mm2's origin.patch
+   2.6.21-rc7-mm2's acpi.patch

from
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

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 jupiter2 IRQ  [8049b49e] 
 inetdev_event+0x48/0x283
   Apr 26 11:09:34 jupiter2 [804c8731] 
 _spin_lock_bh+0x9/0x19
   Apr 26 11:09:34 jupiter2 [80473df1] 
 rt_run_flush+0x7e/0xaf
   Apr 26 11:09:34 jupiter2 [8022bdd0] 
 notifier_call_chain+0x29/0x56 
   Apr 26 11:09:34 jupiter2 [804560cc] 
 dev_set_mac_address+0x53/0x59 
   Apr 26 11:09:34 jupiter2 [88006d8d] 
 bo

This was due to locking bustage in the net tree.  It should be fixed in 
2.6.21-rc7-mm2.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: start_udev and devpts [Re: 2.6.21-rc6-mm1]

On Wed, 25 Apr 2007 23:39:54 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote:

> On Wed, 25 Apr 2007 22:50:39 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
...
> 
> But I think I found the problem.
> In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked
> fine again.
> I'll dig mandrivas rc's to check this...
> 
> Anyways, I see no plain 'mount' command in /sbin/start_udev, all are 
> 'mount --move' commands. So I think it supposes is already mounted and
> tries to move it.
> 

As a (in)famous last work, I think Unix98 PTYs really don't like mount --move
for /dev/pts. If I mount it manually after boot, everything works fine.

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

start_udev and devpts [Re: 2.6.21-rc6-mm1]

On Wed, 25 Apr 2007 22:50:39 +0200, "J.A. Magallón" <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 24 Apr 2007 15:43:21 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> 
> > wrote:
> > 
> > > On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> 
> > > wrote:
> > > 
> > > > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> 
> > > > wrote:
> > > > 
> > > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> 
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > > > > > 
> > > > > > 
> > > > > > - Lots of x86 updates
> > > > > > 
> > > > > 
> > > > > Has somthing related with PTY's changed in this kernel ?
> > > > 
> > > > Not as far as I know, but there were some kobject_uevent changes which
> > > > might have caused udev upcalls to break.  Perhaps.
> > > > 
> > > > > I have to enable legacy PTY handling in a couple boxes to get ssh 
> > > > > working.
> > > > > If not, I had openpty() errors and nor sshd nor virtual terminals 
> > > > > (aterm) were
> > > > > able to get a terminal.
> > > > 
> > > > I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
> > > > works OK here.
> > > > 
> > > > > User space (udev) is the same in three boxes and one works and two 
> > > > > fail.
> > > > > I had /dev/ptmx everywhere and /dev/pts mounted
> > > > > 
> > > > > Any idea ?
> > > > 
> > > > Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If 
> > > > so,
> > > > it might have been the kobject_uevent thing.
> > > > 
> > > 
> > > I will, thanks.
> > > 
> > > A couple questions (as far as udev behaviour is sooo distro 
> > > dependent):
> > > - What should I have in /dev if I don't use legacy ptys ? As I understand
> > >   it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?
> > 
> > My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of
> > /dev/tty0 through /dev/tty63 and no /dev/pty*.
> > 
> > I'm not sure where all the /dev/tty*'s came from - perhaps a static udev
> > rule?
> >
> 
> Uh ?
> From the Kconfig help fot UNIX98_PTYS:
> 
> Linux has traditionally used the BSD-like names /dev/ptyxx for
> masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
> has a number of problems. The GNU C library glibc 2.1 and later,
> however, supports the Unix98 naming standard: in order to acquire a
> pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
> terminal is then made available to the process and the pseudo
> terminal slave can be accessed as /dev/pts/. What was
> traditionally /dev/ttyp2 will then be /dev/pts/2, for example.
> 
> So if all userspace is Unix98-aware, you just would be done with
> /dev/ptmx and /dev/pts/*. In your setup it looks like you are not able
> to use Unix98 PTYs, but as udev has created tty* things work.
> Or not ?
> 
> > > - If my setup, for whatever strange reasons has /dev/tty* stored anyware
> > >   (/dev/.udev, links.conf...) and they get created, I supose that opening
> > >   /dev/tty will give a ENODEV ?
> > 
> > well, /dev/tty is attached to your current tty and /dev/tty2 will get you
> > talking to the second VT.  I can't immediately thing what /dev/tty22 is
> > attached to.
> > 
> 
> I supposed it was something like you always opened /dev/tty but kernel+glibc
> redirect you to /dev/ttyXX, that is your _real_ terminal.
> I will try to check docs...
> 

Oops, no, /dev/tty?? are for virtual consoles.

But I think I found the problem.
In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked
fine again.
I'll dig mandrivas rc's to check this...

Anyways, I see no plain 'mount' command in /sbin/start_udev, all are 
'mount --move' commands. So I think it supposes is already mounted and
tries to move it.

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Apr 2007 15:43:21 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > 
> > > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> 
> > > wrote:
> > > 
> > > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> 
> > > > wrote:
> > > > 
> > > > > 
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > > > > 
> > > > > 
> > > > > - Lots of x86 updates
> > > > > 
> > > > 
> > > > Has somthing related with PTY's changed in this kernel ?
> > > 
> > > Not as far as I know, but there were some kobject_uevent changes which
> > > might have caused udev upcalls to break.  Perhaps.
> > > 
> > > > I have to enable legacy PTY handling in a couple boxes to get ssh 
> > > > working.
> > > > If not, I had openpty() errors and nor sshd nor virtual terminals 
> > > > (aterm) were
> > > > able to get a terminal.
> > > 
> > > I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
> > > works OK here.
> > > 
> > > > User space (udev) is the same in three boxes and one works and two fail.
> > > > I had /dev/ptmx everywhere and /dev/pts mounted
> > > > 
> > > > Any idea ?
> > > 
> > > Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
> > > it might have been the kobject_uevent thing.
> > > 
> > 
> > I will, thanks.
> > 
> > A couple questions (as far as udev behaviour is sooo distro dependent):
> > - What should I have in /dev if I don't use legacy ptys ? As I understand
> >   it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?
> 
> My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of
> /dev/tty0 through /dev/tty63 and no /dev/pty*.
> 
> I'm not sure where all the /dev/tty*'s came from - perhaps a static udev
> rule?
>

Uh ?
>From the Kconfig help fot UNIX98_PTYS:

Linux has traditionally used the BSD-like names /dev/ptyxx for
masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
has a number of problems. The GNU C library glibc 2.1 and later,
however, supports the Unix98 naming standard: in order to acquire a
pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
terminal is then made available to the process and the pseudo
terminal slave can be accessed as /dev/pts/. What was
traditionally /dev/ttyp2 will then be /dev/pts/2, for example.

So if all userspace is Unix98-aware, you just would be done with
/dev/ptmx and /dev/pts/*. In your setup it looks like you are not able
to use Unix98 PTYs, but as udev has created tty* things work.
Or not ?

> > - If my setup, for whatever strange reasons has /dev/tty* stored anyware
> >   (/dev/.udev, links.conf...) and they get created, I supose that opening
> >   /dev/tty will give a ENODEV ?
> 
> well, /dev/tty is attached to your current tty and /dev/tty2 will get you
> talking to the second VT.  I can't immediately thing what /dev/tty22 is
> attached to.
> 

I supposed it was something like you always opened /dev/tty but kernel+glibc
redirect you to /dev/ttyXX, that is your _real_ terminal.
I will try to check docs...

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang


Jiri Kosina wrote:

On Wed, 25 Apr 2007, Helge Hafting wrote:

  
Anyway, based on information you have provided in your later messages, 
it seems that it is probably not necessairly related neither to USB 
nor HID, as you are getting hangs at different stages of boot, 
depending on your local configuration/kernel version used. Is vanilla 
2.6.21-rc6 ok? If so, would you have time to bisect the offending 
patch?
  
I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is 
good.  It boots up without hanging, and my USB devices works too. Should 
I test rc7-mm1 then?



That would also be useful.

But really identifying offending patch using bisection would help most. 
  

If there is an offending patch at all - my rc6-mm1 kernel must
have been built from messed-up sources - we saw that when your
patch did not apply.  So my source had errors - right in the USB part.

I haven't tested a correct rc6-mm1, so I don't even know if it
has problems.  I can make such a kernel of course. . .
And it should be pretty easy and not too much time consuming for you, as 
the bug triggers immediately upon boot in your case.
  

Indeed - it is easy to spot. :-)

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang

2007-04-25 Thread Jiri Kosina

On Wed, 25 Apr 2007, Helge Hafting wrote:

> > Anyway, based on information you have provided in your later messages, 
> > it seems that it is probably not necessairly related neither to USB 
> > nor HID, as you are getting hangs at different stages of boot, 
> > depending on your local configuration/kernel version used. Is vanilla 
> > 2.6.21-rc6 ok? If so, would you have time to bisect the offending 
> > patch?
> I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is 
> good.  It boots up without hanging, and my USB devices works too. Should 
> I test rc7-mm1 then?

That would also be useful.

But really identifying offending patch using bisection would help most. 
And it should be pretty easy and not too much time consuming for you, as 
the bug triggers immediately upon boot in your case.

In case you are not convenient with "bisecting by hand" Andrew's quilt 
patchset, don't forget that it is also possible to obtain -mm tree through 
git, which provides very convenient means for bisecting. This is what I 
usually do.

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang


Jiri Kosina wrote:
[...]
So I guess you are operating on some broken version of 2.6.21-rc6-mm1 
codebase if you are getting rejects on this trivial patch.
  

Didn't think of that - the codebase might be wrong.


Anyway, based on information you have provided in your later messages, it 
seems that it is probably not necessairly related neither to USB nor HID, 
as you are getting hangs at different stages of boot, depending on your 
local configuration/kernel version used.


Is vanilla 2.6.21-rc6 ok? If so, would you have time to bisect the 
offending patch?
  

I don't know about 2.6.21-rc6, but 2.6.21-rc7
(from fresh sources) is good.  It boots up without hanging,
and my USB devices works too.

Should I test rc7-mm1 then?

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang


Jiri Kosina wrote:
[...]
So I guess you are operating on some broken version of 2.6.21-rc6-mm1 
codebase if you are getting rejects on this trivial patch.
  

Didn't think of that - the codebase might be wrong.


Anyway, based on information you have provided in your later messages, it 
seems that it is probably not necessairly related neither to USB nor HID, 
as you are getting hangs at different stages of boot, depending on your 
local configuration/kernel version used.


Is vanilla 2.6.21-rc6 ok? If so, would you have time to bisect the 
offending patch?
  

I don't know about 2.6.21-rc6, but 2.6.21-rc7
(from fresh sources) is good.  It boots up without hanging,
and my USB devices works too.

Should I test rc7-mm1 then?

Helge Hafting

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang

2007-04-25 Thread Jiri Kosina

On Wed, 25 Apr 2007, Helge Hafting wrote:

  Anyway, based on information you have provided in your later messages, 
  it seems that it is probably not necessairly related neither to USB 
  nor HID, as you are getting hangs at different stages of boot, 
  depending on your local configuration/kernel version used. Is vanilla 
  2.6.21-rc6 ok? If so, would you have time to bisect the offending 
  patch?
 I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is 
 good.  It boots up without hanging, and my USB devices works too. Should 
 I test rc7-mm1 then?

That would also be useful.

But really identifying offending patch using bisection would help most. 
And it should be pretty easy and not too much time consuming for you, as 
the bug triggers immediately upon boot in your case.

In case you are not convenient with bisecting by hand Andrew's quilt 
patchset, don't forget that it is also possible to obtain -mm tree through 
git, which provides very convenient means for bisecting. This is what I 
usually do.

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 USB related boot hang


Jiri Kosina wrote:

On Wed, 25 Apr 2007, Helge Hafting wrote:

  
Anyway, based on information you have provided in your later messages, 
it seems that it is probably not necessairly related neither to USB 
nor HID, as you are getting hangs at different stages of boot, 
depending on your local configuration/kernel version used. Is vanilla 
2.6.21-rc6 ok? If so, would you have time to bisect the offending 
patch?
  
I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is 
good.  It boots up without hanging, and my USB devices works too. Should 
I test rc7-mm1 then?



That would also be useful.

But really identifying offending patch using bisection would help most. 
  

If there is an offending patch at all - my rc6-mm1 kernel must
have been built from messed-up sources - we saw that when your
patch did not apply.  So my source had errors - right in the USB part.

I haven't tested a correct rc6-mm1, so I don't even know if it
has problems.  I can make such a kernel of course. . .
And it should be pretty easy and not too much time consuming for you, as 
the bug triggers immediately upon boot in your case.
  

Indeed - it is easy to spot. :-)

Helge Hafting
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton [EMAIL PROTECTED] wrote:

 On Tue, 24 Apr 2007 15:43:21 +0200 J.A. Magallón [EMAIL PROTECTED] wrote:
 
  On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
  
   On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] 
   wrote:
   
On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] 
wrote:

 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
 
 
 - Lots of x86 updates
 

Has somthing related with PTY's changed in this kernel ?
   
   Not as far as I know, but there were some kobject_uevent changes which
   might have caused udev upcalls to break.  Perhaps.
   
I have to enable legacy PTY handling in a couple boxes to get ssh 
working.
If not, I had openpty() errors and nor sshd nor virtual terminals 
(aterm) were
able to get a terminal.
   
   I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
   works OK here.
   
User space (udev) is the same in three boxes and one works and two fail.
I had /dev/ptmx everywhere and /dev/pts mounted

Any idea ?
   
   Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
   it might have been the kobject_uevent thing.
   
  
  I will, thanks.
  
  A couple questions (as far as udev behaviour is sooo distro dependent):
  - What should I have in /dev if I don't use legacy ptys ? As I understand
it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?
 
 My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of
 /dev/tty0 through /dev/tty63 and no /dev/pty*.
 
 I'm not sure where all the /dev/tty*'s came from - perhaps a static udev
 rule?


Uh ?
From the Kconfig help fot UNIX98_PTYS:

Linux has traditionally used the BSD-like names /dev/ptyxx for
masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
has a number of problems. The GNU C library glibc 2.1 and later,
however, supports the Unix98 naming standard: in order to acquire a
pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
terminal is then made available to the process and the pseudo
terminal slave can be accessed as /dev/pts/number. What was
traditionally /dev/ttyp2 will then be /dev/pts/2, for example.

So if all userspace is Unix98-aware, you just would be done with
/dev/ptmx and /dev/pts/*. In your setup it looks like you are not able
to use Unix98 PTYs, but as udev has created tty* things work.
Or not ?

  - If my setup, for whatever strange reasons has /dev/tty* stored anyware
(/dev/.udev, links.conf...) and they get created, I supose that opening
/dev/tty will give a ENODEV ?
 
 well, /dev/tty is attached to your current tty and /dev/tty2 will get you
 talking to the second VT.  I can't immediately thing what /dev/tty22 is
 attached to.
 

I supposed it was something like you always opened /dev/tty but kernel+glibc
redirect you to /dev/ttyXX, that is your _real_ terminal.
I will try to check docs...

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

start_udev and devpts [Re: 2.6.21-rc6-mm1]

On Wed, 25 Apr 2007 22:50:39 +0200, J.A. Magallón [EMAIL PROTECTED] wrote:

On Tue, 24 Apr 2007 10:22:50 -0700, Andrew Morton [EMAIL PROTECTED] wrote:

On Tue, 24 Apr 2007 15:43:21 +0200 J.A. Magallón [EMAIL PROTECTED]
wrote:

On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED]
wrote:

On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED]
wrote:

On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED]
wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/

- Lots of x86 updates

Has somthing related with PTY's changed in this kernel ?

Not as far as I know, but there were some kobject_uevent changes which
might have caused udev upcalls to break. Perhaps.

I have to enable legacy PTY handling in a couple boxes to get ssh
working.
If not, I had openpty() errors and nor sshd nor virtual terminals
(aterm) were
able to get a terminal.

I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
works OK here.

User space (udev) is the same in three boxes and one works and two
fail.
I had /dev/ptmx everywhere and /dev/pts mounted

Any idea ?

Nope. Can you please check 2.6.21-rc7-mm1, see if that fixed it? If
so,
it might have been the kobject_uevent thing.

I will, thanks.

A couple questions (as far as udev behaviour is sooo distro
dependent):
- What should I have in /dev if I don't use legacy ptys ? As I understand
it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?

My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of
/dev/tty0 through /dev/tty63 and no /dev/pty*.

I'm not sure where all the /dev/tty*'s came from - perhaps a static udev
rule?

Uh ?
From the Kconfig help fot UNIX98_PTYS:

Linux has traditionally used the BSD-like names /dev/ptyxx for
masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
has a number of problems. The GNU C library glibc 2.1 and later,
however, supports the Unix98 naming standard: in order to acquire a
pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
terminal is then made available to the process and the pseudo
terminal slave can be accessed as /dev/pts/number. What was
traditionally /dev/ttyp2 will then be /dev/pts/2, for example.

So if all userspace is Unix98-aware, you just would be done with
/dev/ptmx and /dev/pts/*. In your setup it looks like you are not able
to use Unix98 PTYs, but as udev has created tty* things work.
Or not ?

- If my setup, for whatever strange reasons has /dev/tty* stored anyware
(/dev/.udev, links.conf...) and they get created, I supose that opening
/dev/tty will give a ENODEV ?

well, /dev/tty is attached to your current tty and /dev/tty2 will get you
talking to the second VT. I can't immediately thing what /dev/tty22 is
attached to.

I supposed it was something like you always opened /dev/tty but kernel+glibc
redirect you to /dev/ttyXX, that is your _real_ terminal.
I will try to check docs...

Oops, no, /dev/tty?? are for virtual consoles.

But I think I found the problem.
In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked
fine again.
I'll dig mandrivas rc's to check this...

Anyways, I see no plain 'mount' command in /sbin/start_udev, all are
'mount --move' commands. So I think it supposes is already mounted and
tries to move it.

--
J.A. Magallon jamagallon()ono!com \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP
PREEMPT
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: start_udev and devpts [Re: 2.6.21-rc6-mm1]

On Wed, 25 Apr 2007 23:39:54 +0200, J.A. Magallón [EMAIL PROTECTED] wrote:

 On Wed, 25 Apr 2007 22:50:39 +0200, J.A. Magallón [EMAIL PROTECTED] wrote:
...
 
 But I think I found the problem.
 In short, in /dev/pts is mounted before /dev. I remounted it and ssh worked
 fine again.
 I'll dig mandrivas rc's to check this...
 
 Anyways, I see no plain 'mount' command in /sbin/start_udev, all are 
 'mount --move' commands. So I think it supposes is already mounted and
 tries to move it.
 

As a (in)famous last work, I think Unix98 PTYs really don't like mount --move
for /dev/pts. If I mount it manually after boot, everything works fine.

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 15:43:21 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> 
> > wrote:
> > 
> > > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> 
> > > wrote:
> > > 
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > > > 
> > > > 
> > > > - Lots of x86 updates
> > > > 
> > > 
> > > Has somthing related with PTY's changed in this kernel ?
> > 
> > Not as far as I know, but there were some kobject_uevent changes which
> > might have caused udev upcalls to break.  Perhaps.
> > 
> > > I have to enable legacy PTY handling in a couple boxes to get ssh working.
> > > If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) 
> > > were
> > > able to get a terminal.
> > 
> > I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
> > works OK here.
> > 
> > > User space (udev) is the same in three boxes and one works and two fail.
> > > I had /dev/ptmx everywhere and /dev/pts mounted
> > > 
> > > Any idea ?
> > 
> > Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
> > it might have been the kobject_uevent thing.
> > 
> 
> I will, thanks.
> 
> A couple questions (as far as udev behaviour is sooo distro dependent):
> - What should I have in /dev if I don't use legacy ptys ? As I understand
>   it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?

My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of
/dev/tty0 through /dev/tty63 and no /dev/pty*.

I'm not sure where all the /dev/tty*'s came from - perhaps a static udev
rule?

> - If my setup, for whatever strange reasons has /dev/tty* stored anyware
>   (/dev/.udev, links.conf...) and they get created, I supose that opening
>   /dev/tty will give a ENODEV ?

well, /dev/tty is attached to your current tty and /dev/tty2 will get you
talking to the second VT.  I can't immediately thing what /dev/tty22 is
attached to.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:
> 
> > On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > > 
> > > 
> > > - Lots of x86 updates
> > > 
> > 
> > Has somthing related with PTY's changed in this kernel ?
> 
> Not as far as I know, but there were some kobject_uevent changes which
> might have caused udev upcalls to break.  Perhaps.
> 
> > I have to enable legacy PTY handling in a couple boxes to get ssh working.
> > If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) 
> > were
> > able to get a terminal.
> 
> I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
> works OK here.
> 
> > User space (udev) is the same in three boxes and one works and two fail.
> > I had /dev/ptmx everywhere and /dev/pts mounted
> > 
> > Any idea ?
> 
> Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
> it might have been the kobject_uevent thing.
> 

I will, thanks.

A couple questions (as far as udev behaviour is sooo distro dependent):
- What should I have in /dev if I don't use legacy ptys ? As I understand
  it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?
- If my setup, for whatever strange reasons has /dev/tty* stored anyware
  (/dev/.udev, links.conf...) and they get created, I supose that opening
  /dev/tty will give a ENODEV ?

TIA

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 10:10:41 +0200 "J.A. Magallón" <[EMAIL PROTECTED]> wrote:

> On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> > 
> > 
> > - Lots of x86 updates
> > 
> 
> Has somthing related with PTY's changed in this kernel ?

Not as far as I know, but there were some kobject_uevent changes which
might have caused udev upcalls to break.  Perhaps.

> I have to enable legacy PTY handling in a couple boxes to get ssh working.
> If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were
> able to get a terminal.

I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
works OK here.

> User space (udev) is the same in three boxes and one works and two fail.
> I had /dev/ptmx everywhere and /dev/pts mounted
> 
> Any idea ?

Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
it might have been the kobject_uevent thing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
> 
> 
> - Lots of x86 updates
> 

Has somthing related with PTY's changed in this kernel ?
I have to enable legacy PTY handling in a couple boxes to get ssh working.
If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were
able to get a terminal.

User space (udev) is the same in three boxes and one works and two fail.
I had /dev/ptmx everywhere and /dev/pts mounted

Any idea ?
TIA

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP 
PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote:

 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
 
 
 - Lots of x86 updates
 

Has somthing related with PTY's changed in this kernel ?
I have to enable legacy PTY handling in a couple boxes to get ssh working.
If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were
able to get a terminal.

User space (udev) is the same in three boxes and one works and two fail.
I had /dev/ptmx everywhere and /dev/pts mounted

Any idea ?
TIA

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #1 SMP 
PREEMPT
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] wrote:

 On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
 
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
  
  
  - Lots of x86 updates
  
 
 Has somthing related with PTY's changed in this kernel ?

Not as far as I know, but there were some kobject_uevent changes which
might have caused udev upcalls to break.  Perhaps.

 I have to enable legacy PTY handling in a couple boxes to get ssh working.
 If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) were
 able to get a terminal.

I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
works OK here.

 User space (udev) is the same in three boxes and one works and two fail.
 I had /dev/ptmx everywhere and /dev/pts mounted
 
 Any idea ?

Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
it might have been the kobject_uevent thing.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED] wrote:

 On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] wrote:
 
  On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
  
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/
   
   
   - Lots of x86 updates
   
  
  Has somthing related with PTY's changed in this kernel ?
 
 Not as far as I know, but there were some kobject_uevent changes which
 might have caused udev upcalls to break.  Perhaps.
 
  I have to enable legacy PTY handling in a couple boxes to get ssh working.
  If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) 
  were
  able to get a terminal.
 
 I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
 works OK here.
 
  User space (udev) is the same in three boxes and one works and two fail.
  I had /dev/ptmx everywhere and /dev/pts mounted
  
  Any idea ?
 
 Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
 it might have been the kobject_uevent thing.
 

I will, thanks.

A couple questions (as far as udev behaviour is sooo distro dependent):
- What should I have in /dev if I don't use legacy ptys ? As I understand
  it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?
- If my setup, for whatever strange reasons has /dev/tty* stored anyware
  (/dev/.udev, links.conf...) and they get created, I supose that opening
  /dev/tty will give a ENODEV ?

TIA

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2008.0 (Cooker) for i586
Linux 2.6.20-jam10 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #4 SMP 
PREEMPT
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1

On Tue, 24 Apr 2007 15:43:21 +0200 J.A. Magallón [EMAIL PROTECTED] wrote:

 On Tue, 24 Apr 2007 04:58:01 -0700, Andrew Morton [EMAIL PROTECTED] wrote:
 
  On Tue, 24 Apr 2007 10:10:41 +0200 J.A. Magallón [EMAIL PROTECTED] 
  wrote:
  
   On Sun, 8 Apr 2007 14:35:59 -0700, Andrew Morton [EMAIL PROTECTED] 
   wrote:
   

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/


- Lots of x86 updates

   
   Has somthing related with PTY's changed in this kernel ?
  
  Not as far as I know, but there were some kobject_uevent changes which
  might have caused udev upcalls to break.  Perhaps.
  
   I have to enable legacy PTY handling in a couple boxes to get ssh working.
   If not, I had openpty() errors and nor sshd nor virtual terminals (aterm) 
   were
   able to get a terminal.
  
  I have CONFIG_PM_LEGACY unset in at least one of my test configs and it
  works OK here.
  
   User space (udev) is the same in three boxes and one works and two fail.
   I had /dev/ptmx everywhere and /dev/pts mounted
   
   Any idea ?
  
  Nope.  Can you please check 2.6.21-rc7-mm1, see if that fixed it?  If so,
  it might have been the kobject_uevent thing.
  
 
 I will, thanks.
 
 A couple questions (as far as udev behaviour is sooo distro dependent):
 - What should I have in /dev if I don't use legacy ptys ? As I understand
   it, only /dev/ptmx and /dev/pts/*, no /dev/tty* nor /dev/pty* ?

My FC5 CONFIG_LEGACY_PTYS=n box has no /dev/ptmx, /dev/pts/*, all of
/dev/tty0 through /dev/tty63 and no /dev/pty*.

I'm not sure where all the /dev/tty*'s came from - perhaps a static udev
rule?

 - If my setup, for whatever strange reasons has /dev/tty* stored anyware
   (/dev/.udev, links.conf...) and they get created, I supose that opening
   /dev/tty will give a ENODEV ?

well, /dev/tty is attached to your current tty and /dev/tty2 will get you
talking to the second VT.  I can't immediately thing what /dev/tty22 is
attached to.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

> "John" == John Stoffel <[EMAIL PROTECTED]> writes:

> "John" == John Stoffel <[EMAIL PROTECTED]> writes:
 > Ok, so do I need to do anything special with the next -mm release and
 > the next version?
 
 Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Alan> Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan> me know.  It means that Sergei's DPLL sync code seems to work
Alan> better than the vendor code and its time to swap it over.

John> Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
John> in modular so I can switch around more easily.  I hope.  :]

John> Ok, here's the dmesg output using the hpt366 old IDE driver,
John> 2.6.21-rc7, SMP: 

John> [  160.926355] HPT302: IDE controller at PCI slot :03:06.0
John> [  160.928030] ACPI: PCI Interrupt :03:06.0[A] -> GSI 18 (level, low) 
-> IRQ
John>  18
John> [  160.931212] HPT302: chipset revision 1
John> [  160.932801] HPT302: DPLL base: 66 MHz, f_CNT: 100, assuming 33 MHz PCI
John> [  160.941157] HPT302: using 66 MHz DPLL clock
John> [  160.942646] HPT302: 100% native mode on irq 18
John> [  160.943918] ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, 
hdf:pi
John> o
John> [  160.946636] ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, 
hdh:pi
John> o
John> [  160.949439] Probing IDE interface ide2...
John> [  161.213560] hde: WDC WD1200JB-00CRA1, ATA DISK drive
John> [  161.828020] ide2 at 0xecf8-0xecff,0xecf2 on irq 18
John> [  161.829616] Probing IDE interface ide3...
John> [  162.094086] hdg: WDC WD1200JB-00EVA0, ATA DISK drive
John> [  162.709002] ide3 at 0xece0-0xece7,0xecda on irq 18


John> Which looks ok to me I guess.  It found my MD disks on there and
John> assmebled them, eventually.  *grin*

John> I'll reboot and send out the corresponding ATA HPT37x driver dmesg...

And here's the output (much more verbose!) from the hpt37x ATA driver:

[  158.712007] hpt37x: HPT302: Bus clock 33MHz.
[  158.713390] ACPI: PCI Interrupt :03:06.0[A] -> GSI 18 (level, low) -> IRQ
 18
[  158.716254] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2 bmdma 0x000
1e800 irq 18
[  158.719019] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda bmdma 0x000
1e808 irq 18
[  158.722257] scsi7 : pata_hpt37x
[  158.878133] ata5.00: ATA-5: WDC WD1200JB-00CRA1, 17.07W17, max UDMA/100
[  158.879576] ata5.00: 234441648 sectors, multi 16: LBA 
[  158.880934] Find mode for 12 reports C829C62
[  158.882240] Find mode for DMA 69 reports 1C6DDC62
[  158.888152] ata5.00: configured for UDMA/100
[  158.889437] scsi8 : pata_hpt37x
[  158.900338] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[  158.901660] ide: Assuming 33MHz system bus speed for PIO modes; override with
 idebus=xx
[  159.047026] ata6.00: ATA-6: WDC WD1200JB-00EVA0, 15.05R15, max UDMA/100
[  159.048412] ata6.00: 234441648 sectors, multi 16: LBA48 
[  159.050008] Find mode for 12 reports C829C62
[  159.051371] Find mode for DMA 69 reports 1C6DDC62
[  159.057079] ata6.00: configured for UDMA/100
[  159.063655] scsi 7:0:0:0: Direct-Access ATA  WDC WD1200JB-00C 17.0 PQ
: 0 ANSI: 5
[  159.067506] SCSI device sdi: 234441648 512-byte hdwr sectors (120034 MB)
[  159.069004] sdi: Write Protect is off
[  159.070412] sdi: Mode Sense: 00 3a 00 00
[  159.070487] SCSI device sdi: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.073427] SCSI device sdi: 234441648 512-byte hdwr sectors (120034 MB)
[  159.074882] sdi: Write Protect is off
[  159.076262] sdi: Mode Sense: 00 3a 00 00
[  159.076339] SCSI device sdi: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.079097]  sdi: sdi1
[  159.097634] sd 7:0:0:0: Attached scsi disk sdi
[  159.099212] sd 7:0:0:0: Attached scsi generic sg9 type 0
[  159.102344] scsi 8:0:0:0: Direct-Access ATA  WDC WD1200JB-00E 15.0 PQ
: 0 ANSI: 5
[  159.106197] SCSI device sdj: 234441648 512-byte hdwr sectors (120034 MB)
[  159.107722] sdj: Write Protect is off
[  159.109188] sdj: Mode Sense: 00 3a 00 00
[  159.109271] SCSI device sdj: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.112455] SCSI device sdj: 234441648 512-byte hdwr sectors (120034 MB)
[  159.114094] sdj: Write Protect is off
[  159.115870] sdj: Mode Sense: 00 3a 00 00
[  159.115943] SCSI device sdj: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.118965]  sdj: sdj1
[  159.138036] sd 8:0:0:0: Attached scsi disk sdj
[  159.139682] sd 8:0:0:0: Attached scsi generic sg10 type 0



In both cases, my RAID1 disks are found and come up cleanly, which is
good.  Thanks for all the work you guys have done on the IDE stuff, as
well as the new libATA stuff.

Let me know if you need more testing done here, I've only got a
scratch volume on this raid set.

John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

> "John" == John Stoffel <[EMAIL PROTECTED]> writes:

>>> > Ok, so do I need to do anything special with the next -mm release and
>>> > the next version?
>>> 
>>> Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Alan> Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan> me know.  It means that Sergei's DPLL sync code seems to work
Alan> better than the vendor code and its time to swap it over.

John> Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
John> in modular so I can switch around more easily.  I hope.  :]

Ok, here's the dmesg output using the hpt366 old IDE driver,
2.6.21-rc7, SMP: 

[  160.926355] HPT302: IDE controller at PCI slot :03:06.0
[  160.928030] ACPI: PCI Interrupt :03:06.0[A] -> GSI 18 (level, low) -> IRQ
 18
[  160.931212] HPT302: chipset revision 1
[  160.932801] HPT302: DPLL base: 66 MHz, f_CNT: 100, assuming 33 MHz PCI
[  160.941157] HPT302: using 66 MHz DPLL clock
[  160.942646] HPT302: 100% native mode on irq 18
[  160.943918] ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pi
o
[  160.946636] ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, hdh:pi
o
[  160.949439] Probing IDE interface ide2...
[  161.213560] hde: WDC WD1200JB-00CRA1, ATA DISK drive
[  161.828020] ide2 at 0xecf8-0xecff,0xecf2 on irq 18
[  161.829616] Probing IDE interface ide3...
[  162.094086] hdg: WDC WD1200JB-00EVA0, ATA DISK drive
[  162.709002] ide3 at 0xece0-0xece7,0xecda on irq 18


Which looks ok to me I guess.  It found my MD disks on there and
assmebled them, eventually.  *grin*

I'll reboot and send out the corresponding ATA HPT37x driver dmesg...

John

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]

2007-04-18 Thread Shaohua Li

On Wed, 2007-04-18 at 19:00 -0400, Joshua Wise wrote:
> On Tue, 17 Apr 2007, Shaohua Li wrote:
> > Looks there is init order issue of sysfs files. The new refreshed patch
> > should fix your bug.
> 
> Yes, that did fix the hang on resume from STR -- that now works fine.
> 
> However:
> [EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_drivers 
> current_driver
> 
> 
> [EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_governors 
> current_governor
> ladder
> ladder
it's correct and looks you didn't compile the acpi processor module.

Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]

2007-04-18 Thread Joshua Wise


On Tue, 17 Apr 2007, Shaohua Li wrote:

Looks there is init order issue of sysfs files. The new refreshed patch
should fix your bug.


Yes, that did fix the hang on resume from STR -- that now works fine.

However:
[EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_drivers 
current_driver


[EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_governors 
current_governor
ladder
ladder

Is this correct? For reference, my config is http://joshuawise.com/config.gz
-- I didn't see any options for cpuidle drivers to access ACPI states...

joshua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]

2007-04-18 Thread Joshua Wise


On Tue, 17 Apr 2007, Shaohua Li wrote:

Looks there is init order issue of sysfs files. The new refreshed patch
should fix your bug.


Yes, that did fix the hang on resume from STR -- that now works fine.

However:
[EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_drivers 
current_driver

NULL
[EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_governors 
current_governor
ladder
ladder

Is this correct? For reference, my config is http://joshuawise.com/config.gz
-- I didn't see any options for cpuidle drivers to access ACPI states...

joshua
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]

2007-04-18 Thread Shaohua Li

On Wed, 2007-04-18 at 19:00 -0400, Joshua Wise wrote:
 On Tue, 17 Apr 2007, Shaohua Li wrote:
  Looks there is init order issue of sysfs files. The new refreshed patch
  should fix your bug.
 
 Yes, that did fix the hang on resume from STR -- that now works fine.
 
 However:
 [EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_drivers 
 current_driver
 
 NULL
 [EMAIL PROTECTED]:/sys/devices/system/cpu/cpuidle$ cat available_governors 
 current_governor
 ladder
 ladder
it's correct and looks you didn't compile the acpi processor module.

Thanks,
Shaohua
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

 John == John Stoffel [EMAIL PROTECTED] writes:

  Ok, so do I need to do anything special with the next -mm release and
  the next version?
 
 Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Alan Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan me know.  It means that Sergei's DPLL sync code seems to work
Alan better than the vendor code and its time to swap it over.

John Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
John in modular so I can switch around more easily.  I hope.  :]

Ok, here's the dmesg output using the hpt366 old IDE driver,
2.6.21-rc7, SMP: 

[  160.926355] HPT302: IDE controller at PCI slot :03:06.0
[  160.928030] ACPI: PCI Interrupt :03:06.0[A] - GSI 18 (level, low) - IRQ
 18
[  160.931212] HPT302: chipset revision 1
[  160.932801] HPT302: DPLL base: 66 MHz, f_CNT: 100, assuming 33 MHz PCI
[  160.941157] HPT302: using 66 MHz DPLL clock
[  160.942646] HPT302: 100% native mode on irq 18
[  160.943918] ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pi
o
[  160.946636] ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, hdh:pi
o
[  160.949439] Probing IDE interface ide2...
[  161.213560] hde: WDC WD1200JB-00CRA1, ATA DISK drive
[  161.828020] ide2 at 0xecf8-0xecff,0xecf2 on irq 18
[  161.829616] Probing IDE interface ide3...
[  162.094086] hdg: WDC WD1200JB-00EVA0, ATA DISK drive
[  162.709002] ide3 at 0xece0-0xece7,0xecda on irq 18


Which looks ok to me I guess.  It found my MD disks on there and
assmebled them, eventually.  *grin*

I'll reboot and send out the corresponding ATA HPT37x driver dmesg...

John

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

 John == John Stoffel [EMAIL PROTECTED] writes:

 John == John Stoffel [EMAIL PROTECTED] writes:
  Ok, so do I need to do anything special with the next -mm release and
  the next version?
 
 Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Alan Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan me know.  It means that Sergei's DPLL sync code seems to work
Alan better than the vendor code and its time to swap it over.

John Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
John in modular so I can switch around more easily.  I hope.  :]

John Ok, here's the dmesg output using the hpt366 old IDE driver,
John 2.6.21-rc7, SMP: 

John [  160.926355] HPT302: IDE controller at PCI slot :03:06.0
John [  160.928030] ACPI: PCI Interrupt :03:06.0[A] - GSI 18 (level, low) 
- IRQ
John  18
John [  160.931212] HPT302: chipset revision 1
John [  160.932801] HPT302: DPLL base: 66 MHz, f_CNT: 100, assuming 33 MHz PCI
John [  160.941157] HPT302: using 66 MHz DPLL clock
John [  160.942646] HPT302: 100% native mode on irq 18
John [  160.943918] ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, 
hdf:pi
John o
John [  160.946636] ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, 
hdh:pi
John o
John [  160.949439] Probing IDE interface ide2...
John [  161.213560] hde: WDC WD1200JB-00CRA1, ATA DISK drive
John [  161.828020] ide2 at 0xecf8-0xecff,0xecf2 on irq 18
John [  161.829616] Probing IDE interface ide3...
John [  162.094086] hdg: WDC WD1200JB-00EVA0, ATA DISK drive
John [  162.709002] ide3 at 0xece0-0xece7,0xecda on irq 18


John Which looks ok to me I guess.  It found my MD disks on there and
John assmebled them, eventually.  *grin*

John I'll reboot and send out the corresponding ATA HPT37x driver dmesg...

And here's the output (much more verbose!) from the hpt37x ATA driver:

[  158.712007] hpt37x: HPT302: Bus clock 33MHz.
[  158.713390] ACPI: PCI Interrupt :03:06.0[A] - GSI 18 (level, low) - IRQ
 18
[  158.716254] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2 bmdma 0x000
1e800 irq 18
[  158.719019] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda bmdma 0x000
1e808 irq 18
[  158.722257] scsi7 : pata_hpt37x
[  158.878133] ata5.00: ATA-5: WDC WD1200JB-00CRA1, 17.07W17, max UDMA/100
[  158.879576] ata5.00: 234441648 sectors, multi 16: LBA 
[  158.880934] Find mode for 12 reports C829C62
[  158.882240] Find mode for DMA 69 reports 1C6DDC62
[  158.888152] ata5.00: configured for UDMA/100
[  158.889437] scsi8 : pata_hpt37x
[  158.900338] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[  158.901660] ide: Assuming 33MHz system bus speed for PIO modes; override with
 idebus=xx
[  159.047026] ata6.00: ATA-6: WDC WD1200JB-00EVA0, 15.05R15, max UDMA/100
[  159.048412] ata6.00: 234441648 sectors, multi 16: LBA48 
[  159.050008] Find mode for 12 reports C829C62
[  159.051371] Find mode for DMA 69 reports 1C6DDC62
[  159.057079] ata6.00: configured for UDMA/100
[  159.063655] scsi 7:0:0:0: Direct-Access ATA  WDC WD1200JB-00C 17.0 PQ
: 0 ANSI: 5
[  159.067506] SCSI device sdi: 234441648 512-byte hdwr sectors (120034 MB)
[  159.069004] sdi: Write Protect is off
[  159.070412] sdi: Mode Sense: 00 3a 00 00
[  159.070487] SCSI device sdi: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.073427] SCSI device sdi: 234441648 512-byte hdwr sectors (120034 MB)
[  159.074882] sdi: Write Protect is off
[  159.076262] sdi: Mode Sense: 00 3a 00 00
[  159.076339] SCSI device sdi: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.079097]  sdi: sdi1
[  159.097634] sd 7:0:0:0: Attached scsi disk sdi
[  159.099212] sd 7:0:0:0: Attached scsi generic sg9 type 0
[  159.102344] scsi 8:0:0:0: Direct-Access ATA  WDC WD1200JB-00E 15.0 PQ
: 0 ANSI: 5
[  159.106197] SCSI device sdj: 234441648 512-byte hdwr sectors (120034 MB)
[  159.107722] sdj: Write Protect is off
[  159.109188] sdj: Mode Sense: 00 3a 00 00
[  159.109271] SCSI device sdj: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.112455] SCSI device sdj: 234441648 512-byte hdwr sectors (120034 MB)
[  159.114094] sdj: Write Protect is off
[  159.115870] sdj: Mode Sense: 00 3a 00 00
[  159.115943] SCSI device sdj: write cache: enabled, read cache: enabled, doesn
't support DPO or FUA
[  159.118965]  sdj: sdj1
[  159.138036] sd 8:0:0:0: Attached scsi disk sdj
[  159.139682] sd 8:0:0:0: Attached scsi generic sg10 type 0



In both cases, my RAID1 disks are found and come up cleanly, which is
good.  Thanks for all the work you guys have done on the IDE stuff, as
well as the new libATA stuff.

Let me know if you need more testing done here, I've only got a
scratch volume on this raid set.

John
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

2007-04-17 Thread Mark Lord


Sergei Shtylyov wrote:


  HPT chips are surely not a good example of how to do things, more like 
an example how *not* to do. :-)


That explains a lot!  :)

(guess who's first ATA work was on the Highpoint driver..
.. no need to post the answer here, though)

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


Hello.

John Stoffel wrote:


Ok, so do I need to do anything special with the next -mm release and
the next version?



Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).



Alan> Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan> me know.  It means that Sergei's DPLL sync code seems to work
Alan> better than the vendor code and its time to swap it over.



Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
in modular so I can switch around more easily.  I hope.  :]


  You can't switch from the old IDE driver -- they're *not* unloadable. :-/


Alan> Oh how I love highpoint PATA


  More like PITA. :-D


It seemed like a good buy at the time when I was researching these
things.  Best bang for the buck I guess.  It's a RocketRaid133 card,


  As for bang, it's true. You can't imagine how many days/nights I spent 
bangin' with the driver. :-D


but obviously I got a bum deal somewhere down the line.


  HPT chips are surely not a good example of how to do things, more like an 
example how *not* to do. :-)


John


MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


>> > Ok, so do I need to do anything special with the next -mm release and
>> > the next version?
>> 
>> Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Alan> Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan> me know.  It means that Sergei's DPLL sync code seems to work
Alan> better than the vendor code and its time to swap it over.

Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
in modular so I can switch around more easily.  I hope.  :]

Alan> Oh how I love highpoint PATA

It seemed like a good buy at the time when I was researching these
things.  Best bang for the buck I guess.  It's a RocketRaid133 card,
but obviously I got a bum deal somewhere down the line.

Now I've got a Sil3114 SATA controller, which seems to be working just
fine now.  Hopefully it won't have problems like this!

John

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

2007-04-17 Thread Alan Cox

> > Ok, so do I need to do anything special with the next -mm release and
> > the next version?
> 
>Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let me know.
It means that Sergei's DPLL sync code seems to work better than the
vendor code and its time to swap it over.

Oh how I love highpoint PATA

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


John Stoffel wrote:


I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:



[  148.121490] hpt37x: DPLL did not stabilize.



Where before, under 2.6.21-rc6 I got the following:



Sergei> For the moment I thought you're reporting another hpt366.c
Sergei> driver breakage but then noticed the next line:



I used to think that I wanted to use that driver too, but it's not
going to work.  It's because I've got the version 1 of the chip, not
the newer version 2 or higher version.


  So what?


It looks like you really mean for me to use the hpt3x2.c driver
instead, since that's the only other one which mentions the
PCI_DEVICE_ID_TTI_HPT302 device id in it's init method.


  I actually meant drivers/ide/pci/hpt366.c. :-)


[  173.749349] pata_hpt37x: BIOS has not set timing clocks.
[  173.752949] hpt37x: HPT302: Bus clock 33MHz.



Sergei>Obviously this was bacause of switching from PCI to DPLL
Sergei>clock. The old and new drivers are different in how they
Sergei>handle DPLL calibration though.  Could you try hpt366.c
Sergei>(there's been report about its failure too recently -- not
Sergei>enought details yet)?



I don't think it will work here, it won't even touch the card since
the pci_device_id won't match at all.  The htp366.c only looks at
HPT366 ids, while mine is an HPT302 id.


  The driver I've named should work (unless something is broken somewhere, that 
is).
Basically, it uses wider range to calibrate DPLL.


As a quick note, 2.6.21-rc7 is working just fine here.


  Yeah, it's still using PCI clock.


Ok, so do I need to do anything special with the next -mm release and
the next version?


  Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).


Thanks,
John


MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

>>>>> "Sergei" == Sergei Shtylyov <[EMAIL PROTECTED]> writes:

Sergei> Hello.
Sergei> John Stoffel wrote:

>> I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
>> and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
>> disks are not longer detected and I get the following in the dmesg
>> logs:

>> [  148.121490] hpt37x: DPLL did not stabilize.

>> Where before, under 2.6.21-rc6 I got the following:

Sergei> For the moment I thought you're reporting another hpt366.c
Sergei> driver breakage but then noticed the next line:

I used to think that I wanted to use that driver too, but it's not
going to work.  It's because I've got the version 1 of the chip, not
the newer version 2 or higher version.  

It looks like you really mean for me to use the hpt3x2.c driver
instead, since that's the only other one which mentions the
PCI_DEVICE_ID_TTI_HPT302 device id in it's init method.

>> [  173.749349] pata_hpt37x: BIOS has not set timing clocks.
>> [  173.752949] hpt37x: HPT302: Bus clock 33MHz.

Sergei>Obviously this was bacause of switching from PCI to DPLL
Sergei>clock. The old and new drivers are different in how they
Sergei>handle DPLL calibration though.  Could you try hpt366.c
Sergei>(there's been report about its failure too recently -- not
Sergei>enought details yet)?

I don't think it will work here, it won't even touch the card since
the pci_device_id won't match at all.  The htp366.c only looks at
HPT366 ids, while mine is an HPT302 id.  

As a quick note, 2.6.21-rc7 is working just fine here.  

>> [  173.754409] ACPI: PCI Interrupt :03:06.0[A] -> GSI 18 (level,
>> low) -> IRQ
>> 18
>> [  173.758403] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2
>> bmdma 0x000
>> 1e800 irq 18
>> [  173.761396] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda
>> bmdma 0x000
>> 1e808 irq 18
>> [  173.764319] scsi6 : pata_hpt37x
>> [  173.928997] ATA: abnormal status 0x78 on port 0x0001ecff
>> [  173.930511] scsi7 : pata_hpt37x
>> [  174.094906] ATA: abnormal status 0x8 on port 0x0001ece7

>> Here's my lspci infomation on the board, it's an addon.  My apologies
>> for the crappy word wrapping, xterms inside screen, etc. 

>> 03:06.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N
>> (rev 01)
>> Subsystem: Triones Technologies, Inc. Unknown device 0001
>> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Step
>> ping- SERR+ FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>> >TAbort- > - SERR- > Latency: 120 (2000ns min, 2000ns max)
>> Interrupt: pin A routed to IRQ 11
>> Region 0: I/O ports at ecf8 [size=8]
>> Region 1: I/O ports at ecf0 [size=4]
>> Region 2: I/O ports at ece0 [size=8]
>> Region 3: I/O ports at ecd8 [size=4]
>> Region 4: I/O ports at e800 [size=256]
>> Expansion ROM at f900 [disabled] [size=128K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot
>> -,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Sergei> Yeah, that's a "plain" HPT302 chip with the default 66 MHz
Sergei> DPLL clock.

Ok, so do I need to do anything special with the next -mm release and
the next version?

Thanks,
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


Hello.

John Stoffel wrote:


I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:



[  148.121490] hpt37x: DPLL did not stabilize.



Where before, under 2.6.21-rc6 I got the following:


  For the moment I thought you're reporting another hpt366.c driver breakage 
but then noticed the next line:


[  173.749349] pata_hpt37x: BIOS has not set timing clocks.
[  173.752949] hpt37x: HPT302: Bus clock 33MHz.


  Obviously this was bacause of switching from PCI to DPLL clock. The old and 
new drivers are different in how they handle DPLL calibration though.  Could 
you try hpt366.c (there's been report about its failure too recently -- not 
enought details yet)?


[  173.754409] ACPI: PCI Interrupt :03:06.0[A] -> GSI 18 (level,
low) -> IRQ
 18
[  173.758403] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2
bmdma 0x000
1e800 irq 18
[  173.761396] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda
bmdma 0x000
1e808 irq 18
[  173.764319] scsi6 : pata_hpt37x
[  173.928997] ATA: abnormal status 0x78 on port 0x0001ecff
[  173.930511] scsi7 : pata_hpt37x
[  174.094906] ATA: abnormal status 0x8 on port 0x0001ece7



Here's my lspci infomation on the board, it's an addon.  My apologies
for the crappy word wrapping, xterms inside screen, etc. 



  03:06.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N
  (rev 01)
  Subsystem: Triones Technologies, Inc. Unknown device 0001
  Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
  ParErr- Step
  ping- SERR+ FastB2B-
  Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
  >TAbort- SERR- 

  Yeah, that's a "plain" HPT302 chip with the default 66 MHz DPLL clock.

MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]

2007-04-17 Thread Shaohua Li

On Mon, 2007-04-16 at 22:50 -0400, Joshua Wise wrote:
> On Mon, 16 Apr 2007, Shaohua Li wrote:
> > On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
> >> ...
> > please check if the patch at
> > http://marc.info/?l=linux-acpi=117523651630038=2 fixed the issue
> 
> I have the same system as Mattia, and when I applied this patch and turned
> CPU_IDLE back on, I got a panic on boot. Unfortunately, the EIP scrolled off
> screen, so I can't get a line number.
> 
> (I had the same STR breakage as him; STR did not work with CPU_IDLE turned
> on, and it did work with CPU_IDLE turned off.)
> 
> I'm running +rc6+mm(April 11) on a Sony VAIO SZ.
Looks there is init order issue of sysfs files. The new refreshed patch
should fix your bug.

Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>

Index: 21-rc6-mm1/drivers/acpi/processor_idle.c
===
--- 21-rc6-mm1.orig/drivers/acpi/processor_idle.c   2007-04-17 
13:41:29.0 +0800
+++ 21-rc6-mm1/drivers/acpi/processor_idle.c2007-04-17 14:03:56.0 
+0800
@@ -624,7 +624,7 @@ int acpi_processor_cst_has_changed(struc
return -ENODEV;
 
acpi_processor_get_power_info(pr);
-   return cpuidle_force_redetect(_cpu(cpuidle_devices, pr->id));
+   return cpuidle_force_redetect(per_cpu(cpuidle_devices, pr->id));
 }
 
 /* proc interface */
Index: 21-rc6-mm1/drivers/cpuidle/cpuidle.c
===
--- 21-rc6-mm1.orig/drivers/cpuidle/cpuidle.c   2007-04-17 13:41:29.0 
+0800
+++ 21-rc6-mm1/drivers/cpuidle/cpuidle.c2007-04-17 14:42:17.0 
+0800
@@ -18,7 +18,7 @@
 
 #include "cpuidle.h"
 
-DEFINE_PER_CPU(struct cpuidle_device, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
 EXPORT_PER_CPU_SYMBOL_GPL(cpuidle_devices);
 
 DEFINE_MUTEX(cpuidle_lock);
@@ -34,13 +34,13 @@ static void (*pm_idle_old)(void);
  */
 static void cpuidle_idle_call(void)
 {
-   struct cpuidle_device *dev = &__get_cpu_var(cpuidle_devices);
+   struct cpuidle_device *dev = __get_cpu_var(cpuidle_devices);
 
struct cpuidle_state *target_state;
int next_state;
 
/* check if the device is ready */
-   if (dev->status != CPUIDLE_STATUS_DOIDLE) {
+   if (!dev || dev->status != CPUIDLE_STATUS_DOIDLE) {
if (pm_idle_old)
pm_idle_old();
return;
@@ -117,19 +117,32 @@ static int cpuidle_add_device(struct sys
int cpu = sys_dev->id;
struct cpuidle_device *dev;
 
-   dev = _cpu(cpuidle_devices, cpu);
+   dev = per_cpu(cpuidle_devices, cpu);
 
-   dev->cpu = cpu;
mutex_lock(_lock);
if (cpu_is_offline(cpu)) {
mutex_unlock(_lock);
return 0;
}
 
+   if (!dev) {
+   dev = kzalloc(sizeof(struct cpuidle_device), GFP_KERNEL);
+   if (!dev) {
+   mutex_unlock(_lock);
+   return -ENOMEM;
+   }
+   init_completion(>kobj_unregister);
+   per_cpu(cpuidle_devices, cpu) = dev;
+   }
+   dev->cpu = cpu;
+
if (dev->status & CPUIDLE_STATUS_DETECTED) {
mutex_unlock(_lock);
return 0;
}
+
+   cpuidle_add_sysfs(sys_dev);
+
if (cpuidle_curr_driver) {
if (cpuidle_attach_driver(dev))
goto err_ret;
@@ -146,7 +159,6 @@ static int cpuidle_add_device(struct sys
cpuidle_install_idle_handler();
 
list_add(>device_list, _detected_devices);
-   cpuidle_add_sysfs(sys_dev);
dev->status |= CPUIDLE_STATUS_DETECTED;
 
 err_ret:
@@ -165,7 +177,7 @@ static int __cpuidle_remove_device(struc
 {
struct cpuidle_device *dev;
 
-   dev = _cpu(cpuidle_devices, sys_dev->id);
+   dev = per_cpu(cpuidle_devices, sys_dev->id);
 
if (!(dev->status & CPUIDLE_STATUS_DETECTED)) {
return 0;
@@ -178,6 +190,9 @@ static int __cpuidle_remove_device(struc
cpuidle_detach_driver(dev);
cpuidle_remove_sysfs(sys_dev);
list_del(>device_list);
+   wait_for_completion(>kobj_unregister);
+   per_cpu(cpuidle_devices, sys_dev->id) = NULL;
+   kfree(dev);
 
return 0;
 }
Index: 21-rc6-mm1/drivers/cpuidle/sysfs.c
===
--- 21-rc6-mm1.orig/drivers/cpuidle/sysfs.c 2007-04-17 13:41:29.0 
+0800
+++ 21-rc6-mm1/drivers/cpuidle/sysfs.c  2007-04-17 14:03:56.0 +0800
@@ -210,8 +210,16 @@ static struct sysfs_ops cpuidle_sysfs_op
.store = cpuidle_store,
 };
 
+static void cpuidle_sysfs_release(struct kobject *kobj)
+{
+   struct cpuidle_device *dev = kobj_to_cpuidledev(kobj);
+
+   complete(>kobj_unregister);
+}
+
 static struct kobj_type ktype_cpuidle = {
.sysfs_ops = _sysfs_ops,
+

Re: CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]

2007-04-17 Thread Shaohua Li

On Mon, 2007-04-16 at 22:50 -0400, Joshua Wise wrote:
 On Mon, 16 Apr 2007, Shaohua Li wrote:
  On Sat, 2007-04-14 at 01:45 +0200, Mattia Dongili wrote:
  ...
  please check if the patch at
  http://marc.info/?l=linux-acpim=117523651630038w=2 fixed the issue
 
 I have the same system as Mattia, and when I applied this patch and turned
 CPU_IDLE back on, I got a panic on boot. Unfortunately, the EIP scrolled off
 screen, so I can't get a line number.
 
 (I had the same STR breakage as him; STR did not work with CPU_IDLE turned
 on, and it did work with CPU_IDLE turned off.)
 
 I'm running +rc6+mm(April 11) on a Sony VAIO SZ.
Looks there is init order issue of sysfs files. The new refreshed patch
should fix your bug.

Signed-off-by: Shaohua Li [EMAIL PROTECTED]

Index: 21-rc6-mm1/drivers/acpi/processor_idle.c
===
--- 21-rc6-mm1.orig/drivers/acpi/processor_idle.c   2007-04-17 
13:41:29.0 +0800
+++ 21-rc6-mm1/drivers/acpi/processor_idle.c2007-04-17 14:03:56.0 
+0800
@@ -624,7 +624,7 @@ int acpi_processor_cst_has_changed(struc
return -ENODEV;
 
acpi_processor_get_power_info(pr);
-   return cpuidle_force_redetect(per_cpu(cpuidle_devices, pr-id));
+   return cpuidle_force_redetect(per_cpu(cpuidle_devices, pr-id));
 }
 
 /* proc interface */
Index: 21-rc6-mm1/drivers/cpuidle/cpuidle.c
===
--- 21-rc6-mm1.orig/drivers/cpuidle/cpuidle.c   2007-04-17 13:41:29.0 
+0800
+++ 21-rc6-mm1/drivers/cpuidle/cpuidle.c2007-04-17 14:42:17.0 
+0800
@@ -18,7 +18,7 @@
 
 #include cpuidle.h
 
-DEFINE_PER_CPU(struct cpuidle_device, cpuidle_devices);
+DEFINE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
 EXPORT_PER_CPU_SYMBOL_GPL(cpuidle_devices);
 
 DEFINE_MUTEX(cpuidle_lock);
@@ -34,13 +34,13 @@ static void (*pm_idle_old)(void);
  */
 static void cpuidle_idle_call(void)
 {
-   struct cpuidle_device *dev = __get_cpu_var(cpuidle_devices);
+   struct cpuidle_device *dev = __get_cpu_var(cpuidle_devices);
 
struct cpuidle_state *target_state;
int next_state;
 
/* check if the device is ready */
-   if (dev-status != CPUIDLE_STATUS_DOIDLE) {
+   if (!dev || dev-status != CPUIDLE_STATUS_DOIDLE) {
if (pm_idle_old)
pm_idle_old();
return;
@@ -117,19 +117,32 @@ static int cpuidle_add_device(struct sys
int cpu = sys_dev-id;
struct cpuidle_device *dev;
 
-   dev = per_cpu(cpuidle_devices, cpu);
+   dev = per_cpu(cpuidle_devices, cpu);
 
-   dev-cpu = cpu;
mutex_lock(cpuidle_lock);
if (cpu_is_offline(cpu)) {
mutex_unlock(cpuidle_lock);
return 0;
}
 
+   if (!dev) {
+   dev = kzalloc(sizeof(struct cpuidle_device), GFP_KERNEL);
+   if (!dev) {
+   mutex_unlock(cpuidle_lock);
+   return -ENOMEM;
+   }
+   init_completion(dev-kobj_unregister);
+   per_cpu(cpuidle_devices, cpu) = dev;
+   }
+   dev-cpu = cpu;
+
if (dev-status  CPUIDLE_STATUS_DETECTED) {
mutex_unlock(cpuidle_lock);
return 0;
}
+
+   cpuidle_add_sysfs(sys_dev);
+
if (cpuidle_curr_driver) {
if (cpuidle_attach_driver(dev))
goto err_ret;
@@ -146,7 +159,6 @@ static int cpuidle_add_device(struct sys
cpuidle_install_idle_handler();
 
list_add(dev-device_list, cpuidle_detected_devices);
-   cpuidle_add_sysfs(sys_dev);
dev-status |= CPUIDLE_STATUS_DETECTED;
 
 err_ret:
@@ -165,7 +177,7 @@ static int __cpuidle_remove_device(struc
 {
struct cpuidle_device *dev;
 
-   dev = per_cpu(cpuidle_devices, sys_dev-id);
+   dev = per_cpu(cpuidle_devices, sys_dev-id);
 
if (!(dev-status  CPUIDLE_STATUS_DETECTED)) {
return 0;
@@ -178,6 +190,9 @@ static int __cpuidle_remove_device(struc
cpuidle_detach_driver(dev);
cpuidle_remove_sysfs(sys_dev);
list_del(dev-device_list);
+   wait_for_completion(dev-kobj_unregister);
+   per_cpu(cpuidle_devices, sys_dev-id) = NULL;
+   kfree(dev);
 
return 0;
 }
Index: 21-rc6-mm1/drivers/cpuidle/sysfs.c
===
--- 21-rc6-mm1.orig/drivers/cpuidle/sysfs.c 2007-04-17 13:41:29.0 
+0800
+++ 21-rc6-mm1/drivers/cpuidle/sysfs.c  2007-04-17 14:03:56.0 +0800
@@ -210,8 +210,16 @@ static struct sysfs_ops cpuidle_sysfs_op
.store = cpuidle_store,
 };
 
+static void cpuidle_sysfs_release(struct kobject *kobj)
+{
+   struct cpuidle_device *dev = kobj_to_cpuidledev(kobj);
+
+   complete(dev-kobj_unregister);
+}
+
 static struct kobj_type ktype_cpuidle = {
.sysfs_ops =

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

 Sergei == Sergei Shtylyov [EMAIL PROTECTED] writes:

Sergei Hello.
Sergei John Stoffel wrote:

 I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
 and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
 disks are not longer detected and I get the following in the dmesg
 logs:

 [  148.121490] hpt37x: DPLL did not stabilize.

 Where before, under 2.6.21-rc6 I got the following:

Sergei For the moment I thought you're reporting another hpt366.c
Sergei driver breakage but then noticed the next line:

I used to think that I wanted to use that driver too, but it's not
going to work.  It's because I've got the version 1 of the chip, not
the newer version 2 or higher version.  

It looks like you really mean for me to use the hpt3x2.c driver
instead, since that's the only other one which mentions the
PCI_DEVICE_ID_TTI_HPT302 device id in it's init method.

 [  173.749349] pata_hpt37x: BIOS has not set timing clocks.
 [  173.752949] hpt37x: HPT302: Bus clock 33MHz.

SergeiObviously this was bacause of switching from PCI to DPLL
Sergeiclock. The old and new drivers are different in how they
Sergeihandle DPLL calibration though.  Could you try hpt366.c
Sergei(there's been report about its failure too recently -- not
Sergeienought details yet)?

I don't think it will work here, it won't even touch the card since
the pci_device_id won't match at all.  The htp366.c only looks at
HPT366 ids, while mine is an HPT302 id.  

As a quick note, 2.6.21-rc7 is working just fine here.  

 [  173.754409] ACPI: PCI Interrupt :03:06.0[A] - GSI 18 (level,
 low) - IRQ
 18
 [  173.758403] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2
 bmdma 0x000
 1e800 irq 18
 [  173.761396] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda
 bmdma 0x000
 1e808 irq 18
 [  173.764319] scsi6 : pata_hpt37x
 [  173.928997] ATA: abnormal status 0x78 on port 0x0001ecff
 [  173.930511] scsi7 : pata_hpt37x
 [  174.094906] ATA: abnormal status 0x8 on port 0x0001ece7
 
 Here's my lspci infomation on the board, it's an addon.  My apologies
 for the crappy word wrapping, xterms inside screen, etc. 

 03:06.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N
 (rev 01)
 Subsystem: Triones Technologies, Inc. Unknown device 0001
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr- Step
 ping- SERR+ FastB2B-
 Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
 TAbort- TAbort
 - MAbort- SERR- PERR-
 Latency: 120 (2000ns min, 2000ns max)
 Interrupt: pin A routed to IRQ 11
 Region 0: I/O ports at ecf8 [size=8]
 Region 1: I/O ports at ecf0 [size=4]
 Region 2: I/O ports at ece0 [size=8]
 Region 3: I/O ports at ecd8 [size=4]
 Region 4: I/O ports at e800 [size=256]
 Expansion ROM at f900 [disabled] [size=128K]
 Capabilities: [60] Power Management version 2
 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
 PME(D0-,D1-,D2-,D3hot
 -,D3cold-)
 Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Sergei Yeah, that's a plain HPT302 chip with the default 66 MHz
Sergei DPLL clock.

Ok, so do I need to do anything special with the next -mm release and
the next version?

Thanks,
John
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


Hello.

John Stoffel wrote:


I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:



[  148.121490] hpt37x: DPLL did not stabilize.



Where before, under 2.6.21-rc6 I got the following:


  For the moment I thought you're reporting another hpt366.c driver breakage 
but then noticed the next line:


[  173.749349] pata_hpt37x: BIOS has not set timing clocks.
[  173.752949] hpt37x: HPT302: Bus clock 33MHz.


  Obviously this was bacause of switching from PCI to DPLL clock. The old and 
new drivers are different in how they handle DPLL calibration though.  Could 
you try hpt366.c (there's been report about its failure too recently -- not 
enought details yet)?


[  173.754409] ACPI: PCI Interrupt :03:06.0[A] - GSI 18 (level,
low) - IRQ
 18
[  173.758403] ata5: PATA max UDMA/133 cmd 0x0001ecf8 ctl 0x0001ecf2
bmdma 0x000
1e800 irq 18
[  173.761396] ata6: PATA max UDMA/133 cmd 0x0001ece0 ctl 0x0001ecda
bmdma 0x000
1e808 irq 18
[  173.764319] scsi6 : pata_hpt37x
[  173.928997] ATA: abnormal status 0x78 on port 0x0001ecff
[  173.930511] scsi7 : pata_hpt37x
[  174.094906] ATA: abnormal status 0x8 on port 0x0001ece7



Here's my lspci infomation on the board, it's an addon.  My apologies
for the crappy word wrapping, xterms inside screen, etc. 



  03:06.0 RAID bus controller: Triones Technologies, Inc. HPT302/302N
  (rev 01)
  Subsystem: Triones Technologies, Inc. Unknown device 0001
  Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
  ParErr- Step
  ping- SERR+ FastB2B-
  Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
  TAbort- TAbort
  - MAbort- SERR- PERR-
  Latency: 120 (2000ns min, 2000ns max)
  Interrupt: pin A routed to IRQ 11
  Region 0: I/O ports at ecf8 [size=8]
  Region 1: I/O ports at ecf0 [size=4]
  Region 2: I/O ports at ece0 [size=8]
  Region 3: I/O ports at ecd8 [size=4]
  Region 4: I/O ports at e800 [size=256]
  Expansion ROM at f900 [disabled] [size=128K]
  Capabilities: [60] Power Management version 2
  Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
  PME(D0-,D1-,D2-,D3hot
  -,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-


  Yeah, that's a plain HPT302 chip with the default 66 MHz DPLL clock.

MBR, Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


John Stoffel wrote:


I was just testing out 2.6.21-rc6-mm1 to test some Cyclades patches
and I noticed that my HPT302 (rev1) controller with a pair of 120gb WD
disks are not longer detected and I get the following in the dmesg
logs:



[  148.121490] hpt37x: DPLL did not stabilize.



Where before, under 2.6.21-rc6 I got the following:



Sergei For the moment I thought you're reporting another hpt366.c
Sergei driver breakage but then noticed the next line:



I used to think that I wanted to use that driver too, but it's not
going to work.  It's because I've got the version 1 of the chip, not
the newer version 2 or higher version.


  So what?


It looks like you really mean for me to use the hpt3x2.c driver
instead, since that's the only other one which mentions the
PCI_DEVICE_ID_TTI_HPT302 device id in it's init method.


  I actually meant drivers/ide/pci/hpt366.c. :-)


[  173.749349] pata_hpt37x: BIOS has not set timing clocks.
[  173.752949] hpt37x: HPT302: Bus clock 33MHz.



SergeiObviously this was bacause of switching from PCI to DPLL
Sergeiclock. The old and new drivers are different in how they
Sergeihandle DPLL calibration though.  Could you try hpt366.c
Sergei(there's been report about its failure too recently -- not
Sergeienought details yet)?



I don't think it will work here, it won't even touch the card since
the pci_device_id won't match at all.  The htp366.c only looks at
HPT366 ids, while mine is an HPT302 id.


  The driver I've named should work (unless something is broken somewhere, that 
is).
Basically, it uses wider range to calibrate DPLL.


As a quick note, 2.6.21-rc7 is working just fine here.


  Yeah, it's still using PCI clock.


Ok, so do I need to do anything special with the next -mm release and
the next version?


  Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).


Thanks,
John


MBR, Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression

2007-04-17 Thread Alan Cox

  Ok, so do I need to do anything special with the next -mm release and
  the next version?
 
Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let me know.
It means that Sergei's DPLL sync code seems to work better than the
vendor code and its time to swap it over.

Oh how I love highpoint PATA

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression


  Ok, so do I need to do anything special with the next -mm release and
  the next version?
 
 Well, let Alan decide that (2Alan: and I said that HPT code is bogus :-).

Alan Try drivers/ide/pci/hpt366 - if that works grab a dmesg and let
Alan me know.  It means that Sergei's DPLL sync code seems to work
Alan better than the vendor code and its time to swap it over.

Ok, I'll give that a whirl under 2.6.21-rc7 tonight.  I'll build them
in modular so I can switch around more easily.  I hope.  :]

Alan Oh how I love highpoint PATA

It seemed like a good buy at the time when I was researching these
things.  Best bang for the buck I guess.  It's a RocketRaid133 card,
but obviously I got a bum deal somewhere down the line.

Now I've got a Sil3114 SATA controller, which seems to be working just
fine now.  Hopefully it won't have problems like this!

John

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.21-rc6-mm1 ATA HPT37x regression