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. > > > 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 Any news and/or patch concerning this problem ?. Not intended to stress you but time goes on... Do you think a solution could be found in a relatively short timeframe (and i will delay a bit final installation) or is it better to go without bonding and do an upgrade later ?. Vincent > > --- > -Jay Vosburgh, IBM Linux Technology Center, [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. 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 Any news and/or patch concerning this problem ?. Not intended to stress you but time goes on... Do you think a solution could be found in a relatively short timeframe (and i will delay a bit final installation) or is it better to go without bonding and do an upgrade later ?. Vincent --- -Jay Vosburgh, IBM Linux Technology Center, [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: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)
Le Sunday 29 April 2007 13:18:31 Jiri Kosina, vous avez écrit : > > Hi Vincent, Hi Jiri, > > yes, the device is messed up, but it shouldn't have any consequences for > you - the HID driver is able to correctly handle that, so as soon as we > don't need to add any extra quirks for such device, everything should be > fine. I have removed the WARN_ON from the code in my tree. I think we > still don't want users to add quirks for such broken devices (as it would > collide with hid_blakclist[] terminator), so I have left the initial > condition in usbhid_modify_dquirk() untouched. > Thanks a lot for the explanation and the patch, now i better understand the "problem". Sorry to have bother you with just noise. The patch will certainly be of some help with dumb user (who have dump hardware ) like me. I have very appreciate the attention you ( and all other from this feed ) have take with me. So a big thanks for your work and the next time (if any), i will try to better analyse the problem to avoid unnecessary work. Vincent - 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)
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
> > No, it isn't a problem in the USB core. The device itself is messed up;
> > it really does report idVendor and idProduct both equal to 0.
> So is it just a scary trace but without consequence that i could ignored
> ? May i ask you what is the device which is messed up ? ( Maybe should i
> change it ? )
Hi Vincent,
yes, the device is messed up, but it shouldn't have any consequences for
you - the HID driver is able to correctly handle that, so as soon as we
don't need to add any extra quirks for such device, everything should be
fine. I have removed the WARN_ON from the code in my tree. I think we
still don't want users to add quirks for such broken devices (as it would
collide with hid_blakclist[] terminator), so I have left the initial
condition in usbhid_modify_dquirk() untouched.
From: Jiri Kosina <[EMAIL PROTECTED]>
USB HID: don't warn on idVendor == 0
It turns out that there are broken devices out there that incorrectly
report VID/PID as 0x000, see http://lkml.org/lkml/2007/4/27/496
Therefore we should not confuse users by dumping warnings and stacktraces
in such situation. It is not possible to add quirks for such horribly
broken devices, but currently that's not needed.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 27188bd..17a8755 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -477,8 +477,6 @@ static struct hid_blacklist *usbhid_exis
struct quirks_list_struct *q;
struct hid_blacklist *bl_entry = NULL;
- WARN_ON(idVendor == 0);
-
list_for_each_entry(q, _list, node) {
if (q->hid_bl_item.idVendor == idVendor &&
q->hid_bl_item.idProduct == idProduct) {
-
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)
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
No, it isn't a problem in the USB core. The device itself is messed up;
it really does report idVendor and idProduct both equal to 0.
So is it just a scary trace but without consequence that i could ignored
? May i ask you what is the device which is messed up ? ( Maybe should i
change it ? )
Hi Vincent,
yes, the device is messed up, but it shouldn't have any consequences for
you - the HID driver is able to correctly handle that, so as soon as we
don't need to add any extra quirks for such device, everything should be
fine. I have removed the WARN_ON from the code in my tree. I think we
still don't want users to add quirks for such broken devices (as it would
collide with hid_blakclist[] terminator), so I have left the initial
condition in usbhid_modify_dquirk() untouched.
From: Jiri Kosina [EMAIL PROTECTED]
USB HID: don't warn on idVendor == 0
It turns out that there are broken devices out there that incorrectly
report VID/PID as 0x000, see http://lkml.org/lkml/2007/4/27/496
Therefore we should not confuse users by dumping warnings and stacktraces
in such situation. It is not possible to add quirks for such horribly
broken devices, but currently that's not needed.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 27188bd..17a8755 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -477,8 +477,6 @@ static struct hid_blacklist *usbhid_exis
struct quirks_list_struct *q;
struct hid_blacklist *bl_entry = NULL;
- WARN_ON(idVendor == 0);
-
list_for_each_entry(q, dquirks_list, node) {
if (q-hid_bl_item.idVendor == idVendor
q-hid_bl_item.idProduct == idProduct) {
-
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 Sunday 29 April 2007 13:18:31 Jiri Kosina, vous avez écrit : Hi Vincent, Hi Jiri, yes, the device is messed up, but it shouldn't have any consequences for you - the HID driver is able to correctly handle that, so as soon as we don't need to add any extra quirks for such device, everything should be fine. I have removed the WARN_ON from the code in my tree. I think we still don't want users to add quirks for such broken devices (as it would collide with hid_blakclist[] terminator), so I have left the initial condition in usbhid_modify_dquirk() untouched. Thanks a lot for the explanation and the patch, now i better understand the problem. Sorry to have bother you with just noise. The patch will certainly be of some help with dumb user (who have dump hardware ) like me. I have very appreciate the attention you ( and all other from this feed ) have take with me. So a big thanks for your work and the next time (if any), i will try to better analyse the problem to avoid unnecessary work. Vincent - 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: [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)
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)
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)
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)
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)
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)
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)
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: 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)
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: [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
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
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/
USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)
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: 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)
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: [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
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
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/
[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
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
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: [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: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > > I think using the 'shutdown' mode of suspend would be better. > > > > > > > There's a little > > > > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > > > > platform_finish() after > > > > > > > device_resume(), some systems may be broken ... > > > > > > > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > > > > > > > I think the patch helps, because it makes the ACPI magic be done > > > > > while the > > > > > i8042's .resume() is being executed. > > > > > > > > > > Which makes me think the following patch might help: > > > > > > > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. > > > > > > Well, this means i8042 can be ruled out, so the problem probably is > > > related > > > to the ACPI resume which makes it _much_ more difficult to debug. > > > > > > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. > > > as > > > modules, boot the kernel with init=/bin/bash and see if the problem is > > > still > > > present (please keep CONFIG_SERIO_I8042 unset just in case)? > > > > > > Rafael > > > > I first tried it with acpi+cpufreq completely disabled (works). > > Then I tried it with acpi enabled, but everything as modules and > > those not loaded (init=/bin/bash, hangs at second suspend). > > Have you tried with ACPI and without cpufreq? Yes, the second one was with ACPI enabled and cpufreq disabled (CONFIG_X86_ACPI_CPUFREQ is not set). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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-pm] Linux 2.6.21-rc6
On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > > > Rafael J. Wysocki wrote: > > > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > I think using the 'shutdown' mode of suspend would be better. > > > > > > There's a little > > > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > > > platform_finish() after > > > > > > device_resume(), some systems may be broken ... > > > > > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > > > > > I think the patch helps, because it makes the ACPI magic be done while > > > > the > > > > i8042's .resume() is being executed. > > > > > > > > Which makes me think the following patch might help: > > > > > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. > > > > Well, this means i8042 can be ruled out, so the problem probably is related > > to the ACPI resume which makes it _much_ more difficult to debug. > > > > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as > > modules, boot the kernel with init=/bin/bash and see if the problem is still > > present (please keep CONFIG_SERIO_I8042 unset just in case)? > > > > Rafael > > I first tried it with acpi+cpufreq completely disabled (works). > Then I tried it with acpi enabled, but everything as modules and > those not loaded (init=/bin/bash, hangs at second suspend). Have you tried with ACPI and without cpufreq? Rafael - 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-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > I think using the 'shutdown' mode of suspend would be better. > > > > > There's a little > > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > > platform_finish() after > > > > > device_resume(), some systems may be broken ... > > > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > > > I think the patch helps, because it makes the ACPI magic be done while the > > > i8042's .resume() is being executed. > > > > > > Which makes me think the following patch might help: > > > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. > > Well, this means i8042 can be ruled out, so the problem probably is related > to the ACPI resume which makes it _much_ more difficult to debug. > > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as > modules, boot the kernel with init=/bin/bash and see if the problem is still > present (please keep CONFIG_SERIO_I8042 unset just in case)? > > Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7 # Sun Apr 22 09:26:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y #
Re: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 17:14, David Brownell wrote: On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? I think the patch helps, because it makes the ACPI magic be done while the i8042's .resume() is being executed. Which makes me think the following patch might help: Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7 # Sun Apr 22 09:26:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y
Re: [linux-pm] Linux 2.6.21-rc6
On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 17:14, David Brownell wrote: On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? I think the patch helps, because it makes the ACPI magic be done while the i8042's .resume() is being executed. Which makes me think the following patch might help: Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). Have you tried with ACPI and without cpufreq? Rafael - 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-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 17:14, David Brownell wrote: On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? I think the patch helps, because it makes the ACPI magic be done while the i8042's .resume() is being executed. Which makes me think the following patch might help: Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). Have you tried with ACPI and without cpufreq? Yes, the second one was with ACPI enabled and cpufreq disabled (CONFIG_X86_ACPI_CPUFREQ is not set). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Sun, 15 Apr 2007 11:05:53 +1000 > I wrote: > > > So this doesn't change process_input_packet(), which treats the case > > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of > > I meant "the second byte is NOT 0x03", of course. I've applied this patch, thanks 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>>
>> So this doesn't change process_input_packet(), which treats the case
>> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
>> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
>> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
>> the RFC does envision the possibility of receiving frames where the
>> control field has values other than 0x03.
>
> Your fix is probably needed too. However, I think the issue that Patrick
> was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
> we'd still have a problem there.
Nevermind, I mixed up != with == so your patch is all we need.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Your fix is probably needed too. However, I think the issue that Patrick was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore we'd still have a problem there. I tested Paul's patch for last few days and I think everything seems ok. The system is stable. Regards Bartek - 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Your fix is probably needed too. However, I think the issue that Patrick was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore we'd still have a problem there. I tested Paul's patch for last few days and I think everything seems ok. The system is stable. Regards Bartek - 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Herbert Xu [EMAIL PROTECTED] wrote:
Paul Mackerras [EMAIL PROTECTED] wrote:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
the RFC does envision the possibility of receiving frames where the
control field has values other than 0x03.
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
Nevermind, I mixed up != with == so your patch is all we need.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Paul Mackerras [EMAIL PROTECTED] Date: Sun, 15 Apr 2007 11:05:53 +1000 I wrote: So this doesn't change process_input_packet(), which treats the case where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of I meant the second byte is NOT 0x03, of course. I've applied this patch, thanks 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hi Paul:
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
> the RFC does envision the possibility of receiving frames where the
> control field has values other than 0x03.
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
> David Miller writes:
>
>> Here is Patrick McHardy's patch:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
> the RFC does envision the possibility of receiving frames where the
> control field has values other than 0x03.
>
> Therefore I think this patch is probably better. Could people try it
> out and let me know if it fixes the problem?
>
> Paul.
>
> diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
> index 933e2f3..caabbc4 100644
> --- a/drivers/net/ppp_async.c
> +++ b/drivers/net/ppp_async.c
> @@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap)
>
> /* check for address/control and protocol compression */
> p = skb->data;
> - if (p[0] == PPP_ALLSTATIONS && p[1] == PPP_UI) {
> + if (p[0] == PPP_ALLSTATIONS) {
> /* chop off address/control */
> - if (skb->len < 3)
> + if (p[1] != PPP_UI || skb->len < 3)
> goto err;
> p = skb_pull(skb, 2);
> }
Let's look farther:
>proto = p[0];
>if (proto & 1) {
>/* protocol is compressed */
>skb_push(skb, 1)[0] = 0;
BTW - about Patrick's patch:
skb_push seems to be dependent here on the 1-st char of
skb->data, if above (p[0] != PPP_ALLSTATIONS), but on the
3-rd char otherwise (after skb_pull). But, Patrick's patch
reserves the place for this, looking always at 1-st char
(buf[0]) independently of PPP_ALLSTATIONS char presence,
or otherwise - always treating this char as protocol char.
It looks safe because of PPP_ALLSTATION current value,
but isn't too understandable.
On the other hand, without any reservation in the
ppp_async_input for the (buf[0] == PPP_ALLSTATIONS) case,
probably 4-byte alignement isn't achieved as planned.
>} else {
>if (skb->len < 2)
>goto err;
>proto = (proto << 8) + p[1];
>if (proto == PPP_LCP)
>async_lcp_peek(ap, p, skb->len, 1);
>}
>
>/* queue the frame to be processed */
>skb->cb[0] = ap->state;
>skb_queue_tail(>rqueue, skb);
>ap->rpkt = NULL;
>ap->state = 0;
>return;
>
> err:
>/* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */
>ap->state = SC_PREV_ERROR;
>if (skb) {
>/* make skb appear as freshly allocated */
Probably this isn't always true and here the problem
started...
>skb_trim(skb, 0);
>skb_reserve(skb, - skb_headroom(skb));
Isn't here lost e.g. NET_SKB_PAD probably reserved by
dev_alloc_skb?
On the other hand - this kind of pad can very good hide
similar reservation problems in many other places - maybe
it should be omitted or somehow counted in WARNs when some
debugging options are active?
Regards,
Jarek P.
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
David Miller writes:
Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
the RFC does envision the possibility of receiving frames where the
control field has values other than 0x03.
Therefore I think this patch is probably better. Could people try it
out and let me know if it fixes the problem?
Paul.
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 933e2f3..caabbc4 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap)
/* check for address/control and protocol compression */
p = skb-data;
- if (p[0] == PPP_ALLSTATIONS p[1] == PPP_UI) {
+ if (p[0] == PPP_ALLSTATIONS) {
/* chop off address/control */
- if (skb-len 3)
+ if (p[1] != PPP_UI || skb-len 3)
goto err;
p = skb_pull(skb, 2);
}
Let's look farther:
proto = p[0];
if (proto 1) {
/* protocol is compressed */
skb_push(skb, 1)[0] = 0;
BTW - about Patrick's patch:
skb_push seems to be dependent here on the 1-st char of
skb-data, if above (p[0] != PPP_ALLSTATIONS), but on the
3-rd char otherwise (after skb_pull). But, Patrick's patch
reserves the place for this, looking always at 1-st char
(buf[0]) independently of PPP_ALLSTATIONS char presence,
or otherwise - always treating this char as protocol char.
It looks safe because of PPP_ALLSTATION current value,
but isn't too understandable.
On the other hand, without any reservation in the
ppp_async_input for the (buf[0] == PPP_ALLSTATIONS) case,
probably 4-byte alignement isn't achieved as planned.
} else {
if (skb-len 2)
goto err;
proto = (proto 8) + p[1];
if (proto == PPP_LCP)
async_lcp_peek(ap, p, skb-len, 1);
}
/* queue the frame to be processed */
skb-cb[0] = ap-state;
skb_queue_tail(ap-rqueue, skb);
ap-rpkt = NULL;
ap-state = 0;
return;
err:
/* frame had an error, remember that, reset SC_TOSS SC_ESCAPE */
ap-state = SC_PREV_ERROR;
if (skb) {
/* make skb appear as freshly allocated */
Probably this isn't always true and here the problem
started...
skb_trim(skb, 0);
skb_reserve(skb, - skb_headroom(skb));
Isn't here lost e.g. NET_SKB_PAD probably reserved by
dev_alloc_skb?
On the other hand - this kind of pad can very good hide
similar reservation problems in many other places - maybe
it should be omitted or somehow counted in WARNs when some
debugging options are active?
Regards,
Jarek P.
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hi Paul:
Paul Mackerras [EMAIL PROTECTED] wrote:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
the RFC does envision the possibility of receiving frames where the
control field has values other than 0x03.
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Bartek wrote: > 2007/4/14, David Miller <[EMAIL PROTECTED]>: > >> From: Patrick McHardy <[EMAIL PROTECTED]> >> Date: Thu, 12 Apr 2007 07:43:39 +0200 >> >> > It seems we fail to reserve enough headroom for the case >> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. >> > >> > Can you try this patch please? >> >> Any confirmation of this fix yet? > > > I'm testing that patch, till now everything seems ok. Please test Paul's patch instead and keep everyone CCed. - 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-pm] Linux 2.6.21-rc6
On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > > > > > > single core CPU. > > > > > > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment > > > would be to disable the EHCI (high speed USB) support in BIOS, to make > > > for a simpler hardware configuration, and see if that makes BIOS happier. > > > (Or better, just take EHCI out of your Linux config.) Likewise, taking > > > the 8042 drivers out of Linux. > > > > > > I wouldn't be surprised if those factors didn't matter, but it'd be good > > > to rule them out. > > > > I think the disabling of i8042 support might help. > > Still hangs with "# CONFIG_SERIO_I8042 is not set". > > > > > Dmitry, could you please have a look? > > > > > > > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > > > > as USB legacy support is disabled (however without legacy support I > > > > > can't use the USB keyboard to control grub). > > > > > > > > I think using the 'shutdown' mode of suspend would be better. There's > > > > a little > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > platform_finish() after > > > > device_resume(), some systems may be broken ... > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > I think the patch helps, because it makes the ACPI magic be done while the > > i8042's .resume() is being executed. > > > > Which makes me think the following patch might help: > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael - 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-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> >
> > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > > single core CPU.
> >
> > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> > would be to disable the EHCI (high speed USB) support in BIOS, to make
> > for a simpler hardware configuration, and see if that makes BIOS happier.
> > (Or better, just take EHCI out of your Linux config.) Likewise, taking
> > the 8042 drivers out of Linux.
> >
> > I wouldn't be surprised if those factors didn't matter, but it'd be good
> > to rule them out.
>
> I think the disabling of i8042 support might help.
Still hangs with "# CONFIG_SERIO_I8042 is not set".
> > > Dmitry, could you please have a look?
> > >
> > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > > as USB legacy support is disabled (however without legacy support I
> > > > can't use the USB keyboard to control grub).
> > >
> > > I think using the 'shutdown' mode of suspend would be better. There's a
> > > little
> > > point in using 'platform' on desktop systems anyway.
> > >
> > > Frankly, I don't know what to do about it. If we move platform_finish()
> > > after
> > > device_resume(), some systems may be broken ...
> >
> > What I'm curious about is exactly why the patch matters. What ACPI
> > magic is being invoked to confuse, or unconfuse, those controllers?
>
> I think the patch helps, because it makes the ACPI magic be done while the
> i8042's .resume() is being executed.
>
> Which makes me think the following patch might help:
Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
> drivers/input/serio/i8042.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
> ===
> --- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
> 12:15:19.0 +0200
> +++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
> 18:30:01.0 +0200
> @@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
> static int i8042_suspend(struct platform_device *dev, pm_message_t state)
> {
> if (dev->dev.power.power_state.event != state.event) {
> - if (state.event == PM_EVENT_SUSPEND)
> + if (state.event == PM_EVENT_SUSPEND
> + || state.event == PM_EVENT_PRETHAW)
> i8042_controller_reset();
>
> dev->dev.power.power_state = state;
> -
> 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/
>
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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 2.6.21-rc6
On Sunday, 15 April 2007 20:50, Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote: > > > On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > > > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see > > > > > > that the second suspend hangs at "i8042 i8042: EARLY resume". > > > > > > This is kinda interesting because I'm normally using a USB keyboard > > > > > > and sure enough, if I hook up a normal keyboard and disable USB > > > > > > legacy support in the BIOS, then suspend to disk works multiple > > > > > > times. I'd still rather like to use my USB keyboard though. ;) > > > > > > > > Well, I think that when you're using the USB keyboard and the USB legacy > > > > support, the i8042 driver thinks it has a keyboard to handle and tries > > > > to > > > > handle it during the suspend, which fails. I don't know why it fails > > > > during > > > > the second suspend, though. > > > > > > > > Dmitry, could you please have a look? > > > > > > > > > > This is wierd as i8042 does not use suspend_late/resume_early hooks and > > > so it is impossible for it to hang there. None of input drivers use these > > > hooks. Could it be that some other driver _after_ i8042 hangs? > > > > Yes. > > > > Tobias, can you please post the dmesg output from after a successful > > suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode? > > Here you go: Thanks. [--snip--] > [10233.239209] swsusp: critical section: > [10233.253579] swsusp: Need to copy 125818 pages > [10233.253688] swsusp: Normal pages needed: 125818 + 1024 + 22, available > pages: 135940 > [ 43.795445] Extended CMOS year: 2000 > [ 43.798813] svm_cpu_init: svm_data is NULL on 0 > [ 43.800886] pci :00:00.0: EARLY resume > [ 43.800994] pci :00:01.0: EARLY resume > [ 43.801102] nForce2_smbus :00:01.1: EARLY resume > [ 43.801210] pci :00:01.2: EARLY resume > [ 43.801317] ohci_hcd :00:02.0: EARLY resume > [ 43.801425] ehci_hcd :00:02.1: EARLY resume > [ 43.801532] pata_amd :00:04.0: EARLY resume > [ 43.801640] pci :00:06.0: EARLY resume > [ 43.801747] pci :00:06.1: EARLY resume > [ 43.801854] forcedeth :00:08.0: EARLY resume > [ 43.801962] forcedeth :00:09.0: EARLY resume > [ 43.802070] pcieport-driver :00:0a.0: EARLY resume > [ 43.802177] pcieport-driver :00:0b.0: EARLY resume > [ 43.802289] pcieport-driver :00:0c.0: EARLY resume > [ 43.802398] pcieport-driver :00:0d.0: EARLY resume > [ 43.802506] pcieport-driver :00:0e.0: EARLY resume > [ 43.802613] pcieport-driver :00:0f.0: EARLY resume > [ 43.802721] pci :00:18.0: EARLY resume > [ 43.802828] pci :00:18.1: EARLY resume > [ 43.802935] pci :00:18.2: EARLY resume > [ 43.803043] k8temp :00:18.3: EARLY resume > [ 43.803150] e100 :01:07.0: EARLY resume > [ 43.803257] EMU10K1_Audigy :01:08.0: EARLY resume > [ 43.803365] Emu10k1_gameport :01:08.1: EARLY resume > [ 43.803473] pci :01:0b.0: EARLY resume > [ 43.803580] ahci :06:00.0: EARLY resume > [ 43.803695] pci :06:00.1: EARLY resume > [ 43.803802] pci :07:00.0: EARLY resume > [ 43.803910] pci :07:00.1: EARLY resume > [ 43.804018] platform bluetooth: EARLY resume > [ 43.804126] platform pcspkr: EARLY resume > [ 43.804233] platform vesafb.0: EARLY resume > [ 43.804348] i8042 i8042: EARLY resume > [ 43.804460] PM: Image restored successfully. > [ 43.924837] acpi acpi_system:00: resuming > [ 43.924946] button button_power:00: resuming > [ 43.925054] processor ACPI0007:00: resuming > [ 43.925161] processor ACPI0007:01: resuming > [ 43.925268] acpi device:00: resuming [--snip--] Hmm, it looks like i8042 is the last thing on the dpm_off_irq list. Still, if the ACPI resume fails, the next messages may not make it to the console (it's not very probable, though). I've tried to reproduce your problem on another box on which I have no PS/2 keyboard (USB keyboard/mouse only) and the USB legacy support set, but I can't. There must be something very special in your configuration. Have you tried the patch that I posted some time ago (appended again for convenience)? Rafael drivers/input/serio/i8042.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
Re: [linux-pm] Linux 2.6.21-rc6
On Sunday 15 April 2007 9:37 am, Rafael J. Wysocki wrote:
>
> Which makes me think the following patch might help:
>
> drivers/input/serio/i8042.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
> ===========
> --- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
> 12:15:19.00000 +0200
> +++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
> 18:30:01.0 +0200
> @@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
> static int i8042_suspend(struct platform_device *dev, pm_message_t state)
> {
> if (dev->dev.power.power_state.event != state.event) {
> - if (state.event == PM_EVENT_SUSPEND)
> + if (state.event == PM_EVENT_SUSPEND
> + || state.event == PM_EVENT_PRETHAW)
Yeah, lack of PRETHAW support could be an issue. As you may recall,
it was added because otherwise statically linked USB host controllers
came up under the mistaken belief that they were getting a real resume
event rather than a restart-after-power-off ... and there needed to be
a way to force a hard reset. Seems like a similar issue here.
- Dave
> i8042_controller_reset();
>
> dev->dev.power.power_state = state;
>
-
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-pm] Linux 2.6.21-rc6
On Sunday, 15 April 2007 17:14, David Brownell wrote:
> On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
>
> > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > single core CPU.
>
> And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> would be to disable the EHCI (high speed USB) support in BIOS, to make
> for a simpler hardware configuration, and see if that makes BIOS happier.
> (Or better, just take EHCI out of your Linux config.) Likewise, taking
> the 8042 drivers out of Linux.
>
> I wouldn't be surprised if those factors didn't matter, but it'd be good
> to rule them out.
I think the disabling of i8042 support might help.
> > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
> > > > that the second suspend hangs at "i8042 i8042: EARLY resume".
> > > > This is kinda interesting because I'm normally using a USB keyboard
> > > > and sure enough, if I hook up a normal keyboard and disable USB
> > > > legacy support in the BIOS, then suspend to disk works multiple
> > > > times. I'd still rather like to use my USB keyboard though. ;)
> >
> > Well, I think that when you're using the USB keyboard and the USB legacy
> > support, the i8042 driver thinks it has a keyboard to handle and tries to
> > handle it during the suspend, which fails. I don't know why it fails during
> > the second suspend, though.
>
> The "legacy" support in at least some cases involves BIOS having a
> small USB stack -- enough to handle a keyboard or mouse in "boot mode"
> (plus sometimes a USB disk or CDROM) -- and poking the i8042 chip to
> act as if *IT* received the data bytes that really came over USB.
That's what happens here, I think.
> I sure don't know the ins-and-outs of such schemes (ISTR there are
> others), but my guess is that either the 8042 or OHCI got confused,
> at least in conjunction with the lowlevel magic ACPI was doing.
Yes.
> That's all black magic though, as far as I can understand it ...
Well, my theory is the following:
Without the patch, platform_finish() runs before the i8042's .resume() which is
done as though a real keyboard were present, but the ACPI magic is not done
and this confuses the heck out of the controller. Still, it doesn't go mad at
this point just yet (it probably isn't fully functional either, although we
don't see that, because it's not really used), but next, during the subsequent
suspend, it gets poked while device_power_up() is running and goes belly
up.
> > Dmitry, could you please have a look?
> >
> > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > as USB legacy support is disabled (however without legacy support I
> > > can't use the USB keyboard to control grub).
> >
> > I think using the 'shutdown' mode of suspend would be better. There's a
> > little
> > point in using 'platform' on desktop systems anyway.
> >
> > Frankly, I don't know what to do about it. If we move platform_finish()
> > after
> > device_resume(), some systems may be broken ...
>
> What I'm curious about is exactly why the patch matters. What ACPI
> magic is being invoked to confuse, or unconfuse, those controllers?
I think the patch helps, because it makes the ACPI magic be done while the
i8042's .resume() is being executed.
Which makes me think the following patch might help:
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev->dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset();
dev->dev.power.power_state = state;
-
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 2.6.21-rc6
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote: > On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see > > > > that the second suspend hangs at "i8042 i8042: EARLY resume". > > > > This is kinda interesting because I'm normally using a USB keyboard > > > > and sure enough, if I hook up a normal keyboard and disable USB > > > > legacy support in the BIOS, then suspend to disk works multiple > > > > times. I'd still rather like to use my USB keyboard though. ;) > > > > Well, I think that when you're using the USB keyboard and the USB legacy > > support, the i8042 driver thinks it has a keyboard to handle and tries to > > handle it during the suspend, which fails. I don't know why it fails during > > the second suspend, though. > > > > Dmitry, could you please have a look? > > > > This is wierd as i8042 does not use suspend_late/resume_early hooks and > so it is impossible for it to hang there. None of input drivers use these > hooks. Could it be that some other driver _after_ i8042 hangs? Yes. Tobias, can you please post the dmesg output from after a successful suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode? > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > > as USB legacy support is disabled (however without legacy support I > > > can't use the USB keyboard to control grub). > > > > I think using the 'shutdown' mode of suspend would be better. There's a > > little > > point in using 'platform' on desktop systems anyway. > > > > Frankly, I don't know what to do about it. If we move platform_finish() > > after > > device_resume(), some systems may be broken and I think there are more such > > systems than there are systems that set USB legacy support in the BIOS and > > have no PS/2 keyboards attached. > > I would say that every box that does not use PS/2 keyboard does this. Quite some people I know use USB keyboards with notebooks, but in these cases the PS/2 keyboard is still attached (except for notebooks in which the built-in keyboard is a USB one, that is). > IOW every box with USB keyboard has legacy emulation turned on so quite > few of them... I have such a machine nearby, so I'll see if I can reproduce the problem. Greetings, Rafael - 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-pm] Linux 2.6.21-rc6
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > > > single core CPU. And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment would be to disable the EHCI (high speed USB) support in BIOS, to make for a simpler hardware configuration, and see if that makes BIOS happier. (Or better, just take EHCI out of your Linux config.) Likewise, taking the 8042 drivers out of Linux. I wouldn't be surprised if those factors didn't matter, but it'd be good to rule them out. > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see > > > that the second suspend hangs at "i8042 i8042: EARLY resume". > > > This is kinda interesting because I'm normally using a USB keyboard > > > and sure enough, if I hook up a normal keyboard and disable USB > > > legacy support in the BIOS, then suspend to disk works multiple > > > times. I'd still rather like to use my USB keyboard though. ;) > > Well, I think that when you're using the USB keyboard and the USB legacy > support, the i8042 driver thinks it has a keyboard to handle and tries to > handle it during the suspend, which fails. I don't know why it fails during > the second suspend, though. The "legacy" support in at least some cases involves BIOS having a small USB stack -- enough to handle a keyboard or mouse in "boot mode" (plus sometimes a USB disk or CDROM) -- and poking the i8042 chip to act as if *IT* received the data bytes that really came over USB. I sure don't know the ins-and-outs of such schemes (ISTR there are others), but my guess is that either the 8042 or OHCI got confused, at least in conjunction with the lowlevel magic ACPI was doing. That's all black magic though, as far as I can understand it ... > Dmitry, could you please have a look? > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > as USB legacy support is disabled (however without legacy support I > > can't use the USB keyboard to control grub). > > I think using the 'shutdown' mode of suspend would be better. There's a > little > point in using 'platform' on desktop systems anyway. > > Frankly, I don't know what to do about it. If we move platform_finish() after > device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? - Dave - 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 2.6.21-rc6
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see > > > that the second suspend hangs at "i8042 i8042: EARLY resume". > > > This is kinda interesting because I'm normally using a USB keyboard > > > and sure enough, if I hook up a normal keyboard and disable USB > > > legacy support in the BIOS, then suspend to disk works multiple > > > times. I'd still rather like to use my USB keyboard though. ;) > > Well, I think that when you're using the USB keyboard and the USB legacy > support, the i8042 driver thinks it has a keyboard to handle and tries to > handle it during the suspend, which fails. I don't know why it fails during > the second suspend, though. > > Dmitry, could you please have a look? > This is wierd as i8042 does not use suspend_late/resume_early hooks and so it is impossible for it to hang there. None of input drivers use these hooks. Could it be that some other driver _after_ i8042 hangs? > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > as USB legacy support is disabled (however without legacy support I > > can't use the USB keyboard to control grub). > > I think using the 'shutdown' mode of suspend would be better. There's a > little > point in using 'platform' on desktop systems anyway. > > Frankly, I don't know what to do about it. If we move platform_finish() after > device_resume(), some systems may be broken and I think there are more such > systems than there are systems that set USB legacy support in the BIOS and > have no PS/2 keyboards attached. I would say that every box that does not use PS/2 keyboard does this. IOW every box with USB keyboard has legacy emulation turned on so quite few of them... -- Dmitry - 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 2.6.21-rc6
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > > > Rafael J. Wysocki wrote: > > > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > > > Tobias Diedrich wrote: > > > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad > > > > > > > > > > > commit > > > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > > > that device_suspend() is > > > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > > > platform_finish() is called after > > > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > > > indicated by the recent > > > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit > > > > > > > > > > > from -rc6. :) > > > > > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem > > > > > > > > > > when > > > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > > > and I even flagged that message in my local folder, but > > > > > > > > > apparently forgot > > > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > > > described in > > > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > > > > > But it's quite possible that you are running into a different > > > > > > > > issue > > > > > > > > exposed by this commit. > > > > > > > > > > > > > > Yes, it's likely. > > > > > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, > > > > > > > but my hardware > > > > > > > is certainly different. Which suspend mode do you use? If > > > > > > > that's "platform", > > > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > > > > > Sure. > > > > > > shutdown/reboot works fine, only platform is broken. > > > > > > > > > > Thanks. > > > > > > > > > > Now, I suspect the problem is somehow related to the hardware, so it > > > > > would help > > > > > a lot if we could identify the piece of hardware (or driver) involved. > > > > > > > > > > AFAICT, your system is a non-SMP one, so we can rule out > > > > > disable/enable_nonboot_cpus(). To confirm that the problem is > > > > > related to > > > > > platform_finish(), can you please apply the appended debug patch and > > > > > see if the suspend in the 'platform' mode works with it? > > > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > > single core CPU. > > > > > > > > > Also, would that be feasible for you to use 'shutdown' as a > > > > > workaround in case > > > > > the source of the problem is difficult to find and/or fix? > > > > > > > > I guess so, but the below patch fixes the problem. :) > > > > > > Well, I thought it would, but it also would break some other people's > > > systems. > > > That's the _real_ problem. Let's see if we can learn more. > > > > > > Can you please revert it for now, apply the appended one and try to > > > suspend/resume twice in the
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
2007/4/14, David Miller <[EMAIL PROTECTED]>: From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 12 Apr 2007 07:43:39 +0200 > It seems we fail to reserve enough headroom for the case > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > Can you try this patch please? Any confirmation of this fix yet? I'm testing that patch, till now everything seems ok. Regards Bartek - 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 2.6.21-rc6
Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > > Rafael J. Wysocki wrote: > > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > > Rafael J. Wysocki wrote: > > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > > Tobias Diedrich wrote: > > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > > that device_suspend() is > > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > > platform_finish() is called after > > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > > indicated by the recent > > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit > > > > > > > > > > from -rc6. :) > > > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > > and I even flagged that message in my local folder, but > > > > > > > > apparently forgot > > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > > described in > > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > > > But it's quite possible that you are running into a different > > > > > > > issue > > > > > > > exposed by this commit. > > > > > > > > > > > > Yes, it's likely. > > > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but > > > > > > my hardware > > > > > > is certainly different. Which suspend mode do you use? If that's > > > > > > "platform", > > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > > > Sure. > > > > > shutdown/reboot works fine, only platform is broken. > > > > > > > > Thanks. > > > > > > > > Now, I suspect the problem is somehow related to the hardware, so it > > > > would help > > > > a lot if we could identify the piece of hardware (or driver) involved. > > > > > > > > AFAICT, your system is a non-SMP one, so we can rule out > > > > disable/enable_nonboot_cpus(). To confirm that the problem is related > > > > to > > > > platform_finish(), can you please apply the appended debug patch and > > > > see if the suspend in the 'platform' mode works with it? > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > single core CPU. > > > > > > > Also, would that be feasible for you to use 'shutdown' as a workaround > > > > in case > > > > the source of the problem is difficult to find and/or fix? > > > > > > I guess so, but the below patch fixes the problem. :) > > > > Well, I thought it would, but it also would break some other people's > > systems. > > That's the _real_ problem. Let's see if we can learn more. > > > > Can you please revert it for now, apply the appended one and try to > > suspend/resume twice in the 'platform' mode (it may or may not work)? > > Ok. The patch doesn't apply cleanly to 2.6.21-rc6: > |patching file kernel/power/disk.c > |Hunk #1 FAILED at 267. > |Hunk #2 succeeded at 265 (offset -23 lines). > |1 out of 2 hunks FAILED -- saving rejects to file > |kernel/power/disk.c.rej > >
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > Tobias Diedrich wrote: > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > that device_suspend() is > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > platform_finish() is called after > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > indicated by the recent > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from > > > > > > > > > -rc6. :) > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > and I even flagged that message in my local folder, but > > > > > > > apparently forgot > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > described in > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > But it's quite possible that you are running into a different issue > > > > > > exposed by this commit. > > > > > > > > > > Yes, it's likely. > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but my > > > > > hardware > > > > > is certainly different. Which suspend mode do you use? If that's > > > > > "platform", > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > Sure. > > > > shutdown/reboot works fine, only platform is broken. > > > > > > Thanks. > > > > > > Now, I suspect the problem is somehow related to the hardware, so it > > > would help > > > a lot if we could identify the piece of hardware (or driver) involved. > > > > > > AFAICT, your system is a non-SMP one, so we can rule out > > > disable/enable_nonboot_cpus(). To confirm that the problem is related to > > > platform_finish(), can you please apply the appended debug patch and > > > see if the suspend in the 'platform' mode works with it? > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > single core CPU. > > > > > Also, would that be feasible for you to use 'shutdown' as a workaround in > > > case > > > the source of the problem is difficult to find and/or fix? > > > > I guess so, but the below patch fixes the problem. :) > > Well, I thought it would, but it also would break some other people's systems. > That's the _real_ problem. Let's see if we can learn more. > > Can you please revert it for now, apply the appended one and try to > suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at "i8042 i8042: EARLY resume". This is kinda interesting because I'm normally using a USB
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Bartek wrote: 2007/4/14, David Miller [EMAIL PROTECTED]: From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 07:43:39 +0200 It seems we fail to reserve enough headroom for the case buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. Can you try this patch please? Any confirmation of this fix yet? I'm testing that patch, till now everything seems ok. Please test Paul's patch instead and keep everyone CCed. - 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 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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 2.6.21-rc6
Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). -- Tobias
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
2007/4/14, David Miller [EMAIL PROTECTED]: From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 12 Apr 2007 07:43:39 +0200 It seems we fail to reserve enough headroom for the case buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. Can you try this patch please? Any confirmation of this fix yet? I'm testing that patch, till now everything seems ok. Regards Bartek - 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 2.6.21-rc6
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. Ah, sorry. I used a wrong tree to generate the patch. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB
Re: Linux 2.6.21-rc6
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) Well, I think that when you're using the USB keyboard and the USB legacy support, the i8042 driver thinks it has a keyboard to handle and tries to handle it during the suspend, which fails. I don't know why it fails during the second suspend, though. Dmitry, could you please have a look? This is wierd as i8042 does not use suspend_late/resume_early hooks and so it is impossible for it to hang there. None of input drivers use these hooks. Could it be that some other driver _after_ i8042 hangs? And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken and I think there are more such systems than there are systems that set USB legacy support in the BIOS and have no PS/2 keyboards attached. I would say that every box that does not use PS/2 keyboard does this. IOW every box with USB keyboard has legacy emulation turned on so quite few of them... -- Dmitry - 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-pm] Linux 2.6.21-rc6
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment would be to disable the EHCI (high speed USB) support in BIOS, to make for a simpler hardware configuration, and see if that makes BIOS happier. (Or better, just take EHCI out of your Linux config.) Likewise, taking the 8042 drivers out of Linux. I wouldn't be surprised if those factors didn't matter, but it'd be good to rule them out. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) Well, I think that when you're using the USB keyboard and the USB legacy support, the i8042 driver thinks it has a keyboard to handle and tries to handle it during the suspend, which fails. I don't know why it fails during the second suspend, though. The legacy support in at least some cases involves BIOS having a small USB stack -- enough to handle a keyboard or mouse in boot mode (plus sometimes a USB disk or CDROM) -- and poking the i8042 chip to act as if *IT* received the data bytes that really came over USB. I sure don't know the ins-and-outs of such schemes (ISTR there are others), but my guess is that either the 8042 or OHCI got confused, at least in conjunction with the lowlevel magic ACPI was doing. That's all black magic though, as far as I can understand it ... Dmitry, could you please have a look? And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? - Dave - 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 2.6.21-rc6
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote: On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) Well, I think that when you're using the USB keyboard and the USB legacy support, the i8042 driver thinks it has a keyboard to handle and tries to handle it during the suspend, which fails. I don't know why it fails during the second suspend, though. Dmitry, could you please have a look? This is wierd as i8042 does not use suspend_late/resume_early hooks and so it is impossible for it to hang there. None of input drivers use these hooks. Could it be that some other driver _after_ i8042 hangs? Yes. Tobias, can you please post the dmesg output from after a successful suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode? And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken and I think there are more such systems than there are systems that set USB legacy support in the BIOS and have no PS/2 keyboards attached. I would say that every box that does not use PS/2 keyboard does this. Quite some people I know use USB keyboards with notebooks, but in these cases the PS/2 keyboard is still attached (except for notebooks in which the built-in keyboard is a USB one, that is). IOW every box with USB keyboard has legacy emulation turned on so quite few of them... I have such a machine nearby, so I'll see if I can reproduce the problem. Greetings, Rafael - 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-pm] Linux 2.6.21-rc6
On Sunday, 15 April 2007 17:14, David Brownell wrote:
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
would be to disable the EHCI (high speed USB) support in BIOS, to make
for a simpler hardware configuration, and see if that makes BIOS happier.
(Or better, just take EHCI out of your Linux config.) Likewise, taking
the 8042 drivers out of Linux.
I wouldn't be surprised if those factors didn't matter, but it'd be good
to rule them out.
I think the disabling of i8042 support might help.
With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
that the second suspend hangs at i8042 i8042: EARLY resume.
This is kinda interesting because I'm normally using a USB keyboard
and sure enough, if I hook up a normal keyboard and disable USB
legacy support in the BIOS, then suspend to disk works multiple
times. I'd still rather like to use my USB keyboard though. ;)
Well, I think that when you're using the USB keyboard and the USB legacy
support, the i8042 driver thinks it has a keyboard to handle and tries to
handle it during the suspend, which fails. I don't know why it fails during
the second suspend, though.
The legacy support in at least some cases involves BIOS having a
small USB stack -- enough to handle a keyboard or mouse in boot mode
(plus sometimes a USB disk or CDROM) -- and poking the i8042 chip to
act as if *IT* received the data bytes that really came over USB.
That's what happens here, I think.
I sure don't know the ins-and-outs of such schemes (ISTR there are
others), but my guess is that either the 8042 or OHCI got confused,
at least in conjunction with the lowlevel magic ACPI was doing.
Yes.
That's all black magic though, as far as I can understand it ...
Well, my theory is the following:
Without the patch, platform_finish() runs before the i8042's .resume() which is
done as though a real keyboard were present, but the ACPI magic is not done
and this confuses the heck out of the controller. Still, it doesn't go mad at
this point just yet (it probably isn't fully functional either, although we
don't see that, because it's not really used), but next, during the subsequent
suspend, it gets poked while device_power_up() is running and goes belly
up.
Dmitry, could you please have a look?
And I can now confirm that unpatched 2.6.21-rc6 works fine as long
as USB legacy support is disabled (however without legacy support I
can't use the USB keyboard to control grub).
I think using the 'shutdown' mode of suspend would be better. There's a
little
point in using 'platform' on desktop systems anyway.
Frankly, I don't know what to do about it. If we move platform_finish()
after
device_resume(), some systems may be broken ...
What I'm curious about is exactly why the patch matters. What ACPI
magic is being invoked to confuse, or unconfuse, those controllers?
I think the patch helps, because it makes the ACPI magic be done while the
i8042's .resume() is being executed.
Which makes me think the following patch might help:
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev-dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset();
dev-dev.power.power_state = state;
-
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-pm] Linux 2.6.21-rc6
On Sunday 15 April 2007 9:37 am, Rafael J. Wysocki wrote:
Which makes me think the following patch might help:
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev-dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
Yeah, lack of PRETHAW support could be an issue. As you may recall,
it was added because otherwise statically linked USB host controllers
came up under the mistaken belief that they were getting a real resume
event rather than a restart-after-power-off ... and there needed to be
a way to force a hard reset. Seems like a similar issue here.
- Dave
i8042_controller_reset();
dev-dev.power.power_state = state;
-
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 2.6.21-rc6
On Sunday, 15 April 2007 20:50, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote:
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
that the second suspend hangs at i8042 i8042: EARLY resume.
This is kinda interesting because I'm normally using a USB keyboard
and sure enough, if I hook up a normal keyboard and disable USB
legacy support in the BIOS, then suspend to disk works multiple
times. I'd still rather like to use my USB keyboard though. ;)
Well, I think that when you're using the USB keyboard and the USB legacy
support, the i8042 driver thinks it has a keyboard to handle and tries
to
handle it during the suspend, which fails. I don't know why it fails
during
the second suspend, though.
Dmitry, could you please have a look?
This is wierd as i8042 does not use suspend_late/resume_early hooks and
so it is impossible for it to hang there. None of input drivers use these
hooks. Could it be that some other driver _after_ i8042 hangs?
Yes.
Tobias, can you please post the dmesg output from after a successful
suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode?
Here you go:
Thanks.
[--snip--]
[10233.239209] swsusp: critical section:
[10233.253579] swsusp: Need to copy 125818 pages
[10233.253688] swsusp: Normal pages needed: 125818 + 1024 + 22, available
pages: 135940
[ 43.795445] Extended CMOS year: 2000
[ 43.798813] svm_cpu_init: svm_data is NULL on 0
[ 43.800886] pci :00:00.0: EARLY resume
[ 43.800994] pci :00:01.0: EARLY resume
[ 43.801102] nForce2_smbus :00:01.1: EARLY resume
[ 43.801210] pci :00:01.2: EARLY resume
[ 43.801317] ohci_hcd :00:02.0: EARLY resume
[ 43.801425] ehci_hcd :00:02.1: EARLY resume
[ 43.801532] pata_amd :00:04.0: EARLY resume
[ 43.801640] pci :00:06.0: EARLY resume
[ 43.801747] pci :00:06.1: EARLY resume
[ 43.801854] forcedeth :00:08.0: EARLY resume
[ 43.801962] forcedeth :00:09.0: EARLY resume
[ 43.802070] pcieport-driver :00:0a.0: EARLY resume
[ 43.802177] pcieport-driver :00:0b.0: EARLY resume
[ 43.802289] pcieport-driver :00:0c.0: EARLY resume
[ 43.802398] pcieport-driver :00:0d.0: EARLY resume
[ 43.802506] pcieport-driver :00:0e.0: EARLY resume
[ 43.802613] pcieport-driver :00:0f.0: EARLY resume
[ 43.802721] pci :00:18.0: EARLY resume
[ 43.802828] pci :00:18.1: EARLY resume
[ 43.802935] pci :00:18.2: EARLY resume
[ 43.803043] k8temp :00:18.3: EARLY resume
[ 43.803150] e100 :01:07.0: EARLY resume
[ 43.803257] EMU10K1_Audigy :01:08.0: EARLY resume
[ 43.803365] Emu10k1_gameport :01:08.1: EARLY resume
[ 43.803473] pci :01:0b.0: EARLY resume
[ 43.803580] ahci :06:00.0: EARLY resume
[ 43.803695] pci :06:00.1: EARLY resume
[ 43.803802] pci :07:00.0: EARLY resume
[ 43.803910] pci :07:00.1: EARLY resume
[ 43.804018] platform bluetooth: EARLY resume
[ 43.804126] platform pcspkr: EARLY resume
[ 43.804233] platform vesafb.0: EARLY resume
[ 43.804348] i8042 i8042: EARLY resume
[ 43.804460] PM: Image restored successfully.
[ 43.924837] acpi acpi_system:00: resuming
[ 43.924946] button button_power:00: resuming
[ 43.925054] processor ACPI0007:00: resuming
[ 43.925161] processor ACPI0007:01: resuming
[ 43.925268] acpi device:00: resuming
[--snip--]
Hmm, it looks like i8042 is the last thing on the dpm_off_irq list. Still,
if the ACPI resume fails, the next messages may not make it to the console
(it's not very probable, though).
I've tried to reproduce your problem on another box on which I have no PS/2
keyboard (USB keyboard/mouse only) and the USB legacy support set, but I can't.
There must be something very special in your configuration.
Have you tried the patch that I posted some time ago (appended again for
convenience)?
Rafael
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev-dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset
Re: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 17:14, David Brownell wrote:
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
would be to disable the EHCI (high speed USB) support in BIOS, to make
for a simpler hardware configuration, and see if that makes BIOS happier.
(Or better, just take EHCI out of your Linux config.) Likewise, taking
the 8042 drivers out of Linux.
I wouldn't be surprised if those factors didn't matter, but it'd be good
to rule them out.
I think the disabling of i8042 support might help.
Still hangs with # CONFIG_SERIO_I8042 is not set.
Dmitry, could you please have a look?
And I can now confirm that unpatched 2.6.21-rc6 works fine as long
as USB legacy support is disabled (however without legacy support I
can't use the USB keyboard to control grub).
I think using the 'shutdown' mode of suspend would be better. There's a
little
point in using 'platform' on desktop systems anyway.
Frankly, I don't know what to do about it. If we move platform_finish()
after
device_resume(), some systems may be broken ...
What I'm curious about is exactly why the patch matters. What ACPI
magic is being invoked to confuse, or unconfuse, those controllers?
I think the patch helps, because it makes the ACPI magic be done while the
i8042's .resume() is being executed.
Which makes me think the following patch might help:
Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev-dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset();
dev-dev.power.power_state = state;
-
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/
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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-pm] Linux 2.6.21-rc6
On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 17:14, David Brownell wrote: On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment would be to disable the EHCI (high speed USB) support in BIOS, to make for a simpler hardware configuration, and see if that makes BIOS happier. (Or better, just take EHCI out of your Linux config.) Likewise, taking the 8042 drivers out of Linux. I wouldn't be surprised if those factors didn't matter, but it'd be good to rule them out. I think the disabling of i8042 support might help. Still hangs with # CONFIG_SERIO_I8042 is not set. Dmitry, could you please have a look? And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? I think the patch helps, because it makes the ACPI magic be done while the i8042's .resume() is being executed. Which makes me think the following patch might help: Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael - 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
I wrote: > So this doesn't change process_input_packet(), which treats the case > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of I meant "the second byte is NOT 0x03", of course. 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller writes:
> Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
the RFC does envision the possibility of receiving frames where the
control field has values other than 0x03.
Therefore I think this patch is probably better. Could people try it
out and let me know if it fixes the problem?
Paul.
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 933e2f3..caabbc4 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap)
/* check for address/control and protocol compression */
p = skb->data;
- if (p[0] == PPP_ALLSTATIONS && p[1] == PPP_UI) {
+ if (p[0] == PPP_ALLSTATIONS) {
/* chop off address/control */
- if (skb->len < 3)
+ if (p[1] != PPP_UI || skb->len < 3)
goto err;
p = skb_pull(skb, 2);
}
-
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 2.6.21-rc6
On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > Rafael J. Wysocki wrote: > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > Tobias Diedrich wrote: > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > > > > > device_suspend() is > > > > > > > > called before disable_nonboot_cpus() and platform_finish() > > > > > > > > is called after > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > indicated by the recent > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from > > > > > > > > -rc6. :) > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > reverted from -rc1. > > > > > > > > > > > > Now, this was already reported in > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > and I even flagged that message in my local folder, but apparently > > > > > > forgot > > > > > > to follow up on it... *sigh* > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim described > > > > > in > > > > > this email are fixed for him in -rc6. > > > > > > > > > > But it's quite possible that you are running into a different issue > > > > > exposed by this commit. > > > > > > > > Yes, it's likely. > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but my > > > > hardware > > > > is certainly different. Which suspend mode do you use? If that's > > > > "platform", > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > Sure. > > > shutdown/reboot works fine, only platform is broken. > > > > Thanks. > > > > Now, I suspect the problem is somehow related to the hardware, so it would > > help > > a lot if we could identify the piece of hardware (or driver) involved. > > > > AFAICT, your system is a non-SMP one, so we can rule out > > disable/enable_nonboot_cpus(). To confirm that the probl
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > Tobias Diedrich wrote: > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > > > > device_suspend() is > > > > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > > > > called after > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > indicated by the recent > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from > > > > > > > -rc6. :) > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > reverted from -rc1. > > > > > > > > > > Now, this was already reported in > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > and I even flagged that message in my local folder, but apparently > > > > > forgot > > > > > to follow up on it... *sigh* > > > > > > > > Unless I misunderstood something, all of the problems Maxim described > > > > in > > > > this email are fixed for him in -rc6. > > > > > > > > But it's quite possible that you are running into a different issue > > > > exposed by this commit. > > > > > > Yes, it's likely. > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but my > > > hardware > > > is certainly different. Which suspend mode do you use? If that's > > > "platform", > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > Sure. > > shutdown/reboot works fine, only platform is broken. > > Thanks. > > Now, I suspect the problem is somehow related to the hardware, so it would > help > a lot if we could identify the piece of hardware (or driver) involved. > > AFAICT, your system is a non-SMP one, so we can rule out > disable/enable_nonboot_cpus(). To confirm that the problem is related to > platform_finish(), can you please apply the appended debug patch and > see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. > Also, would that be feasible for you to use 'shutdown' as a workaround in case > the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) >
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 22:25, Adrian Bunk wrote: > On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote: > >... > > Also, would that be feasible for you to use 'shutdown' as a workaround in > > case > > the source of the problem is difficult to find and/or fix? > > One person reporting a regression against a -rc kernel can mean > houndreds or thousands of people who will run into the same issue after > 2.6.21 got released if a manual workaround is required... Well, in this particular case it is not very likely to happen. I have three x86_64 machines here with totally different chipsets/devices on which I'm not seeing anything like that and I believe we'd have more reports before if that were a common issue. That said, I'm not going to ignore it. I'll do my best to debug and fix it, if Tobias helps me. :-) Greetings, Rafael - 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 2.6.21-rc6
On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote: >... > Also, would that be feasible for you to use 'shutdown' as a workaround in case > the source of the problem is difficult to find and/or fix? One person reporting a regression against a -rc kernel can mean houndreds or thousands of people who will run into the same issue after 2.6.21 got released if a manual workaround is required... > Rafael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 2.6.21-rc6
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > > Tobias Diedrich wrote:
> > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > Date: Sat Feb 10 01:43:32 2007 -0800
> > > > > >
> > > > > > [PATCH] swsusp: Change code ordering in disk.c
> > > > > >
> > > > > > Change the ordering of code in kernel/power/disk.c so that
> > > > > > device_suspend() is
> > > > > > called before disable_nonboot_cpus() and platform_finish() is
> > > > > > called after
> > > > > > enable_nonboot_cpus() and before device_resume(), as indicated
> > > > > > by the recent
> > > > > > discussion on Linux-PM (cf.
> > > > > >
> > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
> > > > > >
> > > > > > The changes here only affect the built-in swsusp.
> > > > > >
> > > > > > [EMAIL PROTECTED]: fix LED blinking during image load]
> > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]>
> > > > > > Cc: Greg KH <[EMAIL PROTECTED]>
> > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]>
> > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]>
> > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]>
> > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> > > > > >
> > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
> > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
> > > > > >
> > > > > >
> > > > > > Now, the remaining test is to try reverting this commit from -rc6.
> > > > > > :)
> > > > >
> > > > > Doesn't apply cleanly against -rc6, but fixes the problem when
> > > > > reverted from -rc1.
> > > >
> > > > Now, this was already reported in
> > > > http://lkml.org/lkml/2007/3/16/126
> > > > and I even flagged that message in my local folder, but apparently
> > > > forgot
> > > > to follow up on it... *sigh*
> > >
> > > Unless I misunderstood something, all of the problems Maxim described in
> > > this email are fixed for him in -rc6.
> > >
> > > But it's quite possible that you are running into a different issue
> > > exposed by this commit.
> >
> > Yes, it's likely.
> >
> > Tobias, I'm unable to reproduce the problem with your .config, but my
> > hardware
> > is certainly different. Which suspend mode do you use? If that's
> > "platform",
> > can you try to use "shutdown" or "reboot" and see if that helps?
>
> Sure.
> shutdown/reboot works fine, only platform is broken.
Thanks.
Now, I suspect the problem is somehow related to the hardware, so it would help
a lot if we could identify the piece of hardware (or driver) involved.
AFAICT, your system is a non-SMP one, so we can rule out
disable/enable_nonboot_cpus(). To confirm that the problem is related to
platform_finish(), can you please apply the appended debug patch and
see if the suspend in the 'platform' mode works with it?
Also, would that be feasible for you to use 'shutdown' as a workaround in case
the source of the problem is difficult to find and/or fix?
Rafael
---
kernel/power/disk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -170,8 +170,8 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
pr_debug("PM: writing image.\n");
error = swsusp_write();
@@ -189,8 +189,8 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
Thaw:
unprepare_processes();
-
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 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > Tobias Diedrich wrote: > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > > device_suspend() is > > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > > called after > > > > > enable_nonboot_cpus() and before device_resume(), as indicated by > > > > > the recent > > > > > discussion on Linux-PM (cf. > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > reverted from -rc1. > > > > > > Now, this was already reported in > > > http://lkml.org/lkml/2007/3/16/126 > > > and I even flagged that message in my local folder, but apparently forgot > > > to follow up on it... *sigh* > > > > Unless I misunderstood something, all of the problems Maxim described in > > this email are fixed for him in -rc6. > > > > But it's quite possible that you are running into a different issue > > exposed by this commit. > > Yes, it's likely. > > Tobias, I'm unable to reproduce the problem with your .config, but my hardware > is certainly different. Which suspend mode do you use? If that's "platform", > can you try to use "shutdown" or "reboot" and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. -- Tobias PGP: http://9ac7e0bc.uguu.de - 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 2.6.21-rc6
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > Tobias Diedrich wrote: > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > device_suspend() is > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > called after > > > > enable_nonboot_cpus() and before device_resume(), as indicated by > > > > the recent > > > > discussion on Linux-PM (cf. > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > reverted from -rc1. > > > > Now, this was already reported in > > http://lkml.org/lkml/2007/3/16/126 > > and I even flagged that message in my local folder, but apparently forgot > > to follow up on it... *sigh* > > Unless I misunderstood something, all of the problems Maxim described in > this email are fixed for him in -rc6. > > But it's quite possible that you are running into a different issue > exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's "platform", can you try to use "shutdown" or "reboot" and see if that helps? Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller wrote: > From: Paul Mackerras <[EMAIL PROTECTED]> > Date: Sun, 15 Apr 2007 02:49:28 +1000 > > >>I didn't see the patch (the message that this is a reply to is the >>first one that I have seen in this thread), so I can't comment on it. > > > Here is Patrick McHardy's patch: > > [..] I haven't heard back from Bartek yet. In case the patch is correct, ppp_synctty seems to need the same fix. - 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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 02:49:28 +1000
> I didn't see the patch (the message that this is a reply to is the
> first one that I have seen in this thread), so I can't comment on it.
Here is Patrick McHardy's patch:
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 933e2f3..c68e37f 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -890,6 +890,8 @@ ppp_async_input(struct asyncppp *ap, const unsigned char
*buf,
ap->rpkt = skb;
}
if (skb->len == 0) {
+ int headroom = 0;
+
/* Try to get the payload 4-byte aligned.
* This should match the
* PPP_ALLSTATIONS/PPP_UI/compressed tests in
@@ -897,7 +899,10 @@ ppp_async_input(struct asyncppp *ap, const unsigned char
*buf,
* enough chars here to test buf[1] and buf[2].
*/
if (buf[0] != PPP_ALLSTATIONS)
- skb_reserve(skb, 2 + (buf[0] & 1));
+ headroom += 2;
+ if (buf[0] & 1)
+ headroom += 1;
+ skb_reserve(skb, headroom);
}
if (n > skb_tailroom(skb)) {
/* packet overflowed MRU */
-
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: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller writes: > > It seems we fail to reserve enough headroom for the case > > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > > > Can you try this patch please? > > Any confirmation of this fix yet? Indeed, ppp_async doesn't handle that case correctly. RFC 1662 says: The Control field is a single octet, which contains the binary sequence 0011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the Poll/Final (P/F) bit set to zero. The use of other Control field values may be defined at a later time, or by prior agreement. Frames with unrecognized Control field values SHOULD be silently discarded. In what situation were we getting the frames that cause the problem? I didn't see the patch (the message that this is a reply to is the first one that I have seen in this thread), so I can't comment on it. 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: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > Tobias Diedrich wrote: > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > device_suspend() is > > > called before disable_nonboot_cpus() and platform_finish() is called > > > after > > > enable_nonboot_cpus() and before device_resume(), as indicated by the > > > recent > > > discussion on Linux-PM (cf. > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > The changes here only affect the built-in swsusp. > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > reverted from -rc1. > > Now, this was already reported in > http://lkml.org/lkml/2007/3/16/126 > and I even flagged that message in my local folder, but apparently forgot > to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. > Tobias cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 2.6.21-rc6
Tobias Diedrich wrote: > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > Change the ordering of code in kernel/power/disk.c so that > > device_suspend() is > > called before disable_nonboot_cpus() and platform_finish() is called > > after > > enable_nonboot_cpus() and before device_resume(), as indicated by the > > recent > > discussion on Linux-PM (cf. > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > The changes here only affect the built-in swsusp. > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > Cc: Greg KH <[EMAIL PROTECTED]> > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > Doesn't apply cleanly against -rc6, but fixes the problem when > reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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 2.6.21-rc6
On Sat, Apr 14, 2007 at 10:16:19AM +0200, Tobias Diedrich wrote: > Adrian Bunk wrote: > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > Linus Torvalds wrote: > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > regression reports you've done, > > > > > > For me, suspend to disk works only once (has been the case for all > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > There are some threads about an issue like this, which is supposed > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > problem persists nonetheless. > > > > > > On the second suspend attempt, the last message I see is > > > "Suspending console(s)" > > > > > > If I find the time, I'll try to bisect it this weekend. > > >... > > > > Does the latest -git work? > > Still no luck with > Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST > 2007 x86_64 GNU/Linux > Why -dirty? Maybe because I modified the Makefile to use ccache? > > > Does CONFIG_HPET_TIMER=n make any difference? > > Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after > make oldconfig... Is that expected on amd64? >... Yes it is (on i386 you can disable it). Sorry that I missed this. > TobiasPGP: > http://9ac7e0bc.uguu.de cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 2.6.21-rc6
Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > Linus Torvalds wrote:
> > >
> > > > We should be getting close to a 2.6.21 release, so please update any
> > > > regression reports you've done,
> > >
> > > For me, suspend to disk works only once (has been the case for all
> > > .21-rcs IIRC, but I didn't get around to report it so far).
> > > There are some threads about an issue like this, which is supposed
> > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the
> > > problem persists nonetheless.
> > >
> > > On the second suspend attempt, the last message I see is
> > > "Suspending console(s)"
> > >
> > > If I find the time, I'll try to bisect it this weekend.
> > >...
> >
> > Does CONFIG_HPET_TIMER=n make any difference?
> > Does the latest -git work?
>
> bisect results:
>
> git-bisect start
> # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
> git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7
> # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1
> git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba
> # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of
> git://ftp.linux-mips.org/pub/scm/upstream-linus
> git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8
> # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
> git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1
> # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile
> cleanups
> git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9
> # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support
> higher rates
> git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f
> # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal
> with cases of ZONE_DMA meaning the first zone
> git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b
> # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting
> fixes
> git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61
> # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE
> macro when appropriate
> git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0
> # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE
> macro when appropriate
> git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4
> # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and
> update_mmu_cache
> git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a
> # bad: [d12c610e08022a1b84d6bd4412c189214d32e713]
> swsusp-change-code-ordering-in-userc-sanity
> git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713
> # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code
> ordering in disk.c
> git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5
> # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering
> in main.c
> git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557
>
>
> ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> commit ed746e3b18f4df18afa3763155972c5835f284c5
> Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Date: Sat Feb 10 01:43:32 2007 -0800
>
> [PATCH] swsusp: Change code ordering in disk.c
>
> Change the ordering of code in kernel/power/disk.c so that
> device_suspend() is
> called before disable_nonboot_cpus() and platform_finish() is called after
> enable_nonboot_cpus() and before device_resume(), as indicated by the
> recent
> discussion on Linux-PM (cf.
> http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
>
> The changes here only affect the built-in swsusp.
>
> [EMAIL PROTECTED]: fix LED blinking during image load]
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Acked-by: Pavel Machek <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Cc: Nigel Cunningham <[EMAIL PROTECTED]>
> Cc: Patrick Mochel <[EMAIL PROTECTED]>
> Cc: Alexey Starikovskiy <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
>
> :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
> 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
>
>
> Now, the remaining test is to try reverting this commit from -rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Index: linux-2.6.21-rc1/kernel/power/disk.c
===
--- linux-2.6.21-rc1.orig/kernel/power/disk.c 2007-04-14 14:16:59.0
+0200
+++ linux-2.6.21-rc1/kernel/power/disk.c2007-04-14 14:17:03.0
+0200
@@ -87,24 +87,52 @@
}
}
-static void unprepare_processes(void)
-{
- thaw_processes();
- pm_restore_console();
-}
-
static int prepare_processes(void)
{
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > Linus Torvalds wrote: > > > > > We should be getting close to a 2.6.21 release, so please update any > > > regression reports you've done, > > > > For me, suspend to disk works only once (has been the case for all > > .21-rcs IIRC, but I didn't get around to report it so far). > > There are some threads about an issue like this, which is supposed > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > problem persists nonetheless. > > > > On the second suspend attempt, the last message I see is > > "Suspending console(s)" > > > > If I find the time, I'll try to bisect it this weekend. > >... > > Does CONFIG_HPET_TIMER=n make any difference? > Does the latest -git work? bisect results: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal with cases of ZONE_DMA meaning the first zone git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting fixes git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61 # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE macro when appropriate git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0 # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE macro when appropriate git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4 # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and update_mmu_cache git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a # bad: [d12c610e08022a1b84d6bd4412c189214d32e713] swsusp-change-code-ordering-in-userc-sanity git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713 # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code ordering in disk.c git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5 # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering in main.c git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557 ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki <[EMAIL PROTECTED]> Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Cc: Nigel Cunningham <[EMAIL PROTECTED]> Cc: Patrick Mochel <[EMAIL PROTECTED]> Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: > > Adrian Bunk wrote: > > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > > Linus Torvalds wrote: > > > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > > regression reports you've done, > > > > > > > > For me, suspend to disk works only once (has been the case for all > > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > > There are some threads about an issue like this, which is supposed > > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > > problem persists nonetheless. > > > > > > > > On the second suspend attempt, the last message I see is > > > > "Suspending console(s)" > > > > > > > > If I find the time, I'll try to bisect it this weekend. > > > >... > > > > > > Does the latest -git work? > > > > Still no luck with > > Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 > > CEST 2007 x86_64 GNU/Linux > > Can you boot with init=/bin/bash and see if the problem is present in this > configuration? Doesn't help. Maybe interesting: In the init=/bin/bash run, the first suspend try was without swap and thus bailed out. After swapon, the second try already hung, despite not having 'really' suspended at all on the first try. I tried it once more, with swap on the first try and got the same 'second try doesn't work' result. git-bisect so far: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
