Subject : Re: Linux 2.6.26-rc5 Submitter : "Lior Dotan" <liodot@gmail.com> Date : 2008-06-05 15:04 References : http://marc.info/?l=linux-kernel&m=121267834521432&w=4 This entry is being used for tracking a regression from 2.6.25. Please don't close it until the problem is fixed in the mainline.
This seems clearly to have been caused by an invalid-but-semi-functional configuration. The two valid config options are (a) using the legacy RTC code, or (b) using the new RTC framework and rtc-cmos. The invalid one was trying to use both. We made the invalid configuration impossible, to prevent other bugs. Since the previous configuration was invalid, I'm not sure it's quite fair to call this a regression.
On Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.25. Please verify if it still should be listed. > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866 > Subject : /dev/rtc was missing until I disabled > CONFIG_RTC_CLASS > Submitter : Lior Dotan <liodot@gmail.com> > Date : 2008-06-05 15:04 (3 days old) > References : > http://marc.info/?l=linux-kernel&m=121267834521432&w=4 Where are we regarding this entry in the 2.6.26-rc regression list? I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix and not a 2.6.26-rc regression. Does anyone disagree with this? I'm not sure whether this was Lior's problem or another issue I'm seeing on my computer (static /dev, no udev): /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this a functional regression of the new drivers. Could this be fixed? cu Adrian
Reply-To: liodot@gmail.com On Fri, Jun 13, 2008 at 10:33 PM, Adrian Bunk <bunk@kernel.org> wrote: > On Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote: >> This message has been generated automatically as a part of a report >> of recent regressions. >> >> The following bug entry is on the current list of known regressions >> from 2.6.25. Please verify if it still should be listed. >> >> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866 >> Subject : /dev/rtc was missing until I disabled >> CONFIG_RTC_CLASS >> Submitter : Lior Dotan <liodot@gmail.com> >> Date : 2008-06-05 15:04 (3 days old) >> References : >> http://marc.info/?l=linux-kernel&m=121267834521432&w=4 > > Where are we regarding this entry in the 2.6.26-rc regression list? > > I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix > and not a 2.6.26-rc regression. > > Does anyone disagree with this? > > > I'm not sure whether this was Lior's problem or another issue I'm seeing > on my computer (static /dev, no udev): > > /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this > a functional regression of the new drivers. > > Could this be fixed? > > > cu > Adrian > > -- I don't know if it helps you to decide but the way I got to this configuration is by copying my working 2.6.25 .config file and running make oldconfig. I think this scenario is common when upgrading to a newer version so you should make sure it doesn't generate an invalid configuration. Lior.
Reply-To: david-b@pacbell.net On Friday 13 June 2008, Lior Dotan wrote: > I don't know if it helps you to decide but the way I got to this > configuration is by copying my working 2.6.25 .config file and running > make oldconfig. I think this scenario is common when upgrading to a > newer version so you should make sure it doesn't generate an invalid > configuration. It doesn't! "No /dev/rtc" is a perfectly valid config. And it's not uncommon that new kernels require config tweaks. To repeat what's in the bug database: your old config didn't use one of the valid RTC configs: legacy *OR* new style (else neither). Mixing the two was never supported ... it caused various bugs, and much confusion. You might not have observed with your old .config on your hardware (or might have ignored it), but other folk did. I'm not sure anyone would have wanted to merge any patches that would have let the two frameworks coexist/overlap, but that's a moot point since nobody (including you) submitted such patches. What was submitted was a patch that rejected an invalid config. - Dave
* David Brownell <david-b@pacbell.net> wrote: > On Friday 13 June 2008, Lior Dotan wrote: > > I don't know if it helps you to decide but the way I got to this > > configuration is by copying my working 2.6.25 .config file and running > > make oldconfig. I think this scenario is common when upgrading to a > > newer version so you should make sure it doesn't generate an invalid > > configuration. > > It doesn't! "No /dev/rtc" is a perfectly valid config. [...] The bug scenario is rather simple: /dev/rtc existed with that config in prior kernels and now, after "make oldconfig" it does not exist, it's a plain regression and must be fixed. > And it's not uncommon that new kernels require config tweaks. that's wrong - 'make oldconfig' must work smoothly and in an expected way. If you argue that the new kernel should come up with a non-existent /dev/rtc, then you are wrong and you go against established regression handling policies of the kernel. Smooth migration via "make oldconfig" is a must, otherwise we'd lose testers and users. The old /dev/rtc might indeed have been unbelievably "bad" in various ways and you dont even want to think about that code now, but it's your code now that is used so you might as well think about the other 98% of users who used the old /dev/rtc with old kernels. (not because they wanted to use bad code, but because simply that was the default) Ingo
On Fri, Jun 13, 2008 at 10:55:38PM +0300, Lior Dotan wrote: > On Fri, Jun 13, 2008 at 10:33 PM, Adrian Bunk <bunk@kernel.org> wrote: > > On Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote: > >> This message has been generated automatically as a part of a report > >> of recent regressions. > >> > >> The following bug entry is on the current list of known regressions > >> from 2.6.25. Please verify if it still should be listed. > >> > >> > >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866 > >> Subject : /dev/rtc was missing until I disabled > CONFIG_RTC_CLASS > >> Submitter : Lior Dotan <liodot@gmail.com> > >> Date : 2008-06-05 15:04 (3 days old) > >> References : > http://marc.info/?l=linux-kernel&m=121267834521432&w=4 > > > > Where are we regarding this entry in the 2.6.26-rc regression list? > > > > I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix > > and not a 2.6.26-rc regression. > > > > Does anyone disagree with this? > > > > > > I'm not sure whether this was Lior's problem or another issue I'm seeing > > on my computer (static /dev, no udev): > > > > /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this > > a functional regression of the new drivers. > > > > Could this be fixed? > > I don't know if it helps you to decide but the way I got to this > configuration is by copying my working 2.6.25 .config file and running > make oldconfig. I think this scenario is common when upgrading to a > newer version so you should make sure it doesn't generate an invalid > configuration. What is the output of "grep RTC_ .config" on your old .config? > Lior. cu Adrian
Reply-To: david-b@pacbell.net On Friday 13 June 2008, Ingo Molnar wrote: > > Smooth migration via "make oldconfig" > is a must, otherwise we'd lose testers and users. Yes, but "smooth" doesn't mean there's never a need to cope with kernel updates by running "xconfig" (or whatever). In my own experience, several times a year I need to go back and patch up a mess that "oldconfig" made. Things drop out, things get added ... it's the things that get *added* without even a by-your-leave which often seem hardest to fix. > you might as well think about the other 98% of > users who used the old /dev/rtc with old kernels. (not because they > wanted to use bad code, but because simply that was the default) They can continue working just fine with *only* the legacy RTC. If they stuck with defaults, no problems appear. (Modulo the fact that bitrot is setting in.) The only thing that causes the least hiccup is someone who was for a while using a bogus (and non-default) configuration. Given a bogus configuration, how should it be fixed? There can be several solutions, and the right answer for one system will always be the right one for another. So any approach that doesn't expect a human to select options sometimes will be inherently wrong in various cases. - Dave
Reply-To: alessandro.zummo@towertech.it On Fri, 13 Jun 2008 15:38:54 -0700 David Brownell <david-b@pacbell.net> wrote: > > They can continue working just fine with *only* the legacy RTC. > If they stuck with defaults, no problems appear. (Modulo the > fact that bitrot is setting in.) > > The only thing that causes the least hiccup is someone who was > for a while using a bogus (and non-default) configuration. > > Given a bogus configuration, how should it be fixed? There > can be several solutions, and the right answer for one system > will always be the right one for another. So any approach > that doesn't expect a human to select options sometimes will > be inherently wrong in various cases. I agree with david. oldconfig cannot be made to fix every possible manual misconfiguration that has been introduced by the user, even those that, by chance, just worked. The actual Kconfig will handle pretty well the transition from a good config. where good is different from working-by-chance. There are far too many people that just keep pressing Y when a new kernel option appears without even considering what would happen or reading the help.
* David Brownell <david-b@pacbell.net> wrote: > On Friday 13 June 2008, Ingo Molnar wrote: > > > > Smooth migration via "make oldconfig" > > is a must, otherwise we'd lose testers and users. > > Yes, but "smooth" doesn't mean there's never a need to cope with > kernel updates by running "xconfig" (or whatever). you are arguing against the facts - just look at the report - /dev/rtc broke and that shouldnt have happened and should be fixed. No amount of talking you do here will produce a working config. > In my own experience, several times a year I need to go back and patch > up a mess that "oldconfig" made. Things drop out, things get added > ... it's the things that get *added* without even a by-your-leave > which often seem hardest to fix. i have hit 1400 kernel bugs in the past 6 months alone on my testsystems. That does not mean kernel bugs are the norm and it does not entitle me to ignore kernel bugs in the future? > The only thing that causes the least hiccup is someone who was for a > while using a bogus (and non-default) configuration. uhm, there's no such thing as a "bogus configuration". The Kconfig rules for RTC (authored by you too) allowed it. If it "makes no sense" it's because you coded it so - deal with it, it's not hard. But instead of solving it (it is trivial) you are trying to push the blame to the user - and that is rather lame to do. > Given a bogus configuration, how should it be fixed? [...] this is not rocket science. The solution is to turn on the fine RTC code, if the old config option is enabled too. I.e. be more careful about compatibility. It's still possible to solve this problem and allow the RTC code to be compiled out completely. and note that you are hurting users who tried out _your_ RTC code (which was default off in the past) previously. Yes, while experimenting with your code they might have created the "wrong" mix of config options but that's not a problem - this isnt some esoteric embedded platform where only real men are allowed to configure the kernel and who are left out in the cold if they mess up - this is Linux where we encourage (and beg) actual user to test our kernels. So please show some basic respect towards them and dont arbitrarily declare configs "broken" that were working in the past. Ingo
On Sat, Jun 14, 2008 at 11:35:35AM +0200, Alessandro Zummo wrote: > On Fri, 13 Jun 2008 15:38:54 -0700 > David Brownell <david-b@pacbell.net> wrote: > > > They can continue working just fine with *only* the legacy RTC. > > If they stuck with defaults, no problems appear. (Modulo the > > fact that bitrot is setting in.) > > > > The only thing that causes the least hiccup is someone who was > > for a while using a bogus (and non-default) configuration. > > > > Given a bogus configuration, how should it be fixed? There > > can be several solutions, and the right answer for one system > > will always be the right one for another. So any approach > > that doesn't expect a human to select options sometimes will > > be inherently wrong in various cases. > > I agree with david. oldconfig cannot be made to fix every possible > manual misconfiguration that has been introduced by the user, even > those that, by chance, just worked. > > The actual Kconfig will handle pretty well the transition from > a good config. where good is different from working-by-chance. > > There are far too many people that just keep pressing Y > when a new kernel option appears without even considering what would > happen or reading the help. If Lior's problem was due to something like CONFIG_RTC_CLASS=y, CONFIG_RTC_DRV_CMOS=n that's a kernel configuration that would anyway break when the old driver gets removed, and it just broke earlier. Everyone seems to focus on this kconfig related case, what about my point of no /dev/rtc with a static /dev ? When talking about existing setups and embedded systems that's a real issue for some systems. > Best regards, > > Alessandro Zummo, cu Adrian
Reply-To: alessandro.zummo@towertech.it On Sat, 14 Jun 2008 14:18:06 +0300 Adrian Bunk <bunk@kernel.org> wrote: > > If Lior's problem was due to something like CONFIG_RTC_CLASS=y, > CONFIG_RTC_DRV_CMOS=n that's a kernel configuration that would > anyway break when the old driver gets removed, and it just broke > earlier. I haven't seen the .config, but CONFIG_RTC_CLASS=y and CONFIG_RTC_DRV_CMOS=n is perfectly legal. It just don't have to be put in the default x86 config maybe, but it's legal.. > Everyone seems to focus on this kconfig related case, what about my > point of no /dev/rtc with a static /dev ? When talking about existing > setups and embedded systems that's a real issue for some systems. the device node creation is yet another option of the rtc class. it should be on by default in any defconfig, I'd guess. But then you'll get /dev/rtc0 without any specific device node. As I said in the past, I'd accept a patch to handle this special case of having /dev/rtc with a specific major and minor, but I'm against it. It would be better to upgrade your userspace when such big changes happens in the kernel. In fact, it the first time that the rtc has been touched in the last.. 10 year? I think it's not unreasonable to ask to upgrade userspace. wrto embedded systems, having worked with them for years, you are expected to check every detail of every new kernel you want to use before releasing it or, say, uploading it to your lander on the moon :)
Reply-To: liodot@gmail.com On Fri, Jun 13, 2008 at 11:20 PM, Adrian Bunk <bunk@kernel.org> wrote: > On Fri, Jun 13, 2008 at 10:55:38PM +0300, Lior Dotan wrote: >> On Fri, Jun 13, 2008 at 10:33 PM, Adrian Bunk <bunk@kernel.org> wrote: >> > On Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote: >> > >> > /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this >> > a functional regression of the new drivers. >> > >> > Could this be fixed? >> >> I don't know if it helps you to decide but the way I got to this >> configuration is by copying my working 2.6.25 .config file and running >> make oldconfig. I think this scenario is common when upgrading to a >> newer version so you should make sure it doesn't generate an invalid >> configuration. > > What is the output of "grep RTC_ .config" on your old .config? I don't have access to that machine right now so I'll post it tomorrow. > cu > Adrian > Cheers, Lior
Reply-To: liodot@gmail.com On Sat, Jun 14, 2008 at 12:20 AM, Adrian Bunk <bunk@kernel.org> wrote: > > What is the output of "grep RTC_ .config" on your old .config? Here it is: # CONFIG_HPET_RTC_IRQ is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # CONFIG_RTC_DRV_CMOS is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_V3020 is not set Do note that my 2.6.25 kernel was from Gentoo but none of the patches there seem related to RTC. Lior.
RTC_CLASS is selected but no drivers are configured. If switching from the 'old' RTC drivers then CONFIG_RTC_DRV_CMOS is required. How can we make the configuration process prevent that?
Reply-To: david-b@pacbell.net > ------- Comment #14 from cebbert@redhat.com 2008-06-15 15:34 ------- > RTC_CLASS is selected but no drivers are configured. > If switching from the 'old' RTC drivers then CONFIG_RTC_DRV_CMOS is required. > > How can we make the configuration process prevent that? I think that's been solved for some time, but not in the old config that started this: RTC_DRV_CMOS is "default y if X86". So selecting the RTC_CLASS should automatically enable the new one (and disable the legacy driver). Yes?
On Sun, Jun 15, 2008 at 11:15:23AM +0300, Lior Dotan wrote: > On Sat, Jun 14, 2008 at 12:20 AM, Adrian Bunk <bunk@kernel.org> wrote: > > > > What is the output of "grep RTC_ .config" on your old .config? > > Here it is: Thanks. >... > CONFIG_RTC_CLASS=y >... > # CONFIG_RTC_DRV_CMOS is not set >... That means the support for the PC RTC is disabled. Honestly, I do not think we can handle all possible misconfigurations when switching to the new RTC drivers automatically. > Lior. cu Adrian
Reply-To: liodot@gmail.com On Mon, Jun 16, 2008 at 3:24 AM, Adrian Bunk <bunk@kernel.org> wrote: > On Sun, Jun 15, 2008 at 11:15:23AM +0300, Lior Dotan wrote: >> On Sat, Jun 14, 2008 at 12:20 AM, Adrian Bunk <bunk@kernel.org> wrote: >> > >> > What is the output of "grep RTC_ .config" on your old .config? >> >> Here it is: > > Thanks. > >>... >> CONFIG_RTC_CLASS=y >>... >> # CONFIG_RTC_DRV_CMOS is not set >>... > > That means the support for the PC RTC is disabled. > > Honestly, I do not think we can handle all possible misconfigurations > when switching to the new RTC drivers automatically. In that case my configuration was indeed bogus and this bug can be closed. > cu > Adrian > Cheers, Lior.