Bug 10866

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&amp;m=121267834521432&amp;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&amp;m=121267834521432&amp;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&amp;m=121267834521432&amp;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.