Re: adapter, what's in a name
Karl Dahlke wrote: > Meantime, I pulled the emails out of the headers and pasted them in. > Hope that reasonably works. Well, you're still breaking the thread by starting a new one. Guess when you're implementing reply-to-all, you should also think about implementing support for In-Reply-To: and References: headers (and possibly a whole lot of other stuff that's supposed to be included in a standards-compliant MUA). Cheers, FJP -- 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: adapter, what's in a name
Karl Dahlke wrote: Meantime, I pulled the emails out of the headers and pasted them in. Hope that reasonably works. Well, you're still breaking the thread by starting a new one. Guess when you're implementing reply-to-all, you should also think about implementing support for In-Reply-To: and References: headers (and possibly a whole lot of other stuff that's supposed to be included in a standards-compliant MUA). Cheers, FJP -- 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: Unable to continue testing of 2.6.25
On Tuesday 19 February 2008, Adrian Bunk wrote: > The "or any other emulator" is exactly where my question is directed at. > > Xen, KVM or even qemu come into my mind, but considering how loudly you > complained about a temporary breakage for VirtualBox there must be a > reason why your work on the Debian Installer can only be done > effectively and efficiently with an emulator module that has AFAIK not > been submitted for inclusion in the kernel. - Xen is currently not supported by the kernel Debian Installer uses (though work is being done to change that. - KVM AFAIK requires hardware support that I don't have. - QEMU is completely useless because of its slow speed without the (also out of tree) kqemu module, which does not work when the host system is x86_64 [1]. Also, I very much prefer the VirtualBox user interface over what qemu has to offer. - I've actually used VMWare for a long time (licenced), but stopped after the 5 series stopped working with current kernels and around that time VirtualBox became available as an alternative. Hope that explains. Cheers, FJP [1] http://bugs.debian.org/444160 -- 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: Unable to continue testing of 2.6.25
On Sunday 17 February 2008, Arjan van de Ven wrote: > On Sun, 17 Feb 2008 14:38:51 -0600 Paul Jackson <[EMAIL PROTECTED]> wrote: > > Adrian wrote: > > > So let's fix the problem (kernel lacks functionality) > > > > That's the problem as understood by Adrian. > > > > I hear another problem as well ... > > > > Frans wrote: > > > Please allow external users some decent period for transitioning. > > > The initial plan to "remove the old function in 2.6.27" was > > > entirely sensible. It's a pity it was not followed through. > > > > That seems plain enough to me. It's not just the lack of > > functionality, but that such lack apparently happened with too little > > warning. > > > > If this is a fair representation of what happened, then seems to me > > that we could have left that EXPORT_UNUSED_SYMBOL(change_page_attr) > > in place a bit longer. > > it's not a fair repersentation. Again.. this export was unkeepable due to > the API being nasty and having to be fixed anyway ;(. > > One of the problems was that the c-p-a api has to be followed by a cache > flush function call. Sadly that does a TOTAL flush of the caches of all > cpus in the system. As part of the -rc1 changes, it is now done only on > the exact pages that need to be flushed (so you no longer flush 12Mb of > caches when you only needed to flush 4Kb), but to achieve that, it was no > longer an option to keep this as 2 separate function calls. > Add to this that some very fundemanteal bugs couldn't be fixed without > the function underlying cpa changing prototype and behavior, so the > function had to go. That's a much better explanation than can be found in the changelog. The changelog effectively says: this commits makes a few (new) functions static; oh, and by the way, let's delete the old function _because it is unused and ugly_. Well, I've shown that the first is not true and the second by itself is absolutely not sufficient reason to remove an exported function that has long been part of the kernel. I would probably have started this thread differently if the removal had been done in a separate commit and had included the explanation you give above. > I understand where he's coming from; at the same time it's a very small > change to virtualbox to fix this and has been done already... in minutes. The problem here is that it may be a simple change for you and other similarly gifted people, but it's something that's above _my_ skills. > Frans should take that up with the virtual box support forum, I'm sure I did actually manage to create such a patch for the breakage in the VirtualBox source because of 2.6.24, but those really were very minor issues (basically overlapping definitions). I posted that on their user list (to which I am subscribed), but I never saw any response to it. I also don't think it is really realistic to expect Innotek to provide patches for unreleased kernel versions. Maybe some other user could provide me with the patch, but I'm not as confident as you are. My point still is that I feel they should not have to. That it's also the kernel developers responsibility to ensure backwards compatibility or at least a grace period for conversion whenever possible. And IMO that not only goes for user-space API, but also for interfaces used by out-of-tree kernel modules. Is it really impossible in this case for example to rewrite the old function so that it becomes a wrapper around the new interface? If it is impossible, then so be it. > they have the patch available there. I haven't seen anything on the user mailing list yet... On Tuesday 19 February 2008, Arjan van de Ven wrote: > I assume you've read the other mails right and went to the virtualbox > form to get the small patch to make it work on .25 right? If you can give me a link to that patch, I'd be grateful. As I said, I'm subscribed to their user list but have not seen any patch there. I've also googled for it, without result. I've also just quickly checked their "VirtualBox on Linux" forum, but did not see any obvious existing post about it. Cheers, FJP -- 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: Unable to continue testing of 2.6.25
On Sunday 17 February 2008, Adrian Bunk wrote: > The real problem is that the kernel seems to lack functionality you > require for doing some work. Not sure how you reached that conclusion. > Why does your work on the Debian Installer depend on VirtualBox and > can't be done with what the kernel already ships? Work on the installer does not so much hard depend on VirtualBox (or any other emulator), but can be done much more effectively and efficiently using one. It allows me to run the installer inside the emulator without the need for a second computer (and using the same keyboard). It allows me to take snapshots just before stages I'm interested in and then add debugging or try changes. If what I tried does not work, I can just revert to the snapshot and try something else without having to run the full installation from scratch. It allows me to easily test RAID setups without having multiple physical disks. Etc. The fact that VirtualBox does not (yet) work for me with 2.6.25 means that I'm unable to run 2.6.25 on my main desktop and do any real work. Rebooting my desktop whenever I want to use VirtualBox is just not a realistic option. That in turn means that I cannot do any more testing of 2.6.25, because most of the testing I do consists of just using a new kernel and critically observing the behavior of my system. As I've caught a fair number of bugs that way for the past few releases, I'd say that's a useful contribution. -- 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: Unable to continue testing of 2.6.25
On Sunday 17 February 2008, Adrian Bunk wrote: The real problem is that the kernel seems to lack functionality you require for doing some work. Not sure how you reached that conclusion. Why does your work on the Debian Installer depend on VirtualBox and can't be done with what the kernel already ships? Work on the installer does not so much hard depend on VirtualBox (or any other emulator), but can be done much more effectively and efficiently using one. It allows me to run the installer inside the emulator without the need for a second computer (and using the same keyboard). It allows me to take snapshots just before stages I'm interested in and then add debugging or try changes. If what I tried does not work, I can just revert to the snapshot and try something else without having to run the full installation from scratch. It allows me to easily test RAID setups without having multiple physical disks. Etc. The fact that VirtualBox does not (yet) work for me with 2.6.25 means that I'm unable to run 2.6.25 on my main desktop and do any real work. Rebooting my desktop whenever I want to use VirtualBox is just not a realistic option. That in turn means that I cannot do any more testing of 2.6.25, because most of the testing I do consists of just using a new kernel and critically observing the behavior of my system. As I've caught a fair number of bugs that way for the past few releases, I'd say that's a useful contribution. -- 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: Unable to continue testing of 2.6.25
On Sunday 17 February 2008, Arjan van de Ven wrote: On Sun, 17 Feb 2008 14:38:51 -0600 Paul Jackson [EMAIL PROTECTED] wrote: Adrian wrote: So let's fix the problem (kernel lacks functionality) That's the problem as understood by Adrian. I hear another problem as well ... Frans wrote: Please allow external users some decent period for transitioning. The initial plan to remove the old function in 2.6.27 was entirely sensible. It's a pity it was not followed through. That seems plain enough to me. It's not just the lack of functionality, but that such lack apparently happened with too little warning. If this is a fair representation of what happened, then seems to me that we could have left that EXPORT_UNUSED_SYMBOL(change_page_attr) in place a bit longer. it's not a fair repersentation. Again.. this export was unkeepable due to the API being nasty and having to be fixed anyway ;(. One of the problems was that the c-p-a api has to be followed by a cache flush function call. Sadly that does a TOTAL flush of the caches of all cpus in the system. As part of the -rc1 changes, it is now done only on the exact pages that need to be flushed (so you no longer flush 12Mb of caches when you only needed to flush 4Kb), but to achieve that, it was no longer an option to keep this as 2 separate function calls. Add to this that some very fundemanteal bugs couldn't be fixed without the function underlying cpa changing prototype and behavior, so the function had to go. That's a much better explanation than can be found in the changelog. The changelog effectively says: this commits makes a few (new) functions static; oh, and by the way, let's delete the old function _because it is unused and ugly_. Well, I've shown that the first is not true and the second by itself is absolutely not sufficient reason to remove an exported function that has long been part of the kernel. I would probably have started this thread differently if the removal had been done in a separate commit and had included the explanation you give above. I understand where he's coming from; at the same time it's a very small change to virtualbox to fix this and has been done already... in minutes. The problem here is that it may be a simple change for you and other similarly gifted people, but it's something that's above _my_ skills. Frans should take that up with the virtual box support forum, I'm sure I did actually manage to create such a patch for the breakage in the VirtualBox source because of 2.6.24, but those really were very minor issues (basically overlapping definitions). I posted that on their user list (to which I am subscribed), but I never saw any response to it. I also don't think it is really realistic to expect Innotek to provide patches for unreleased kernel versions. Maybe some other user could provide me with the patch, but I'm not as confident as you are. My point still is that I feel they should not have to. That it's also the kernel developers responsibility to ensure backwards compatibility or at least a grace period for conversion whenever possible. And IMO that not only goes for user-space API, but also for interfaces used by out-of-tree kernel modules. Is it really impossible in this case for example to rewrite the old function so that it becomes a wrapper around the new interface? If it is impossible, then so be it. they have the patch available there. I haven't seen anything on the user mailing list yet... On Tuesday 19 February 2008, Arjan van de Ven wrote: I assume you've read the other mails right and went to the virtualbox form to get the small patch to make it work on .25 right? If you can give me a link to that patch, I'd be grateful. As I said, I'm subscribed to their user list but have not seen any patch there. I've also googled for it, without result. I've also just quickly checked their VirtualBox on Linux forum, but did not see any obvious existing post about it. Cheers, FJP -- 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: Unable to continue testing of 2.6.25
On Tuesday 19 February 2008, Adrian Bunk wrote: The or any other emulator is exactly where my question is directed at. Xen, KVM or even qemu come into my mind, but considering how loudly you complained about a temporary breakage for VirtualBox there must be a reason why your work on the Debian Installer can only be done effectively and efficiently with an emulator module that has AFAIK not been submitted for inclusion in the kernel. - Xen is currently not supported by the kernel Debian Installer uses (though work is being done to change that. - KVM AFAIK requires hardware support that I don't have. - QEMU is completely useless because of its slow speed without the (also out of tree) kqemu module, which does not work when the host system is x86_64 [1]. Also, I very much prefer the VirtualBox user interface over what qemu has to offer. - I've actually used VMWare for a long time (licenced), but stopped after the 5 series stopped working with current kernels and around that time VirtualBox became available as an alternative. Hope that explains. Cheers, FJP [1] http://bugs.debian.org/444160 -- 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: [BUG] Linux 2.6.25-rc2 - Kernel Ooops while running dbench
Jeff Garzik wrote: > Two x86-64 boxes here lock up here on 2.6.25-rc2, shortly after boot. > One running Fedora 8 + X (GNOME) and one a headless file server. > configs and lspci attached. Unable to capture any splatter so far. Sounds like it may be http://lkml.org/lkml/2008/2/17/78. Suggest you try reverting that before doing the bisect. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
On Monday 18 February 2008, Mike Galbraith wrote: > On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote: > > Joerg Schilling wrote: > > > This fragment is much too short to allow to judge on possible > > > reasons. There is a high probability that your problem is caused by > > > the cdrecord fork called "wodim". > > > > There is also the 100% certainty that this reply was from a known troll > > and should just be ignored. > > That was rude, crude and uncalled for. I have no problems with my reply being called "rude" or "crude". After all, I wasn't even remotely trying to be nice or considerate. However, I do think it was called for as mr. Schilling's reply was nothing other than the next mail in his endlessly running FUD campain against Wodim. If you're not aware of that campain, please try for example the following link: http://www.google.com/search?q=schilling+wodim=UTF-8=UTF-8 Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
Joerg Schilling wrote: > This fragment is much too short to allow to judge on possible reasons. > There is a high probability that your problem is caused by the cdrecord > fork called "wodim". There is also the 100% certainty that this reply was from a known troll and should just be ignored. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
Joerg Schilling wrote: This fragment is much too short to allow to judge on possible reasons. There is a high probability that your problem is caused by the cdrecord fork called wodim. There is also the 100% certainty that this reply was from a known troll and should just be ignored. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1/2 CD/DVD burning broken
On Monday 18 February 2008, Mike Galbraith wrote: On Mon, 2008-02-18 at 09:46 +0100, Frans Pop wrote: Joerg Schilling wrote: This fragment is much too short to allow to judge on possible reasons. There is a high probability that your problem is caused by the cdrecord fork called wodim. There is also the 100% certainty that this reply was from a known troll and should just be ignored. That was rude, crude and uncalled for. I have no problems with my reply being called rude or crude. After all, I wasn't even remotely trying to be nice or considerate. However, I do think it was called for as mr. Schilling's reply was nothing other than the next mail in his endlessly running FUD campain against Wodim. If you're not aware of that campain, please try for example the following link: http://www.google.com/search?q=schilling+wodimie=UTF-8oe=UTF-8 Cheers, FJP -- 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: [BUG] Linux 2.6.25-rc2 - Kernel Ooops while running dbench
Jeff Garzik wrote: Two x86-64 boxes here lock up here on 2.6.25-rc2, shortly after boot. One running Fedora 8 + X (GNOME) and one a headless file server. configs and lspci attached. Unable to capture any splatter so far. Sounds like it may be http://lkml.org/lkml/2008/2/17/78. Suggest you try reverting that before doing the bisect. Cheers, FJP -- 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: [REGRESSION 2.6.23] no vga console and no messages
On Sunday 17 February 2008, Daniel Barkalow wrote: > On Sun, 17 Feb 2008, Frans Pop wrote: > > Daniel Barkalow wrote: > > > For some reason I can't see and don't know how to debug, in 2.6.23 on > > > my server I don't get the vga console, but only get the dummy > > > console. > > > > Please check if this bug report matches the issue you are seeing: > > http://bugzilla.kernel.org/show_bug.cgi?id=9310 > > I think mine might be different. I've got a vga parameter (vga=0x301), > and mine disappears very early, before when you usually get "Console: > colour VGA+ 80x25" (and I'm getting "Console: coloud dummy 80x25" > instead). I've also got CONFIG_FB turned off entirely. The main question is: do you have FRAMEBUFFER_CONSOLE_DETECT_PRIMARY enabled in you kernel config. If you do, I'd try disabling it. > But if you've got any insight into how the console driver stuff works > from troubleshooting your problem, I could use the hints... Afraid not. Are you sure you have the correct framebuffer driver compiled into the kernel? Please post your kernel config and the output of 'lspci -nn', so people can have a look. -- 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/
Unable to continue testing of 2.6.25
Yesterday, after spending quite a few hours over the last days on bisecting some serious regressions and finding workarounds for them, I thought I could start using 2.6.25-rc2 as the new kernel for my desktop. Unfortunately I found that I cannot because it would make my other main activity - working on the Debian installation system - impossible. For my work on the Debian Installer I heavily rely on emulators to run test installs and ATM my emulator of choice is VirtualBox (the fully open "ose" version). This requires the vboxdrv kernel module, but unfortunately: vboxdrv: Unknown symbol change_page_attr At first I traced this to: e1271f68 x86: deprecate change_page_attr() for drivers With the introduction of the new API, no driver or non-archcore code needs to use c-p-a anymore, so this patch also deprecates the EXPORT_SYMBOL of CPA (it's a horrible API after all). which had: -EXPORT_SYMBOL(change_page_attr); +EXPORT_UNUSED_SYMBOL(change_page_attr); /* to be removed in 2.6.27 */ Which seemed entirely reasonable but left me wondering about the error I got. But then I found: d1028a15 x86: make various pageattr.c functions static change_page_attr_add is only used in pageattr.c now, so we can make this function static. change_page_attr() isn't used anywere at all anymore; this function is a really bad API anyway so just remove the bloat entirely. Which removed the entire function (without even properly mentioning it in the shortlog). OF COURSE it is up to the VirtualBox developers to adjust to the new interface (and based on past experience I expect they will with their next version). And it may very well be that they were totally braindead to use the function in the first place. I don't know and I really don't care. The important fact for me is that I can no longer use a piece of software that is essential to me and thereby lose the motivation to do any work on the kernel. Lesson of the day: thinking only about in-kernel users of published API when doing restructuring is going to lose you testers who do MORE with their systems than just kernel development. Please allow external users some decent period for transitioning. The initial plan to "remove the old function in 2.6.27" was entirely sensible. It's a pity it was not followed through. Thanks, FJP P.S. Of course I _will_ follow up on issues that I've already reported. I will just not be doing any new testing. -- 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/
Unable to continue testing of 2.6.25
Yesterday, after spending quite a few hours over the last days on bisecting some serious regressions and finding workarounds for them, I thought I could start using 2.6.25-rc2 as the new kernel for my desktop. Unfortunately I found that I cannot because it would make my other main activity - working on the Debian installation system - impossible. For my work on the Debian Installer I heavily rely on emulators to run test installs and ATM my emulator of choice is VirtualBox (the fully open ose version). This requires the vboxdrv kernel module, but unfortunately: vboxdrv: Unknown symbol change_page_attr At first I traced this to: e1271f68 x86: deprecate change_page_attr() for drivers With the introduction of the new API, no driver or non-archcore code needs to use c-p-a anymore, so this patch also deprecates the EXPORT_SYMBOL of CPA (it's a horrible API after all). which had: -EXPORT_SYMBOL(change_page_attr); +EXPORT_UNUSED_SYMBOL(change_page_attr); /* to be removed in 2.6.27 */ Which seemed entirely reasonable but left me wondering about the error I got. But then I found: d1028a15 x86: make various pageattr.c functions static change_page_attr_add is only used in pageattr.c now, so we can make this function static. change_page_attr() isn't used anywere at all anymore; this function is a really bad API anyway so just remove the bloat entirely. Which removed the entire function (without even properly mentioning it in the shortlog). OF COURSE it is up to the VirtualBox developers to adjust to the new interface (and based on past experience I expect they will with their next version). And it may very well be that they were totally braindead to use the function in the first place. I don't know and I really don't care. The important fact for me is that I can no longer use a piece of software that is essential to me and thereby lose the motivation to do any work on the kernel. Lesson of the day: thinking only about in-kernel users of published API when doing restructuring is going to lose you testers who do MORE with their systems than just kernel development. Please allow external users some decent period for transitioning. The initial plan to remove the old function in 2.6.27 was entirely sensible. It's a pity it was not followed through. Thanks, FJP P.S. Of course I _will_ follow up on issues that I've already reported. I will just not be doing any new testing. -- 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: [REGRESSION 2.6.23] no vga console and no messages
On Sunday 17 February 2008, Daniel Barkalow wrote: On Sun, 17 Feb 2008, Frans Pop wrote: Daniel Barkalow wrote: For some reason I can't see and don't know how to debug, in 2.6.23 on my server I don't get the vga console, but only get the dummy console. Please check if this bug report matches the issue you are seeing: http://bugzilla.kernel.org/show_bug.cgi?id=9310 I think mine might be different. I've got a vga parameter (vga=0x301), and mine disappears very early, before when you usually get Console: colour VGA+ 80x25 (and I'm getting Console: coloud dummy 80x25 instead). I've also got CONFIG_FB turned off entirely. The main question is: do you have FRAMEBUFFER_CONSOLE_DETECT_PRIMARY enabled in you kernel config. If you do, I'd try disabling it. But if you've got any insight into how the console driver stuff works from troubleshooting your problem, I could use the hints... Afraid not. Are you sure you have the correct framebuffer driver compiled into the kernel? Please post your kernel config and the output of 'lspci -nn', so people can have a look. -- 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: [REGRESSION 2.6.23] no vga console and no messages
Daniel Barkalow wrote: > For some reason I can't see and don't know how to debug, in 2.6.23 on my > server I don't get the vga console, but only get the dummy console. Please check if this bug report matches the issue you are seeing: http://bugzilla.kernel.org/show_bug.cgi?id=9310 Cheers, FJP -- 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: [REGRESSION 2.6.23] no vga console and no messages
Daniel Barkalow wrote: For some reason I can't see and don't know how to debug, in 2.6.23 on my server I don't get the vga console, but only get the dummy console. Please check if this bug report matches the issue you are seeing: http://bugzilla.kernel.org/show_bug.cgi?id=9310 Cheers, FJP -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Friday 15 February 2008, Greg KH wrote:
> I swear someone sent this patch in before. Can you try this one below,
> there seems to be an imbalance with kobject_get and _put.
I did remember seeing this patch before [1] and can confirm that it does
indeed fix the issue: with this patch applied to 2.6.25 git head my system
powers off correctly.
[1] See http://lkml.org/lkml/2008/2/8/342; also added to #9960.
> ---
> drivers/cpufreq/cpufreq.c |8
> 1 file changed, 8 deletions(-)
>
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1006,14 +1006,6 @@ static int __cpufreq_remove_dev (struct
> }
> #endif
>
> -
> - if (!kobject_get(>kobj)) {
> - spin_unlock_irqrestore(_driver_lock, flags);
> - cpufreq_debug_enable_ratelimit();
> - unlock_policy_rwsem_write(cpu);
> - return -EFAULT;
> - }
> -
> #ifdef CONFIG_SMP
>
> #ifdef CONFIG_HOTPLUG_CPU
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Friday 15 February 2008, Greg KH wrote:
I swear someone sent this patch in before. Can you try this one below,
there seems to be an imbalance with kobject_get and _put.
I did remember seeing this patch before [1] and can confirm that it does
indeed fix the issue: with this patch applied to 2.6.25 git head my system
powers off correctly.
[1] See http://lkml.org/lkml/2008/2/8/342; also added to #9960.
---
drivers/cpufreq/cpufreq.c |8
1 file changed, 8 deletions(-)
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1006,14 +1006,6 @@ static int __cpufreq_remove_dev (struct
}
#endif
-
- if (!kobject_get(data-kobj)) {
- spin_unlock_irqrestore(cpufreq_driver_lock, flags);
- cpufreq_debug_enable_ratelimit();
- unlock_policy_rwsem_write(cpu);
- return -EFAULT;
- }
-
#ifdef CONFIG_SMP
#ifdef CONFIG_HOTPLUG_CPU
--
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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Thursday 14 February 2008, Thomas Gleixner wrote: > futex_lock_pi is called with an absolute timeout, which is based on > CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON > might trap over a false positive, when the expiry value is less than > base->offset. This was intentional before we put the WARN_ON into the > clockevents code. > > The patch below should fix this issue. With these two patches on top of 2.6.24.2 I no longer get any warnings during a glibc compile: - hrtimer: check relative timeouts for overflow - hrtimer: fix abs clock realtime Thanks Thomas. Cheers, FJP -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Thursday 14 February 2008, Thomas Gleixner wrote: futex_lock_pi is called with an absolute timeout, which is based on CLOCK_REALTIME. Nothing wrong with that, but the clockevents WARN_ON might trap over a false positive, when the expiry value is less than base-offset. This was intentional before we put the WARN_ON into the clockevents code. The patch below should fix this issue. With these two patches on top of 2.6.24.2 I no longer get any warnings during a glibc compile: - hrtimer: check relative timeouts for overflow - hrtimer: fix abs clock realtime Thanks Thomas. Cheers, FJP -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Wednesday 13 February 2008, Thomas Gleixner wrote: > can you please apply the following patch ? I really should have > thought about that, when I fixed the above one. I still get the bug with this patch. At least I'm now certain it happens during glibc compilation and that I can reproduce it. I applied your patch on top of 2.6.24.2 (applied with only minor offsets) because I also saw the issue with that kernel and I don't yet completely trust 2.6.25. Here's the error from this run: WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 27638, comm: ld-linux.so.2 Not tainted 2.6.24.2-test1 #39 Call Trace: [] ktime_get+0xc/0x41 [] clockevents_program_event+0x3b/0x94 [] tick_program_event+0x31/0x4d [] hrtimer_reprogram+0x3b/0x51 [] enqueue_hrtimer+0x66/0x102 [] hrtimer_start+0x102/0x125 [] :ext3:__ext3_journal_stop+0x1f/0x3d [] rt_mutex_slowlock+0x90/0x53a [] find_lock_page+0x29/0x8d [] find_extend_vma+0x16/0x59 [] get_futex_key+0x82/0x14e [] futex_lock_pi+0x60f/0x90d [] hrtimer_wakeup+0x0/0x21 [] rt_mutex_slowlock+0x90/0x53a [] do_futex+0xa08/0xa3d [] error_exit+0x0/0x51 [] compat_sys_futex+0xf0/0x10e [] __switch_to+0x10e/0x27e [] schedule_tail+0x23/0x60 [] ia32_sysret+0x0/0xa Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, Greg KH wrote: > > So, just on the off chance, I applied the patch below and bingo, the > > system powers off again. I doubt this will be the correct solution, but > > just in case it is, here's my signed off. A comment why the double put > > is needed would probably be good though. > > There is a bug in the cpufreq kref logic that makes this "double put" > necessary. A real fix has already been posted to solve this issue, and > I think it should be on it's way to Linus for -rc2 already. OK, great. Do you think that #6879 could be caused by a similar issue elsewhere in the tree? Can you give me some pointers on how I could find out (debugging to enable, instrumentation to add)? > Please let me know if -rc2 comes out without this needed fix. Will do. -- 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/
[PATCH] kbuild: allow alternative hook script dir in .deb packages
From: Frans Pop <[EMAIL PROTECTED]>
Hook scripts in the default directory /etc/kernel are also
executed by packages created using make-kpkg (including official
Debian kernels). Allow to specify an alternative hook scripts
directory by exporting the environment variable KERNELDEBHOOKDIR
so that this can be avoided.
Signed-off-by: Frans Pop <[EMAIL PROTECTED]>
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 2577dec..c76bbf1 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -55,14 +55,17 @@ if grep -q '^CONFIG_MODULES=y' .config ; then
fi
# Install the maintainer scripts
+# Note: hook scripts under /etc/kernel are also executed by kernel packages
+# built using make-kpkg (from the "kernelpackage" package)
+debhookdir=${KERNELDEBHOOKDIR:-/etc/kernel}
for script in postinst postrm preinst prerm ; do
- mkdir -p "$tmpdir/etc/kernel/$script.d"
+ mkdir -p "$tmpdir$debhookdir/$script.d"
cat < "$tmpdir/DEBIAN/$script"
#!/bin/sh
set -e
-test -d /etc/kernel/$script.d && run-parts --arg="$version"
/etc/kernel/$script.d
+test -d $debhookdir/$script.d && run-parts --arg="$version"
$debhookdir/$script.d
exit 0
EOF
chmod 755 "$tmpdir/DEBIAN/$script"
signature.asc
Description: This is a digitally signed message part.
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: > On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: > > On Monday 11 February 2008, Frans Pop wrote: > > > In general 2.6.25 if looking quite good on my desktop, but there's > > > one important issue: the system no longer powers off after shutdown. > > > This works fine with 2.6.24. > > > > Don't ask me why, but bisection shows this commit to be the cause of > > the failure to power off: > > commit c10997f6575f476ff38442fa18fd4a0d80345f9d > > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > Date: Thu Dec 20 08:13:05 2007 -0800 > > > > Kobject: convert drivers/* from kobject_unregister() to > > kobject_put() > > > > Because it seemed somewhat unlikely, I have double checked this by > > doing an extra compilation for this commit and its predecessor. > > What is the symptom of not powering off? I already noticed yesterday that there's one hunk in that commit that's not a straight replacement: diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 9e102af..5efd555 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1030,8 +1030,6 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); - kobject_unregister(>kobj); - kobject_put(>kobj); /* we need to make sure that the underlying kobj is actually So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. Signed-off-by: Frans Pop <[EMAIL PROTECTED]> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 64926aa..9dbaac6 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1058,6 +1058,7 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); kobject_put(>kobj); + kobject_put(>kobj); /* we need to make sure that the underlying kobj is actually * not referenced anymore by anybody before we proceed with -- 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/
[PATCH] kbuild: allow to specify a custom revision for .deb packages
From: Frans Pop <[EMAIL PROTECTED]> Allow to specify a custom revision for the generated .deb package by exporting the environment variable KERNELDEBREVISION. Signed-off-by: Frans Pop <[EMAIL PROTECTED]> diff --git a/scripts/package/builddeb b/scripts/package/builddeb index ba6bf5d..2577dec 100644 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -14,6 +14,11 @@ set -e # Some variables and settings used throughout the script version=$KERNELRELEASE revision=`cat .version` +if [ x"$KERNELDEBREVISION" = x ]; then + debrevision=$version-$revision +else + debrevision=$KERNELDEBREVISION +fi tmpdir="$objtree/debian/tmp" packagename=linux-$version @@ -66,7 +71,7 @@ done name="Kernel Compiler <$(id -nu)@$(hostname -f)>" # Generate a simple changelog template cat < debian/changelog -linux ($version-$revision) unstable; urgency=low +linux ($debrevision) unstable; urgency=low * A standard release -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, you wrote: > On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > > Symptom is that the system shuts down normally and completely, it just > > does not power off. > > I've been struggling with an identically-manifesting regression on one of > my test machines for a week. It's due to softlockup changes, and setting > CONFIG_DETECT_SOFTLOCKUP=n "fixes" it. > > It sounds unlikely, but I'd suggest that you see if it's the same on your > machine so we're not both chasing the same bug. Unsetting CONFIG_DETECT_SOFTLOCKUP does not help in my case, but thanks for the suggestion. -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Wednesday 13 February 2008, Thomas Gleixner wrote: > On Tue, 12 Feb 2008, Andrew Morton wrote: > > On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop <[EMAIL PROTECTED]> wrote: > > the hrtimer code is preparing an invalid ktime_t. Note that > > clockevents_program_event() actually fails when this happens - I am > > surprised that this is not causing observeable userspace problems. > > > > The WARN_ON_ONCE() means that you'll only see this warning once per > > boot. But the actually error could be happening any number of times > > without being reported. > > > > Looks pretty serious? > > Yes. It's the same problem, which got fixed with: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit >;h=62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 OK, so probably glibc performs a unit test during build that asks for a long sleep. I guess that makes sense. Thanks Thomas and Andrew. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] jerky mouse cursor and randoooom key repeats
On Monday 11 February 2008, Frans Pop wrote: > In general 2.6.25 if looking quite good on my desktop, but there's one > important issue: the system no longer powers off after shutdown. > This works fine with 2.6.24. I was wrong :-( I'd not really done any real wor under 2.6.25 yet, but now while running a kernel compile with -j4 (single processor, dual core Pentium D), I see this behavior. The mouse cursor moves a bit jerky and I sometimes get key presses repeated. While I'm typing this, the load lowers a bit and immediately things become smoother and the key repeats seem to vanish. (The key repeats in the subject and para above are real examples of this, not typo's.) The keyboard repeat issue looks like what was reported in [1], but for me this is very definitely an new issue that did not appear with 2.6.24 or earlier. Cheers, FJP [1] http://lkml.org/lkml/2008/2/6/100 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] jerky mouse cursor and randoooom key repeats
On Monday 11 February 2008, Frans Pop wrote: In general 2.6.25 if looking quite good on my desktop, but there's one important issue: the system no longer powers off after shutdown. This works fine with 2.6.24. I was wrong :-( I'd not really done any real wor under 2.6.25 yet, but now while running a kernel compile with -j4 (single processor, dual core Pentium D), I see this behavior. The mouse cursor moves a bit jerky and I sometimes get key presses repeated. While I'm typing this, the load lowers a bit and immediately things become smoother and the key repeats seem to vanish. (The key repeats in the subject and para above are real examples of this, not typo's.) The keyboard repeat issue looks like what was reported in [1], but for me this is very definitely an new issue that did not appear with 2.6.24 or earlier. Cheers, FJP [1] http://lkml.org/lkml/2008/2/6/100 -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Wednesday 13 February 2008, Thomas Gleixner wrote: On Tue, 12 Feb 2008, Andrew Morton wrote: On Sun, 10 Feb 2008 14:40:21 +0100 Frans Pop [EMAIL PROTECTED] wrote: the hrtimer code is preparing an invalid ktime_t. Note that clockevents_program_event() actually fails when this happens - I am surprised that this is not causing observeable userspace problems. The WARN_ON_ONCE() means that you'll only see this warning once per boot. But the actually error could be happening any number of times without being reported. Looks pretty serious? Yes. It's the same problem, which got fixed with: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit ;h=62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 OK, so probably glibc performs a unit test during build that asks for a long sleep. I guess that makes sense. Thanks Thomas and Andrew. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, you wrote: On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop [EMAIL PROTECTED] wrote: Symptom is that the system shuts down normally and completely, it just does not power off. I've been struggling with an identically-manifesting regression on one of my test machines for a week. It's due to softlockup changes, and setting CONFIG_DETECT_SOFTLOCKUP=n fixes it. It sounds unlikely, but I'd suggest that you see if it's the same on your machine so we're not both chasing the same bug. Unsetting CONFIG_DETECT_SOFTLOCKUP does not help in my case, but thanks for the suggestion. -- 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/
[PATCH] kbuild: allow to specify a custom revision for .deb packages
From: Frans Pop [EMAIL PROTECTED] Allow to specify a custom revision for the generated .deb package by exporting the environment variable KERNELDEBREVISION. Signed-off-by: Frans Pop [EMAIL PROTECTED] diff --git a/scripts/package/builddeb b/scripts/package/builddeb index ba6bf5d..2577dec 100644 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -14,6 +14,11 @@ set -e # Some variables and settings used throughout the script version=$KERNELRELEASE revision=`cat .version` +if [ x$KERNELDEBREVISION = x ]; then + debrevision=$version-$revision +else + debrevision=$KERNELDEBREVISION +fi tmpdir=$objtree/debian/tmp packagename=linux-$version @@ -66,7 +71,7 @@ done name=Kernel Compiler $(id -nu)@$(hostname -f) # Generate a simple changelog template cat EOF debian/changelog -linux ($version-$revision) unstable; urgency=low +linux ($debrevision) unstable; urgency=low * A standard release -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: On Monday 11 February 2008, Frans Pop wrote: In general 2.6.25 if looking quite good on my desktop, but there's one important issue: the system no longer powers off after shutdown. This works fine with 2.6.24. Don't ask me why, but bisection shows this commit to be the cause of the failure to power off: commit c10997f6575f476ff38442fa18fd4a0d80345f9d Author: Greg Kroah-Hartman [EMAIL PROTECTED] Date: Thu Dec 20 08:13:05 2007 -0800 Kobject: convert drivers/* from kobject_unregister() to kobject_put() Because it seemed somewhat unlikely, I have double checked this by doing an extra compilation for this commit and its predecessor. What is the symptom of not powering off? I already noticed yesterday that there's one hunk in that commit that's not a straight replacement: diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 9e102af..5efd555 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1030,8 +1030,6 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); - kobject_unregister(data-kobj); - kobject_put(data-kobj); /* we need to make sure that the underlying kobj is actually So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. Signed-off-by: Frans Pop [EMAIL PROTECTED] diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 64926aa..9dbaac6 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1058,6 +1058,7 @@ static int __cpufreq_remove_dev (struct sys_device * sys_dev) unlock_policy_rwsem_write(cpu); kobject_put(data-kobj); + kobject_put(data-kobj); /* we need to make sure that the underlying kobj is actually * not referenced anymore by anybody before we proceed with -- 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/
[PATCH] kbuild: allow alternative hook script dir in .deb packages
From: Frans Pop [EMAIL PROTECTED]
Hook scripts in the default directory /etc/kernel are also
executed by packages created using make-kpkg (including official
Debian kernels). Allow to specify an alternative hook scripts
directory by exporting the environment variable KERNELDEBHOOKDIR
so that this can be avoided.
Signed-off-by: Frans Pop [EMAIL PROTECTED]
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 2577dec..c76bbf1 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -55,14 +55,17 @@ if grep -q '^CONFIG_MODULES=y' .config ; then
fi
# Install the maintainer scripts
+# Note: hook scripts under /etc/kernel are also executed by kernel packages
+# built using make-kpkg (from the kernelpackage package)
+debhookdir=${KERNELDEBHOOKDIR:-/etc/kernel}
for script in postinst postrm preinst prerm ; do
- mkdir -p $tmpdir/etc/kernel/$script.d
+ mkdir -p $tmpdir$debhookdir/$script.d
cat EOF $tmpdir/DEBIAN/$script
#!/bin/sh
set -e
-test -d /etc/kernel/$script.d run-parts --arg=$version
/etc/kernel/$script.d
+test -d $debhookdir/$script.d run-parts --arg=$version
$debhookdir/$script.d
exit 0
EOF
chmod 755 $tmpdir/DEBIAN/$script
signature.asc
Description: This is a digitally signed message part.
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Wednesday 13 February 2008, Greg KH wrote: So, just on the off chance, I applied the patch below and bingo, the system powers off again. I doubt this will be the correct solution, but just in case it is, here's my signed off. A comment why the double put is needed would probably be good though. There is a bug in the cpufreq kref logic that makes this double put necessary. A real fix has already been posted to solve this issue, and I think it should be on it's way to Linus for -rc2 already. OK, great. Do you think that #6879 could be caused by a similar issue elsewhere in the tree? Can you give me some pointers on how I could find out (debugging to enable, instrumentation to add)? Please let me know if -rc2 comes out without this needed fix. Will do. -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Wednesday 13 February 2008, Thomas Gleixner wrote: can you please apply the following patch ? I really should have thought about that, when I fixed the above one. I still get the bug with this patch. At least I'm now certain it happens during glibc compilation and that I can reproduce it. I applied your patch on top of 2.6.24.2 (applied with only minor offsets) because I also saw the issue with that kernel and I don't yet completely trust 2.6.25. Here's the error from this run: WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 27638, comm: ld-linux.so.2 Not tainted 2.6.24.2-test1 #39 Call Trace: [8024afaf] ktime_get+0xc/0x41 [8024ea59] clockevents_program_event+0x3b/0x94 [8024f8c8] tick_program_event+0x31/0x4d [8024a2fd] hrtimer_reprogram+0x3b/0x51 [8024a478] enqueue_hrtimer+0x66/0x102 [8024ad38] hrtimer_start+0x102/0x125 [8819f403] :ext3:__ext3_journal_stop+0x1f/0x3d [803f8dcc] rt_mutex_slowlock+0x90/0x53a [802667e8] find_lock_page+0x29/0x8d [80277a78] find_extend_vma+0x16/0x59 [802509b2] get_futex_key+0x82/0x14e [80251ac5] futex_lock_pi+0x60f/0x90d [8024a70d] hrtimer_wakeup+0x0/0x21 [803f8dcc] rt_mutex_slowlock+0x90/0x53a [802527cb] do_futex+0xa08/0xa3d [803f9c59] error_exit+0x0/0x51 [80252d48] compat_sys_futex+0xf0/0x10e [8020a6f1] __switch_to+0x10e/0x27e [80231889] schedule_tail+0x23/0x60 [80223972] ia32_sysret+0x0/0xa Cheers, FJP -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: > On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: > > On Monday 11 February 2008, Frans Pop wrote: > > > In general 2.6.25 if looking quite good on my desktop, but there's > > > one important issue: the system no longer powers off after shutdown. > > > This works fine with 2.6.24. > > > > Don't ask me why, but bisection shows this commit to be the cause of > > the failure to power off: > > commit c10997f6575f476ff38442fa18fd4a0d80345f9d > > Author: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > Date: Thu Dec 20 08:13:05 2007 -0800 > > > > Kobject: convert drivers/* from kobject_unregister() to > > kobject_put() > > > > Because it seemed somewhat unlikely, I have double checked this by > > doing an extra compilation for this commit and its predecessor. > > What is the symptom of not powering off? Symptom is that the system shuts down normally and completely, it just does not power off. Here are the last messages on the console: Will now halt. sd 1:0:0:0: [sdb] Synchronizing SCSI cache sd 1:0:0:0: [sdb] Stopping disk sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device :01:00.0 disabled Disabling non-boot CPUs ... > Can you press SysRq-T and see a task list running and waiting when > things should be shut down? The system does not respond to that anymore. > Do you happen to have a USB storage stick plugged into the system? Nothing. Only USB kbd/mouse. Note that I've had this issue before with this box: http://bugzilla.kernel.org/show_bug.cgi?id=6879 Somehow it disappeared when I pulled the extra video card that came with the system (no decent driver for it, so no loss). Since then the system has always powered off completely reliably. This time it is a clear and reproducible regression. If we can solve this one we might get a better handle on #6879 too. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1] System no longer powers off after shutdown
On Tuesday 12 February 2008, Greg KH wrote: On Tue, Feb 12, 2008 at 09:39:14PM +0100, Frans Pop wrote: On Monday 11 February 2008, Frans Pop wrote: In general 2.6.25 if looking quite good on my desktop, but there's one important issue: the system no longer powers off after shutdown. This works fine with 2.6.24. Don't ask me why, but bisection shows this commit to be the cause of the failure to power off: commit c10997f6575f476ff38442fa18fd4a0d80345f9d Author: Greg Kroah-Hartman [EMAIL PROTECTED] Date: Thu Dec 20 08:13:05 2007 -0800 Kobject: convert drivers/* from kobject_unregister() to kobject_put() Because it seemed somewhat unlikely, I have double checked this by doing an extra compilation for this commit and its predecessor. What is the symptom of not powering off? Symptom is that the system shuts down normally and completely, it just does not power off. Here are the last messages on the console: Will now halt. sd 1:0:0:0: [sdb] Synchronizing SCSI cache sd 1:0:0:0: [sdb] Stopping disk sd 0:0:0:0: [sda] Synchronizing SCSI cache sd 0:0:0:0: [sda] Stopping disk ACPI: PCI interrupt for device :01:00.0 disabled Disabling non-boot CPUs ... Can you press SysRq-T and see a task list running and waiting when things should be shut down? The system does not respond to that anymore. Do you happen to have a USB storage stick plugged into the system? Nothing. Only USB kbd/mouse. Note that I've had this issue before with this box: http://bugzilla.kernel.org/show_bug.cgi?id=6879 Somehow it disappeared when I pulled the extra video card that came with the system (no decent driver for it, so no loss). Since then the system has always powered off completely reliably. This time it is a clear and reproducible regression. If we can solve this one we might get a better handle on #6879 too. Cheers, FJP -- 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: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Sunday 10 February 2008, Frans Pop wrote: > I have no idea yet what triggers it and am unsure if I'll be able to > reproduce. I think I know at least _when_ it happens: during compilation of glibc. This was almost certainly while compiling in the normal amd64 environment: > Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1 And this was while compiling the glibc in an i386 unstable chroot: > Pid: 29517, comm: ld-linux.so.2 Not tainted 2.6.24 #1 Could it be that some glibc unit test triggers this? I have done one other compile of glibc yesterday though that did _not_ trigger the error, but that was using pbuilder (i.e. in an amd64 chroot). -- 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/
[stable 2.6.24] WARNING: at kernel/time/clockevents.c
Kernel: vanilla 2.6.24 x86_64 SMP Environment: Debian unstable Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core) I've been running this kernel without problems since its release, but yesterday evening I suddenly got the following error, and this afternoon it was repeated (below). The system had been powered down in between. I have no idea yet what triggers it and am unsure if I'll be able to reproduce. WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1 Call Trace: [] ktime_get+0xc/0x41 [] clockevents_program_event+0x3b/0x94 [] tick_program_event+0x31/0x4d [] hrtimer_reprogram+0x3b/0x51 [] enqueue_hrtimer+0x66/0x102 [] hrtimer_start+0x105/0x128 [] rt_mutex_slowlock+0x90/0x53a [] find_extend_vma+0x16/0x59 [] get_futex_key+0x82/0x14e [] futex_lock_pi+0x60f/0x90d [] hrtimer_wakeup+0x0/0x21 [] rt_mutex_slowlock+0x90/0x53a [] do_futex+0xa08/0xa3d [] __dequeue_entity+0x1c/0x32 [] thread_return+0x3a/0xab [] sys_futex+0xe0/0xfe [] system_call+0x7e/0x83 WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 29517, comm: ld-linux.so.2 Not tainted 2.6.24 #1 Call Trace: [] ktime_get+0xc/0x41 [] clockevents_program_event+0x3b/0x94 [] tick_program_event+0x31/0x4d [] hrtimer_reprogram+0x3b/0x51 [] enqueue_hrtimer+0x66/0x102 [] hrtimer_start+0x105/0x128 [] rt_mutex_slowlock+0x90/0x53a [] thread_return+0x3a/0xab [] find_lock_page+0x29/0x8d [] find_extend_vma+0x16/0x59 [] get_futex_key+0x82/0x14e [] futex_lock_pi+0x60f/0x90d [] hrtimer_wakeup+0x0/0x21 [] rt_mutex_slowlock+0x90/0x53a [] do_futex+0xa08/0xa3d [] error_exit+0x0/0x51 [] compat_sys_futex+0xda/0xf8 [] ia32_sysret+0x0/0xa Any ideas? Cheers, FJP # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 # Fri Jan 25 00:28:04 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_HT=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set 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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # 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_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is
[stable 2.6.24] WARNING: at kernel/time/clockevents.c
Kernel: vanilla 2.6.24 x86_64 SMP Environment: Debian unstable Processor: Intel(R) Pentium(R) D CPU 3.20GHz (dual core) I've been running this kernel without problems since its release, but yesterday evening I suddenly got the following error, and this afternoon it was repeated (below). The system had been powered down in between. I have no idea yet what triggers it and am unsure if I'll be able to reproduce. WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1 Call Trace: [8024af78] ktime_get+0xc/0x41 [8024ea21] clockevents_program_event+0x3b/0x94 [8024f890] tick_program_event+0x31/0x4d [8024a2c3] hrtimer_reprogram+0x3b/0x51 [8024a43e] enqueue_hrtimer+0x66/0x102 [8024ad01] hrtimer_start+0x105/0x128 [803f8c9c] rt_mutex_slowlock+0x90/0x53a [80277a00] find_extend_vma+0x16/0x59 [8025097a] get_futex_key+0x82/0x14e [80251a8d] futex_lock_pi+0x60f/0x90d [8024a6d3] hrtimer_wakeup+0x0/0x21 [803f8c9c] rt_mutex_slowlock+0x90/0x53a [80252793] do_futex+0xa08/0xa3d [8022bd23] __dequeue_entity+0x1c/0x32 [803f8261] thread_return+0x3a/0xab [802528a8] sys_futex+0xe0/0xfe [8020befe] system_call+0x7e/0x83 WARNING: at kernel/time/clockevents.c:82 clockevents_program_event() Pid: 29517, comm: ld-linux.so.2 Not tainted 2.6.24 #1 Call Trace: [8024af78] ktime_get+0xc/0x41 [8024ea21] clockevents_program_event+0x3b/0x94 [8024f890] tick_program_event+0x31/0x4d [8024a2c3] hrtimer_reprogram+0x3b/0x51 [8024a43e] enqueue_hrtimer+0x66/0x102 [8024ad01] hrtimer_start+0x105/0x128 [803f8c9c] rt_mutex_slowlock+0x90/0x53a [803f8261] thread_return+0x3a/0xab [8026677d] find_lock_page+0x29/0x8d [80277a00] find_extend_vma+0x16/0x59 [8025097a] get_futex_key+0x82/0x14e [80251a8d] futex_lock_pi+0x60f/0x90d [8024a6d3] hrtimer_wakeup+0x0/0x21 [803f8c9c] rt_mutex_slowlock+0x90/0x53a [80252793] do_futex+0xa08/0xa3d [803f9b29] error_exit+0x0/0x51 [80252ce2] compat_sys_futex+0xda/0xf8 [80223972] ia32_sysret+0x0/0xa Any ideas? Cheers, FJP # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24 # Fri Jan 25 00:28:04 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_HT=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set 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_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO
Re: [stable 2.6.24] WARNING: at kernel/time/clockevents.c
On Sunday 10 February 2008, Frans Pop wrote: I have no idea yet what triggers it and am unsure if I'll be able to reproduce. I think I know at least _when_ it happens: during compilation of glibc. This was almost certainly while compiling in the normal amd64 environment: Pid: 2210, comm: ld-linux-x86-64 Not tainted 2.6.24 #1 And this was while compiling the glibc in an i386 unstable chroot: Pid: 29517, comm: ld-linux.so.2 Not tainted 2.6.24 #1 Could it be that some glibc unit test triggers this? I have done one other compile of glibc yesterday though that did _not_ trigger the error, but that was using pbuilder (i.e. in an amd64 chroot). -- 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: [PATCH] x86: restore correct module name for apm
Sam Ravnborg wrote: > The apm module were renamed to apm_32 during the merge of 32 and 64 bit > x86 which is unfortunate. > As apm is 32 bit specific we like to keep the _32 in the filename > but the module should be named apm. > > Fix this in the Makefile. > Reported by "A.E.Lawrence" <[EMAIL PROTECTED]> > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Cc: Ingo Molnar <[EMAIL PROTECTED]> > Cc: Thomas Gleixner <[EMAIL PROTECTED]> > Cc: "H. Peter Anvin" <[EMAIL PROTECTED]> > Cc: "A.E.Lawrence" <[EMAIL PROTECTED]> I assume this will be pushed for stable 2.6.24 as well? Cheers, FJP -- 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: [PATCH] x86: restore correct module name for apm
Sam Ravnborg wrote: The apm module were renamed to apm_32 during the merge of 32 and 64 bit x86 which is unfortunate. As apm is 32 bit specific we like to keep the _32 in the filename but the module should be named apm. Fix this in the Makefile. Reported by A.E.Lawrence [EMAIL PROTECTED] Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Cc: Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Thomas Gleixner [EMAIL PROTECTED] Cc: H. Peter Anvin [EMAIL PROTECTED] Cc: A.E.Lawrence [EMAIL PROTECTED] I assume this will be pushed for stable 2.6.24 as well? Cheers, FJP -- 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: [REVIEW for merge] kbuild updates including silence of section mismatch check
Sam Ravnborg wrote:
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -45,3 +45,18 @@ if hgid=`hg id 2>/dev/null`; then
> # All done with mercurial
> exit
> fi
> +
> +# Check for svn and a svn repo.
> +if rev=`svn info 2>/dev/null | grep '^Revision' | awk '{print $NF}'` ; then
> + changes=`svn status 2>/dev/null | grep '^[AMD]' | wc -l`
> +
> + # Are there uncommitted changes?
> + if [ $changes != 0 ]; then
> + printf -- '-svn%s%s%s' "$rev" -dirty "$changes"
> + else
> + printf -- '-svn%s' "$rev"
> + fi
> +
> + # All done with svn
> + exit
> +fi
This looks broken. Unless I'm very much mistaken the 'if' statement is
always going to be true because the awk statement will always execute
without error. Try: echo "" | awk '{print $NF}' || echo Error
So, the code should probably be changed to:
+if rev=`svn info 2>/dev/null | grep '^Revision' ; then
+ rev=`echo $rev | awk '{print $NF}'`
+ changes=`svn status 2>/dev/null | grep '^[AMD]' | wc -l`
or alternatively:
+if rev=`svn info 2>/dev/null | grep '^Revision' | awk '{print $NF}'` && \
+ [ -n "$rev" ] ; then
+ changes=`svn status 2>/dev/null | grep '^[AMD]' | wc -l`
Cheers,
FJP
P.S. Looks like the mercurial section is missing some indentation.
--
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: Incompatibility of "const" and __xxxinitdata?
Peter Teoh wrote: > In include/linux/init.h, it is documented that all __xxxinitdata > declaration must not have constant, as show below: See: http://lkml.org/lkml/2008/1/26/182 There's a fairly major cleanup happening at the moment as you could see from the mailing list archives for the past week or so. Cheers, FJP -- 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: Incompatibility of const and __xxxinitdata?
Peter Teoh wrote: In include/linux/init.h, it is documented that all __xxxinitdata declaration must not have constant, as show below: See: http://lkml.org/lkml/2008/1/26/182 There's a fairly major cleanup happening at the moment as you could see from the mailing list archives for the past week or so. Cheers, FJP -- 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: [REVIEW for merge] kbuild updates including silence of section mismatch check
Sam Ravnborg wrote:
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -45,3 +45,18 @@ if hgid=`hg id 2/dev/null`; then
# All done with mercurial
exit
fi
+
+# Check for svn and a svn repo.
+if rev=`svn info 2/dev/null | grep '^Revision' | awk '{print $NF}'` ; then
+ changes=`svn status 2/dev/null | grep '^[AMD]' | wc -l`
+
+ # Are there uncommitted changes?
+ if [ $changes != 0 ]; then
+ printf -- '-svn%s%s%s' $rev -dirty $changes
+ else
+ printf -- '-svn%s' $rev
+ fi
+
+ # All done with svn
+ exit
+fi
This looks broken. Unless I'm very much mistaken the 'if' statement is
always going to be true because the awk statement will always execute
without error. Try: echo | awk '{print $NF}' || echo Error
So, the code should probably be changed to:
+if rev=`svn info 2/dev/null | grep '^Revision' ; then
+ rev=`echo $rev | awk '{print $NF}'`
+ changes=`svn status 2/dev/null | grep '^[AMD]' | wc -l`
or alternatively:
+if rev=`svn info 2/dev/null | grep '^Revision' | awk '{print $NF}'` \
+ [ -n $rev ] ; then
+ changes=`svn status 2/dev/null | grep '^[AMD]' | wc -l`
Cheers,
FJP
P.S. Looks like the mercurial section is missing some indentation.
--
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: Typo in net/netfilter/xt_iprange.c (git tree)
Forward to netdev list. --- Forwarded message (begin) Subject: Typo in net/netfilter/xt_iprange.c (git tree) From: Jiri Moravec <...> Date: Fri, 01 Feb 2008 15:50:15 +0100 Function iprange_mt4 belong to IPv4 family - AF_INET. Right? .name = "iprange", .revision = 1, .family= AF_INET6, <-- Typo? .match = iprange_mt4, .matchsize = sizeof(struct xt_iprange_mtinfo), .me= THIS_MODULE, --- Forwarded message (end) -- 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: Typo in net/netfilter/xt_iprange.c (git tree)
Forward to netdev list. --- Forwarded message (begin) Subject: Typo in net/netfilter/xt_iprange.c (git tree) From: Jiri Moravec ... Date: Fri, 01 Feb 2008 15:50:15 +0100 Function iprange_mt4 belong to IPv4 family - AF_INET. Right? .name = iprange, .revision = 1, .family= AF_INET6, -- Typo? .match = iprange_mt4, .matchsize = sizeof(struct xt_iprange_mtinfo), .me= THIS_MODULE, --- Forwarded message (end) -- 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: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
Adrian Bunk wrote: >> Jeff, Auke, would something like this be acceptable? It makes it very >> obvious in the driver table which entries are for the PCIE versions that >> would be handled by the E1000E driver if it is enabled.. > > I don't like it: > We should aim at having exactly one driver for one card. There is one thing I don't understand, but that may well be just me... >From Linus' original patch: > +++ b/drivers/net/e1000/e1000_main.c > + INTEL_E1000_ETHERNET_DEVICE(0x108C), So, apparently support for 8086:108c was removed from the e1000 driver. >From my lspci: $ lspci -nn | grep Ether 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03) But when I look at where that card is sitting: $ readlink pci/devices/\:01\:00.0/driver ../../../../bus/pci/drivers/e1000 So, it's on the PCI bus, not on the PCI-Express bus (which I also have, but which has no devices on it). Or does the e1000e driver also support cards on the PCI bus? If that's the case then the original changelog entry "Move PCI-Express device IDs over to e1000e" is misleading as it's not only PCI-Express devices... Hmmm. Or does which driver is loaded decide on which bus the device ends up? Confused, FJP -- 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: Mostly revert e1000/e1000e: Move PCI-Express device IDs over to e1000e
Adrian Bunk wrote: Jeff, Auke, would something like this be acceptable? It makes it very obvious in the driver table which entries are for the PCIE versions that would be handled by the E1000E driver if it is enabled.. I don't like it: We should aim at having exactly one driver for one card. There is one thing I don't understand, but that may well be just me... From Linus' original patch: +++ b/drivers/net/e1000/e1000_main.c + INTEL_E1000_ETHERNET_DEVICE(0x108C), So, apparently support for 8086:108c was removed from the e1000 driver. From my lspci: $ lspci -nn | grep Ether 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03) But when I look at where that card is sitting: $ readlink pci/devices/\:01\:00.0/driver ../../../../bus/pci/drivers/e1000 So, it's on the PCI bus, not on the PCI-Express bus (which I also have, but which has no devices on it). Or does the e1000e driver also support cards on the PCI bus? If that's the case then the original changelog entry Move PCI-Express device IDs over to e1000e is misleading as it's not only PCI-Express devices... Hmmm. Or does which driver is loaded decide on which bus the device ends up? Confused, FJP -- 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: [PATCH 1/2] dm-band: The I/O bandwidth controller: Source code patch
Frans Pop wrote: > The help should probably be a bit more verbose as this does not tell > anybody much who has not already read the documentation. > > Maybe something like: > > This device-mapper target allows to define how the > available bandwith of a storage device should be > shared between processes or cgroups. > > Information on how to use dm-band is available in: >Documentation/device-mapper/band.txt > I just see in other Kconfig files that the last line should be: . Cheers, FJP -- 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/
[PATCH] Use on-board instead of built-in in config options
On Saturday 26 January 2008, Bartlomiej Zolnierkiewicz wrote: > On Saturday 26 January 2008, Jan Engelhardt wrote: > > On Jan 26 2008 21:31, Frans Pop wrote: > > >> config BLK_DEV_IDE_PMAC > > >> - bool "Builtin PowerMac IDE support" > > >> + tristate "Builtin PowerMac IDE support" > > this change is no-op at the moment because the next Kconfig line is: > > depends on PPC_PMAC && IDE=y && BLK_DEV_IDE=y > > [ PPC-specific IDE host drivers are still a special case because they are > using ppc_ide_md architecture hooks instead of doing proper host driver > initialization sequence - to be fixed after adding warm-plug support... > ] > > > >This does not seem to make sense: if the option is now tristate, it is > > > no longer "Builtin", so probably s/Builtin // in the description. > > > > Or something like s/Builtin/Onboard/; I did not even consider that meaning of built-in, but that does seem more descriptive. > Please send a patch. Of course :-) --- From: Frans Pop <[EMAIL PROTECTED]> To avoid confusion between 'built-in' drivers and 'on-board' controllers, consistently use the term 'on-board' for controllers. Minor line-wrapping improvements in descriptions for config options. Signed-off-by: Frans Pop <[EMAIL PROTECTED]> --- Spelling for on-board seems to be rather inconsistent. All of "on board", "on-board" and onboard currently occur. I've chosen "on-board" as that seems most correct to me. diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig index 64df55e..92b0117 100644 --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -617,8 +617,8 @@ config BLK_DEV_SC1200 tristate "National SCx200 chipset support" select BLK_DEV_IDEDMA_PCI help - This driver adds support for the built in IDE on the National - SCx200 series of embedded x86 "Geode" systems + This driver adds support for the on-board IDE controller on the + National SCx200 series of embedded x86 "Geode" systems. config BLK_DEV_PIIX tristate "Intel PIIXn chipsets support" @@ -793,22 +793,22 @@ config BLK_DEV_CELLEB depends on PPC_CELLEB select BLK_DEV_IDEDMA_PCI help - This driver provides support for the built-in IDE controller on + This driver provides support for the on-board IDE controller on Toshiba Cell Reference Board. If unsure, say Y. endif config BLK_DEV_IDE_PMAC - tristate "Builtin PowerMac IDE support" + tristate "PowerMac on-board IDE support" depends on PPC_PMAC && IDE=y && BLK_DEV_IDE=y help - This driver provides support for the built-in IDE controller on + This driver provides support for the on-board IDE controller on most of the recent Apple Power Macintoshes and PowerBooks. If unsure, say Y. config BLK_DEV_IDE_PMAC_ATA100FIRST - bool "Probe internal ATA/100 (Kauai) first" + bool "Probe on-board ATA/100 (Kauai) first" depends on BLK_DEV_IDE_PMAC help This option will cause the ATA/100 controller found in UniNorth2 @@ -823,7 +823,7 @@ config BLK_DEV_IDEDMA_PMAC depends on BLK_DEV_IDE_PMAC select BLK_DEV_IDEDMA_PCI help - This option allows the driver for the built-in IDE controller on + This option allows the driver for the on-board IDE controller on Power Macintoshes and PowerBooks to use DMA (direct memory access) to transfer data to and from memory. Saying Y is safe and improves performance. @@ -934,7 +934,7 @@ config BLK_DEV_GAYLE help This is the IDE driver for the Amiga Gayle IDE interface. It supports both the `A1200 style' and `A4000 style' of the Gayle IDE interface, - This includes builtin IDE interfaces on some Amiga models (A600, + This includes on-board IDE interfaces on some Amiga models (A600, A1200, A4000, and A4000T), and IDE interfaces on the Zorro expansion bus (M-Tech E-Matrix 530 expansion card). Say Y if you have an Amiga with a Gayle IDE interface and want to use @@ -948,10 +948,10 @@ config BLK_DEV_IDEDOUBLER depends on BLK_DEV_GAYLE && EXPERIMENTAL ---help--- This driver provides support for the so-called `IDE doublers' (made - by various manufacturers, e.g. Eyetech) that can be connected to the - builtin IDE interface of some Amiga models. Using such an IDE - doubler, you can connect up to four instead of two IDE devices on - the Amiga's builtin IDE interface. + by various manufacturers, e.g. Eyetech) that can be connected to + the on-board IDE interface of some Amiga models. Using such an IDE + doubler, you can connect up to four instead of two IDE devices to + the Amiga's on-board IDE interface. Note that the normal Amiga Gayle IDE driver may not work correctly if you have an IDE doubler and don't enable this driver!
Re: [PATCH 1/2] dm-band: The I/O bandwidth controller: Source code patch
Frans Pop wrote: The help should probably be a bit more verbose as this does not tell anybody much who has not already read the documentation. Maybe something like: snip This device-mapper target allows to define how the available bandwith of a storage device should be shared between processes or cgroups. Information on how to use dm-band is available in: Documentation/device-mapper/band.txt /snip I just see in other Kconfig files that the last line should be: file:Documentation/device-mapper/band.txt. Cheers, FJP -- 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: From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> (linux.* mail to news gateway)
> config BLK_DEV_IDE_PMAC > - bool "Builtin PowerMac IDE support" > + tristate "Builtin PowerMac IDE support" This does not seem to make sense: if the option is now tristate, it is no longer "Builtin", so probably s/Builtin // in the description. Cheers, FJP -- 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: From: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] (linux.* mail to news gateway)
config BLK_DEV_IDE_PMAC - bool Builtin PowerMac IDE support + tristate Builtin PowerMac IDE support This does not seem to make sense: if the option is now tristate, it is no longer Builtin, so probably s/Builtin // in the description. Cheers, FJP -- 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: [PATCH] [NET]: Remove PowerPC code from fec.c
On Friday 25 January 2008, Jochen Friedrich wrote: > > Jochen Friedrich wrote: > >> +++ b/drivers/net/fec.c > >> @@ -23,6 +23,9 @@ > >> * > >> * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED]) > >> * Copyright (c) 2004-2006 Macq Electronique SA. > >> + * > >> + * This driver is now only used on ColdFire processors. Remove conditional > >> + * Powerpc code. > >> */ > > > > This comment makes sense for a changelog, but IMO it makes no sense at > > all to add it to the file. > > I just added it to clarify this code is now only used on m68knommu > (Coldfire). The comments on top are mailny about MPC860T CPUs (PowerPC), > however the driver is no longer used for these CPUs. > > Maybe the wording should be changed to: > > This driver is now only used on ColdFire (m68knommu) processors. > Conditional PowerPC code has been removed. Yes, that certainly makes more sense, although IMHO the second sentence is still somewhat redundant. (My problem was mainly with the second sentence. I should have made that more clear, sorry.) -- 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: [PATCH] [NET]: Remove PowerPC code from fec.c
Jochen Friedrich wrote: > +++ b/drivers/net/fec.c > @@ -23,6 +23,9 @@ > * > * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED]) > * Copyright (c) 2004-2006 Macq Electronique SA. > + * > + * This driver is now only used on ColdFire processors. Remove conditional > + * Powerpc code. > */ This comment makes sense for a changelog, but IMO it makes no sense at all to add it to the file. Cheers, FJP -- 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: [PATCH] [NET]: Remove PowerPC code from fec.c
Jochen Friedrich wrote: +++ b/drivers/net/fec.c @@ -23,6 +23,9 @@ * * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED]) * Copyright (c) 2004-2006 Macq Electronique SA. + * + * This driver is now only used on ColdFire processors. Remove conditional + * Powerpc code. */ This comment makes sense for a changelog, but IMO it makes no sense at all to add it to the file. Cheers, FJP -- 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: [PATCH] [NET]: Remove PowerPC code from fec.c
On Friday 25 January 2008, Jochen Friedrich wrote: Jochen Friedrich wrote: +++ b/drivers/net/fec.c @@ -23,6 +23,9 @@ * * Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED]) * Copyright (c) 2004-2006 Macq Electronique SA. + * + * This driver is now only used on ColdFire processors. Remove conditional + * Powerpc code. */ This comment makes sense for a changelog, but IMO it makes no sense at all to add it to the file. I just added it to clarify this code is now only used on m68knommu (Coldfire). The comments on top are mailny about MPC860T CPUs (PowerPC), however the driver is no longer used for these CPUs. Maybe the wording should be changed to: This driver is now only used on ColdFire (m68knommu) processors. Conditional PowerPC code has been removed. Yes, that certainly makes more sense, although IMHO the second sentence is still somewhat redundant. (My problem was mainly with the second sentence. I should have made that more clear, sorry.) -- 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: [PATCH 1/2] dm-band: The I/O bandwidth controller: Source code patch
Hi, I'm not qualified to comment on the code, but here are some suggestions on config option and comments. Cheers, FJP Ryo Tsuruta wrote: > +config DM_BAND > + tristate "I/O band width control " s/band width/bandwidth/ (it seems to be used correctly elsewhere, but you may want to double-check) > + depends on BLK_DEV_DM > + ---help--- > + Any processes or cgroups can use the same storage > + with its band-width fairly shared. s/band-width/bandwidth/ The help should probably be a bit more verbose as this does not tell anybody much who has not already read the documentation. Maybe something like: This device-mapper target allows to define how the available bandwith of a storage device should be shared between processes or cgroups. Information on how to use dm-band is available in: Documentation/device-mapper/band.txt > + * The following functiotons determine when and which BIOs should ^^^ > + * be submitted to control the I/O flow. > + * It is possible to add a new I/O scheduling policy with it. > + * > + * g_can_submit : To determine whether a given group has a right to s/a right/the right/ > + * submit BIOs. > + * The larger return value the higher priority to submit. > + * Zero means it has no right. "The larger the return value, the higher the priority [...]" > + * g_prepare_bio : Called right before submitting each BIO. > + * g_restart_bios : Called when there exist some BIOs blocked but none of > them > + * can't be submitted now. s/when there exist some BIOs blocked/if some BIOs exist that are blocked/ ? "none of them can't" : the double negative looks incorrect (and should be avoided anyway) > + * This method have to do something to restart to submit BIOs. s/have/has/ "has to do something" : that's rather vague... -- 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: [PATCH 1/2] dm-band: The I/O bandwidth controller: Source code patch
Hi, I'm not qualified to comment on the code, but here are some suggestions on config option and comments. Cheers, FJP Ryo Tsuruta wrote: +config DM_BAND + tristate I/O band width control s/band width/bandwidth/ (it seems to be used correctly elsewhere, but you may want to double-check) + depends on BLK_DEV_DM + ---help--- + Any processes or cgroups can use the same storage + with its band-width fairly shared. s/band-width/bandwidth/ The help should probably be a bit more verbose as this does not tell anybody much who has not already read the documentation. Maybe something like: snip This device-mapper target allows to define how the available bandwith of a storage device should be shared between processes or cgroups. Information on how to use dm-band is available in: Documentation/device-mapper/band.txt /snip + * The following functiotons determine when and which BIOs should ^^^ + * be submitted to control the I/O flow. + * It is possible to add a new I/O scheduling policy with it. + * Method description + * g_can_submit : To determine whether a given group has a right to s/a right/the right/ + * submit BIOs. + * The larger return value the higher priority to submit. + * Zero means it has no right. The larger the return value, the higher the priority [...] + * g_prepare_bio : Called right before submitting each BIO. + * g_restart_bios : Called when there exist some BIOs blocked but none of them + * can't be submitted now. s/when there exist some BIOs blocked/if some BIOs exist that are blocked/ ? none of them can't : the double negative looks incorrect (and should be avoided anyway) + * This method have to do something to restart to submit BIOs. s/have/has/ has to do something : that's rather vague... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: reference count leak in PPPoE
Andi Kleen wrote: > My workstation running 2.6.24-rc8 just hung during shutdown with an > endless (or rather I didn't wait more than a few minutes) loop of > > unregister_netdev: waiting for ppp-device to become free. Usage count = 1 Same as http://lkml.org/lkml/2008/1/20/27? See also follow-up to that. Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: reference count leak in PPPoE
Andi Kleen wrote: My workstation running 2.6.24-rc8 just hung during shutdown with an endless (or rather I didn't wait more than a few minutes) loop of unregister_netdev: waiting for ppp-device to become free. Usage count = 1 Same as http://lkml.org/lkml/2008/1/20/27? See also follow-up to that. Cheers, FJP -- 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: pnpacpi : exceeded the max number of IO resources
Dave Young wrote: > I noticed the port number changed to 40 in 2.6.24-rc8, but it's not > enough for me still. Same here, though the extreme noise has gone. >From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-( Cheers, FJP -- 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: pnpacpi : exceeded the max number of IO resources
Dave Young wrote: I noticed the port number changed to 40 in 2.6.24-rc8, but it's not enough for me still. Same here, though the extreme noise has gone. From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-( Cheers, FJP -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Thursday 17 January 2008, David Miller wrote: > From: "Brandeburg, Jesse" <[EMAIL PROTECTED]> > > > We spent Wednesday trying to reproduce (without the patch) these issues > > without much luck, and have applied the patch cleanly and will continue > > testing it. Given the simplicity of the changes, and the community > > testing, I'll give my ack and we will continue testing. > > You need a slow CPU, and you need to make sure you do actually > trigger the TX limiting code there. Hmmm. Is a dual core Pentium D 3.20GHz considered slow these days? -- 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: [PATCH 00/10] x86: Reduce memory and intra-node effects with large count NR_CPUs V3
[EMAIL PROTECTED] wrote: >8472457 Total 30486950 +259% 30342823 +258% Hmmm. The table for previous versions looked a lot more impressive. now:8472457 Total+22014493 +259% +21870366 +258% V2 :7172678 Total+23314404 +325% -147590 -2% (recalculated for comparison) Did something go wrong with the "after" data? -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Wednesday 16 January 2008, David Miller wrote: > Ok, here is the patch I'll propose to fix this. The goal is to make > it as simple as possible without regressing the thing we were trying > to fix. Looks good to me. Tested with -rc8. Cheers, FJP -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Wednesday 16 January 2008, David Miller wrote: Ok, here is the patch I'll propose to fix this. The goal is to make it as simple as possible without regressing the thing we were trying to fix. Looks good to me. Tested with -rc8. Cheers, FJP -- 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: [PATCH 00/10] x86: Reduce memory and intra-node effects with large count NR_CPUs V3
[EMAIL PROTECTED] wrote: 8472457 Total 30486950 +259% 30342823 +258% Hmmm. The table for previous versions looked a lot more impressive. now:8472457 Total+22014493 +259% +21870366 +258% V2 :7172678 Total+23314404 +325% -147590 -2% (recalculated for comparison) Did something go wrong with the after data? -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Tuesday 15 January 2008, David Miller wrote: > From: Frans Pop <[EMAIL PROTECTED]> > > kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang > > Does this make the problem go away? Yes, it very much looks like that solves it. I ran with the patch for 6 hours or so without any errors. I then switched back to an unpatched kernel and they reappeared immediately. > (Note this isn't the final correct patch we should apply. There > is no reason why this revert back to the older ->poll() logic > here should have any effect on the TX hang triggering...) s/no reason/no obvious reason/ ? ;-) Cheers, FJP -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
On Tuesday 15 January 2008, David Miller wrote: From: Frans Pop [EMAIL PROTECTED] kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Does this make the problem go away? Yes, it very much looks like that solves it. I ran with the patch for 6 hours or so without any errors. I then switched back to an unpatched kernel and they reappeared immediately. (Note this isn't the final correct patch we should apply. There is no reason why this revert back to the older -poll() logic here should have any effect on the TX hang triggering...) s/no reason/no obvious reason/ ? ;-) Cheers, FJP -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
Wow. That's fast! :-) On Tuesday 15 January 2008, David Miller wrote: > From: Frans Pop <[EMAIL PROTECTED]> > > > kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang > > Does this make the problem go away? I'm compiling a kernel with the patch now. Will let you know the result. May take a while as I don't know how to trigger the bug, so I'll just have to let it run for some time. -- 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/
[REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
After compiling v2.6.24-rc7-163-g1a1b285 (x86_64) yesterday I suddenly see this error repeatedly: kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang kernel: Tx Queue <0> kernel: TDH kernel: TDT kernel: next_to_use kernel: next_to_clean kernel: buffer_info[next_to_clean] kernel: time_stamp <10002738a> kernel: next_to_watch kernel: jiffies <1000275b4> kernel: next_to_watch.status <1> My previous kernel was v2.6.24-rc7 and with that this error did not occur. I have also never seen it with earlier kernels. The values for "TX Queue" and "next_to_watch.status" are constant, the others vary. My NIC is: 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 01:00.0 0200: 8086:108c (rev 03) Subsystem: 8086:3096 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
After compiling v2.6.24-rc7-163-g1a1b285 (x86_64) yesterday I suddenly see this error repeatedly: kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang kernel: Tx Queue 0 kernel: TDH a kernel: TDT a kernel: next_to_use a kernel: next_to_cleanff kernel: buffer_info[next_to_clean] kernel: time_stamp 10002738a kernel: next_to_watchff kernel: jiffies 1000275b4 kernel: next_to_watch.status 1 My previous kernel was v2.6.24-rc7 and with that this error did not occur. I have also never seen it with earlier kernels. The values for TX Queue and next_to_watch.status are constant, the others vary. My NIC is: 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 01:00.0 0200: 8086:108c (rev 03) Subsystem: 8086:3096 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 1273 Region 0: Memory at 9020 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at 9010 (32-bit, non-prefetchable) [size=1M] Region 2: I/O ports at 1000 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Address: fee0300c Data: 41a9 Capabilities: [e0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s 512ns, L1 64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0 Link: Latency L0s 128ns, L1 64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 The system is an Intel D945GCZ main board with Intel(R) Pentium(R) D CPU 3.20GHz (dual core) processor. Cheers, FJP -- 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: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
Wow. That's fast! :-) On Tuesday 15 January 2008, David Miller wrote: From: Frans Pop [EMAIL PROTECTED] kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Does this make the problem go away? I'm compiling a kernel with the patch now. Will let you know the result. May take a while as I don't know how to trigger the bug, so I'll just have to let it run for some time. -- 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: > 100% CPU usage
James Kosin wrote: > Anyone remember the patch / patches done for the 2.6 series that related > to top reporting > 100% CPU usage? Do you mean these perhaps? - 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee - 9301899be75b464ef097f0b5af7af6d9bd8f68a7 Cheers, FJP -- 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: 100% CPU usage
James Kosin wrote: Anyone remember the patch / patches done for the 2.6 series that related to top reporting 100% CPU usage? Do you mean these perhaps? - 73a2bcb0edb9ffb0b007b3546b430e2c6e415eee - 9301899be75b464ef097f0b5af7af6d9bd8f68a7 Cheers, FJP -- 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: pnpacpi : exceeded the max number of IO resources
Len Brown wrote: >> > Well, yes, the warning is actually new as well. Previously your kernel >> > just silently ignored 8 more mem resources than it does now it seems. >> > >> > Given that people are hitting these limits, it might make sense to just >> > do away with the warning for 2.6.24 again while waiting for the dynamic >> > code? >> >> Ping. Should these warnings be reverted for 2.6.24? > > No. I don't think hiding this issue again is a good idea. > I'd rather live with people complaining about an addition dmesg line. We're not talking about "a" additional line. In my case [1] we're talking about 22 (!) additional identical lines. Not fixing this before 2.6.24 seems completely inconsistent: - either this is a real bug and the ERR level message is correct, in which case the limits should be increased; - or hitting the limits is harmless and the message should be changed to DEBUG level. It is great to hear that the memory allocation will become dynamic in the future and maybe that could just justify your standpoint, but having the messages is damn ugly and alarming from a user point of view. Please keep in mind that depending on distro release schedules, 2.6.24 could live for quite a bit longer than just the period needed to release 2.6.25 (if that is when the dynamic allocation will be implemented). Cheers, FJP [1] http://lkml.org/lkml/2008/1/6/279 -- 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: pnpacpi : exceeded the max number of IO resources
Len Brown wrote: Well, yes, the warning is actually new as well. Previously your kernel just silently ignored 8 more mem resources than it does now it seems. Given that people are hitting these limits, it might make sense to just do away with the warning for 2.6.24 again while waiting for the dynamic code? Ping. Should these warnings be reverted for 2.6.24? No. I don't think hiding this issue again is a good idea. I'd rather live with people complaining about an addition dmesg line. We're not talking about a additional line. In my case [1] we're talking about 22 (!) additional identical lines. Not fixing this before 2.6.24 seems completely inconsistent: - either this is a real bug and the ERR level message is correct, in which case the limits should be increased; - or hitting the limits is harmless and the message should be changed to DEBUG level. It is great to hear that the memory allocation will become dynamic in the future and maybe that could just justify your standpoint, but having the messages is damn ugly and alarming from a user point of view. Please keep in mind that depending on distro release schedules, 2.6.24 could live for quite a bit longer than just the period needed to release 2.6.25 (if that is when the dynamic allocation will be implemented). Cheers, FJP [1] http://lkml.org/lkml/2008/1/6/279 -- 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: pnpacpi: exceeded the max number of IO resources: 24
(Mail below was sent to me privately, forwarding to the lists.) On Mon, 2008-01-07 at 00:48 +0100, Frans Pop wrote: > (Adding the kernel list back. Any reason you did not send the reply > there?) > > Sorry for the late reply: Christmas, New Year, the flue, etc. > Thank you for caring this problem. > On Friday 28 December 2007, Zhao Yakui wrote: > > On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: > > > During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite > > > A40 laptop, I suddenly get the following message (repeated 22 > > > times!): pnpacpi: exceeded the max number of IO resources: 24 > > > > > > Last time I tested 2.6.24 on that box was after the initial merge, > > > but before -rc1. Then those lines were not present. > > > > > > Looks like the messages originate from a7839e96 by Zhao Yakui and > > > that patch just adds the kernel messages so it was probably a > > > hidden issue before, but I cannot determine if I should be worried > > > or not. > > > > Thanks for caring this problem. > > And thank you for the reply, although I must admit that I'm still > confused. > > > In the patch of a7839e96 the predefined PNP constant is changed. For > > example: IO is changed from 8 to 24, Mem is changed from 4 to 12. > > That means that more resources will be obtained from the PNP device > > defined in ACPI table. So the system will print more message. > > OK. The change for Mem from 4 to 12 could explain the extra "iomem > range" messages (although I don't quite understand why resources that > "could not be reserved" still use a slot). The resources of PNP device are obtained by calling the _CRS method. Maybe some resources has been reserved. For example: Some system will reserve the following resources. BIOS-e820: fec0 - fed4 (reserved) BIOS-e820: fed45000 - 0001 (reserved) So the system will report that some resources can't be reserved. > I do not yet see how the "ioport range" messages increased from 0 to 16 > is explained, but I'm not too worried about that. > > > At the same time another problem maybe happens. If the number of > > resources defined in BIOS still exceeds the predefined PNP constant, > > it will report that pnpacpi: exceeded the max number of IO resources: > > 24. Although it can be fixed by changed the pnp constant bigger, it > > is inappropriate because it will waste a lot of memory in most cases. > > > > Of course the above error message is harmless. > > Are the _errors_ really harmless? The error message is harmless. It only tells us that the resource definition of PNP device exceeds the predefined PNP constant and maybe there will be potential problem if some important resources can't be reserved. For example about 90 IOPORT resources are defined in some PNP device. So it will print the message. Of course it is more appropriate to change the message level from ERR to DEBUG. > Your commit message was: > "It brings that some resources can't be reserved and resource > confilicts. This will cause PCI resources are assigned wrongly in some > systems, and cause hang. This is a regression since we deleted ACPI > motherboard driver and use PNP system driver." > > That text seems to indicate that not reserving the remaining resources > _can_ cause real problems. Do we know what PCI resources are now not > being correctly reserved on my laptop (and other machines)? The fact > that the message is repeated 22 times seems to indicate that in my case > quite a lot of resources are being ignored. > > Should the memory allocation maybe be made dynamic instead of static if > the memory waste is really such a problem? Apparently the number of PCI > resources can vary wildly from one machine to another. It is more appropriate to use dynamic memory allocation for Pnp device than to increase the PNP constant bigger. Now Thomas is working on it. Maybe he will submit the patch very soon. > If the error messages really are harmless, shouldn't they be changed > from ERR to DEBUG? As it is, the messages are extremely ugly and will > probably cause a lot of people to file bug reports as it _looks_ like > there is an error. -- 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: pnpacpi: exceeded the max number of IO resources: 24
(Mail below was sent to me privately, forwarding to the lists.) On Mon, 2008-01-07 at 00:48 +0100, Frans Pop wrote: (Adding the kernel list back. Any reason you did not send the reply there?) Sorry for the late reply: Christmas, New Year, the flue, etc. Thank you for caring this problem. On Friday 28 December 2007, Zhao Yakui wrote: On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite A40 laptop, I suddenly get the following message (repeated 22 times!): pnpacpi: exceeded the max number of IO resources: 24 Last time I tested 2.6.24 on that box was after the initial merge, but before -rc1. Then those lines were not present. Looks like the messages originate from a7839e96 by Zhao Yakui and that patch just adds the kernel messages so it was probably a hidden issue before, but I cannot determine if I should be worried or not. Thanks for caring this problem. And thank you for the reply, although I must admit that I'm still confused. In the patch of a7839e96 the predefined PNP constant is changed. For example: IO is changed from 8 to 24, Mem is changed from 4 to 12. That means that more resources will be obtained from the PNP device defined in ACPI table. So the system will print more message. OK. The change for Mem from 4 to 12 could explain the extra iomem range messages (although I don't quite understand why resources that could not be reserved still use a slot). The resources of PNP device are obtained by calling the _CRS method. Maybe some resources has been reserved. For example: Some system will reserve the following resources. BIOS-e820: fec0 - fed4 (reserved) BIOS-e820: fed45000 - 0001 (reserved) So the system will report that some resources can't be reserved. I do not yet see how the ioport range messages increased from 0 to 16 is explained, but I'm not too worried about that. At the same time another problem maybe happens. If the number of resources defined in BIOS still exceeds the predefined PNP constant, it will report that pnpacpi: exceeded the max number of IO resources: 24. Although it can be fixed by changed the pnp constant bigger, it is inappropriate because it will waste a lot of memory in most cases. Of course the above error message is harmless. Are the _errors_ really harmless? The error message is harmless. It only tells us that the resource definition of PNP device exceeds the predefined PNP constant and maybe there will be potential problem if some important resources can't be reserved. For example about 90 IOPORT resources are defined in some PNP device. So it will print the message. Of course it is more appropriate to change the message level from ERR to DEBUG. Your commit message was: It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver. That text seems to indicate that not reserving the remaining resources _can_ cause real problems. Do we know what PCI resources are now not being correctly reserved on my laptop (and other machines)? The fact that the message is repeated 22 times seems to indicate that in my case quite a lot of resources are being ignored. Should the memory allocation maybe be made dynamic instead of static if the memory waste is really such a problem? Apparently the number of PCI resources can vary wildly from one machine to another. It is more appropriate to use dynamic memory allocation for Pnp device than to increase the PNP constant bigger. Now Thomas is working on it. Maybe he will submit the patch very soon. If the error messages really are harmless, shouldn't they be changed from ERR to DEBUG? As it is, the messages are extremely ugly and will probably cause a lot of people to file bug reports as it _looks_ like there is an error. -- 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: pnpacpi: exceeded the max number of IO resources: 24
(Adding the kernel list back. Any reason you did not send the reply there?) Sorry for the late reply: Christmas, New Year, the flue, etc. On Friday 28 December 2007, Zhao Yakui wrote: > On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: > > During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite A40 > > laptop, I suddenly get the following message (repeated 22 times!): > >pnpacpi: exceeded the max number of IO resources: 24 > > > > Last time I tested 2.6.24 on that box was after the initial merge, but > > before -rc1. Then those lines were not present. > > > > Looks like the messages originate from a7839e96 by Zhao Yakui and that > > patch just adds the kernel messages so it was probably a hidden issue > > before, but I cannot determine if I should be worried or not. > > Thanks for caring this problem. And thank you for the reply, although I must admit that I'm still confused. > In the patch of a7839e96 the predefined PNP constant is changed. For > example: IO is changed from 8 to 24, Mem is changed from 4 to 12. > That means that more resources will be obtained from the PNP device > defined in ACPI table. So the system will print more message. OK. The change for Mem from 4 to 12 could explain the extra "iomem range" messages (although I don't quite understand why resources that "could not be reserved" still use a slot). I do not yet see how the "ioport range" messages increased from 0 to 16 is explained, but I'm not too worried about that. > At the same time another problem maybe happens. If the number of > resources defined in BIOS still exceeds the predefined PNP constant, it > will report that pnpacpi: exceeded the max number of IO resources: 24. > Although it can be fixed by changed the pnp constant bigger, it is > inappropriate because it will waste a lot of memory in most cases. > > Of course the above error message is harmless. Are the _errors_ really harmless? Your commit message was: "It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver." That text seems to indicate that not reserving the remaining resources _can_ cause real problems. Do we know what PCI resources are now not being correctly reserved on my laptop (and other machines)? The fact that the message is repeated 22 times seems to indicate that in my case quite a lot of resources are being ignored. Should the memory allocation maybe be made dynamic instead of static if the memory waste is really such a problem? Apparently the number of PCI resources can vary wildly from one machine to another. If the error messages really are harmless, shouldn't they be changed from ERR to DEBUG? As it is, the messages are extremely ugly and will probably cause a lot of people to file bug reports as it _looks_ like there is an error. Cheers, Frans Pop -- 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: [BUG] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
On Sunday 06 January 2008, Eric W. Biederman wrote: > Short of two programs coming in and simultaneously trying to claim > the parallel port and there being not exclusion in ppdev.c I don't > have a clue what could cause the reported error. That could well be the root cause as the full log shows: Jan 6 01:21:02 faramir kernel: ppdev0: registered pardevice Jan 6 01:21:03 faramir kernel: sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Jan 6 01:21:03 faramir kernel: Pid: 11078, comm: hpijs Not tainted 2.6.24-rc6 #1 Jan 6 01:21:03 faramir kernel: Jan 6 01:21:03 faramir kernel: Call Trace: Jan 6 01:21:03 faramir kernel: [] set_fail+0x3f/0x47 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4ae/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [] register_sysctl_table+0x52/0x9d Jan 6 01:21:03 faramir kernel: [] :parport:parport_device_proc_register+0xc3/0xe3 Jan 6 01:21:03 faramir kernel: [] :parport:parport_register_device+0x206/0x267 Jan 6 01:21:03 faramir kernel: [] :ppdev:pp_irq+0x0/0x40 Jan 6 01:21:03 faramir kernel: [] :ppdev:pp_ioctl+0x13f/0x77c Jan 6 01:21:03 faramir kernel: [] do_ioctl+0x55/0x6b Jan 6 01:21:03 faramir kernel: [] vfs_ioctl+0x243/0x25c Jan 6 01:21:03 faramir kernel: [] sys_ioctl+0x51/0x71 Jan 6 01:21:03 faramir kernel: [] system_call+0x7e/0x83 Jan 6 01:21:03 faramir kernel: Jan 6 01:21:03 faramir kernel: ppdev0: registered pardevice Jan 6 01:22:10 faramir kernel: ppdev0: released pardevice because user-space forgot Jan 6 01:22:10 faramir kernel: ppdev0: unregistered pardevice Jan 6 01:22:11 faramir kernel: ppdev0: unregistered pardevice Jan 6 03:24:57 faramir kernel: fuse exit Sorry for not providing that info earlier, but the first time I had this issue I had two print jobs after eachother and because of that I overlooked the double registering. I am printing through CUPS on a fairly standard Debian unstable system running the KDE desktop. -- 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: pnpacpi: exceeded the max number of IO resources: 24
(Adding the kernel list back. Any reason you did not send the reply there?) Sorry for the late reply: Christmas, New Year, the flue, etc. On Friday 28 December 2007, Zhao Yakui wrote: On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote: During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite A40 laptop, I suddenly get the following message (repeated 22 times!): pnpacpi: exceeded the max number of IO resources: 24 Last time I tested 2.6.24 on that box was after the initial merge, but before -rc1. Then those lines were not present. Looks like the messages originate from a7839e96 by Zhao Yakui and that patch just adds the kernel messages so it was probably a hidden issue before, but I cannot determine if I should be worried or not. Thanks for caring this problem. And thank you for the reply, although I must admit that I'm still confused. In the patch of a7839e96 the predefined PNP constant is changed. For example: IO is changed from 8 to 24, Mem is changed from 4 to 12. That means that more resources will be obtained from the PNP device defined in ACPI table. So the system will print more message. OK. The change for Mem from 4 to 12 could explain the extra iomem range messages (although I don't quite understand why resources that could not be reserved still use a slot). I do not yet see how the ioport range messages increased from 0 to 16 is explained, but I'm not too worried about that. At the same time another problem maybe happens. If the number of resources defined in BIOS still exceeds the predefined PNP constant, it will report that pnpacpi: exceeded the max number of IO resources: 24. Although it can be fixed by changed the pnp constant bigger, it is inappropriate because it will waste a lot of memory in most cases. Of course the above error message is harmless. Are the _errors_ really harmless? Your commit message was: It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver. That text seems to indicate that not reserving the remaining resources _can_ cause real problems. Do we know what PCI resources are now not being correctly reserved on my laptop (and other machines)? The fact that the message is repeated 22 times seems to indicate that in my case quite a lot of resources are being ignored. Should the memory allocation maybe be made dynamic instead of static if the memory waste is really such a problem? Apparently the number of PCI resources can vary wildly from one machine to another. If the error messages really are harmless, shouldn't they be changed from ERR to DEBUG? As it is, the messages are extremely ugly and will probably cause a lot of people to file bug reports as it _looks_ like there is an error. Cheers, Frans Pop -- 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: [BUG] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
On Sunday 06 January 2008, Eric W. Biederman wrote: Short of two programs coming in and simultaneously trying to claim the parallel port and there being not exclusion in ppdev.c I don't have a clue what could cause the reported error. That could well be the root cause as the full log shows: Jan 6 01:21:02 faramir kernel: ppdev0: registered pardevice Jan 6 01:21:03 faramir kernel: sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Jan 6 01:21:03 faramir kernel: Pid: 11078, comm: hpijs Not tainted 2.6.24-rc6 #1 Jan 6 01:21:03 faramir kernel: Jan 6 01:21:03 faramir kernel: Call Trace: Jan 6 01:21:03 faramir kernel: [8024c104] set_fail+0x3f/0x47 Jan 6 01:21:03 faramir kernel: [8024c5ba] sysctl_check_table+0x4ae/0x4fb Jan 6 01:21:03 faramir kernel: [8024c0b6] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [8024c5d0] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [8024c0b6] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [8024c5d0] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [8024c0b6] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [8024c5d0] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [8024c0b6] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [8024c5d0] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [8024c0b6] sysctl_check_lookup+0xc1/0xd0 Jan 6 01:21:03 faramir kernel: [8024c5d0] sysctl_check_table+0x4c4/0x4fb Jan 6 01:21:03 faramir kernel: [8023ca8d] register_sysctl_table+0x52/0x9d Jan 6 01:21:03 faramir kernel: [881ea7cb] :parport:parport_device_proc_register+0xc3/0xe3 Jan 6 01:21:03 faramir kernel: [881e8da7] :parport:parport_register_device+0x206/0x267 Jan 6 01:21:03 faramir kernel: [884151ae] :ppdev:pp_irq+0x0/0x40 Jan 6 01:21:03 faramir kernel: [8841574f] :ppdev:pp_ioctl+0x13f/0x77c Jan 6 01:21:03 faramir kernel: [80296a55] do_ioctl+0x55/0x6b Jan 6 01:21:03 faramir kernel: [80296cae] vfs_ioctl+0x243/0x25c Jan 6 01:21:03 faramir kernel: [80296d18] sys_ioctl+0x51/0x71 Jan 6 01:21:03 faramir kernel: [8020beee] system_call+0x7e/0x83 Jan 6 01:21:03 faramir kernel: Jan 6 01:21:03 faramir kernel: ppdev0: registered pardevice Jan 6 01:22:10 faramir kernel: ppdev0: released pardevice because user-space forgot Jan 6 01:22:10 faramir kernel: ppdev0: unregistered pardevice Jan 6 01:22:11 faramir kernel: ppdev0: unregistered pardevice Jan 6 03:24:57 faramir kernel: fuse exit Sorry for not providing that info earlier, but the first time I had this issue I had two print jobs after eachother and because of that I overlooked the double registering. I am printing through CUPS on a fairly standard Debian unstable system running the KDE desktop. -- 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/
[BUG] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
(Resending as there were no replies on my first post mid December; issue is still there with -rc6.) This is the first time I've seen this error. Last time I used the printer was with 2.6.24-rc3 and that time this error did not occur. The error occurs when I start a print job, not when I turn the printer on. System is Pentium D x86_64 kernel running Debian unstable. Printer is a HP Photosmart P1100 connected via parallel port. Not sure who should be CCed on this. ppdev0: registered pardevice sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Pid: 14491, comm: hpijs Not tainted 2.6.24-rc5 #1 Call Trace: [] set_fail+0x3f/0x47 [] sysctl_check_table+0x4ae/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] sysctl_check_lookup+0xc1/0xd0 [] sysctl_check_table+0x4c4/0x4fb [] register_sysctl_table+0x52/0x9d [] :parport:parport_device_proc_register+0xc3/0xe3 [] :parport:parport_register_device+0x206/0x267 [] :ppdev:pp_irq+0x0/0x40 [] :ppdev:pp_ioctl+0x13f/0x77c [] do_ioctl+0x55/0x6b [] vfs_ioctl+0x243/0x25c [] sys_ioctl+0x51/0x71 [] system_call+0x7e/0x83 Cheers, FJP -- 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/
[BUG] 2.6.24-rc5: 'sysctl table check failed' when turning on printer
(Resending as there were no replies on my first post mid December; issue is still there with -rc6.) This is the first time I've seen this error. Last time I used the printer was with 2.6.24-rc3 and that time this error did not occur. The error occurs when I start a print job, not when I turn the printer on. System is Pentium D x86_64 kernel running Debian unstable. Printer is a HP Photosmart P1100 connected via parallel port. Not sure who should be CCed on this. ppdev0: registered pardevice sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Pid: 14491, comm: hpijs Not tainted 2.6.24-rc5 #1 Call Trace: [8024c0b0] set_fail+0x3f/0x47 [8024c566] sysctl_check_table+0x4ae/0x4fb [8024c062] sysctl_check_lookup+0xc1/0xd0 [8024c57c] sysctl_check_table+0x4c4/0x4fb [8024c062] sysctl_check_lookup+0xc1/0xd0 [8024c57c] sysctl_check_table+0x4c4/0x4fb [8024c062] sysctl_check_lookup+0xc1/0xd0 [8024c57c] sysctl_check_table+0x4c4/0x4fb [8024c062] sysctl_check_lookup+0xc1/0xd0 [8024c57c] sysctl_check_table+0x4c4/0x4fb [8024c062] sysctl_check_lookup+0xc1/0xd0 [8024c57c] sysctl_check_table+0x4c4/0x4fb [8023ca15] register_sysctl_table+0x52/0x9d [881d97cb] :parport:parport_device_proc_register+0xc3/0xe3 [881d7da7] :parport:parport_register_device+0x206/0x267 [884171ae] :ppdev:pp_irq+0x0/0x40 [8841774f] :ppdev:pp_ioctl+0x13f/0x77c [80296a11] do_ioctl+0x55/0x6b [80296c6a] vfs_ioctl+0x243/0x25c [80296cd4] sys_ioctl+0x51/0x71 [8020beee] system_call+0x7e/0x83 Cheers, FJP -- 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: Trailing periods in kernel messages
On Thursday 20 December 2007, Alan Cox wrote: > The kernel printk messages are sentences. I'm afraid that I completely and utterly disagree. Kernel messages are _not_ sentences. The vast majority is not well-formed and does not contain any of the elements that are required for a proper sentence. The most kernel messages can be compared to is a rather diverse and sloppy enumeration. And enumerations follow completely different rules than sentences. It can better be characterized as a "semi-random sequence of context-sensitive technical messages". IMHO the existing rule that "Kernel messages do not have to be terminated with a period." is completely justified, though it does need some minor clarification on the cases in which proper punctuation _should_ be followed. -- 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: Trailing periods in kernel messages
On Thursday 20 December 2007, Alan Cox wrote: The kernel printk messages are sentences. I'm afraid that I completely and utterly disagree. Kernel messages are _not_ sentences. The vast majority is not well-formed and does not contain any of the elements that are required for a proper sentence. The most kernel messages can be compared to is a rather diverse and sloppy enumeration. And enumerations follow completely different rules than sentences. It can better be characterized as a semi-random sequence of context-sensitive technical messages. IMHO the existing rule that Kernel messages do not have to be terminated with a period. is completely justified, though it does need some minor clarification on the cases in which proper punctuation _should_ be followed. -- 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: [PATCH] finish processor.h integration
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote: > On Dec 18, 2007 6:54 PM, Frans Pop <[EMAIL PROTECTED]> wrote: > > Glauber de Oliveira Costa wrote: > > > What's left in processor_32.h and processor_64.h cannot be cleanly > > > integrated. However, it's just a couple of definitions. They are > > > moved to processor.h around ifdefs, and the original files are > > > deleted. Note that there's much less headers included in the final > > > version. > > > > Either I must be missing something or this patch was corrupted somehow. > > neither. > Note the else in the middle. It's just a mistake in the comment. Wouldn't an explicit second #ifdef block be a lot clearer (and improve maintainability) in this case? An #else can easily be overlooked among other preprocessor commands or when #ifdefs get nested. -- 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: [PATCH] finish processor.h integration
Glauber de Oliveira Costa wrote: > What's left in processor_32.h and processor_64.h cannot be cleanly > integrated. However, it's just a couple of definitions. They are moved > to processor.h around ifdefs, and the original files are deleted. Note > that there's much less headers included in the final version. Either I must be missing something or this patch was corrupted somehow. I see: +#ifdef CONFIG_X86_32 [...] +#endif /* CONFIG_X86_64 */ While I'd have expected: +#ifdef CONFIG_X86_32 [...] +#endif /* CONFIG_X86_32 */ + +#ifdef CONFIG_X86_64 [...] +#endif /* CONFIG_X86_64 */ Cheers, FJP -- 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: [PATCH] finish processor.h integration
Glauber de Oliveira Costa wrote: What's left in processor_32.h and processor_64.h cannot be cleanly integrated. However, it's just a couple of definitions. They are moved to processor.h around ifdefs, and the original files are deleted. Note that there's much less headers included in the final version. Either I must be missing something or this patch was corrupted somehow. I see: +#ifdef CONFIG_X86_32 [...] +#endif /* CONFIG_X86_64 */ While I'd have expected: +#ifdef CONFIG_X86_32 [...] +#endif /* CONFIG_X86_32 */ + +#ifdef CONFIG_X86_64 [...] +#endif /* CONFIG_X86_64 */ Cheers, FJP -- 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: [PATCH] finish processor.h integration
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote: On Dec 18, 2007 6:54 PM, Frans Pop [EMAIL PROTECTED] wrote: Glauber de Oliveira Costa wrote: What's left in processor_32.h and processor_64.h cannot be cleanly integrated. However, it's just a couple of definitions. They are moved to processor.h around ifdefs, and the original files are deleted. Note that there's much less headers included in the final version. Either I must be missing something or this patch was corrupted somehow. neither. Note the else in the middle. It's just a mistake in the comment. Wouldn't an explicit second #ifdef block be a lot clearer (and improve maintainability) in this case? An #else can easily be overlooked among other preprocessor commands or when #ifdefs get nested. -- 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/
