2.6.25-rc7: Ugh. - Kernel

This is a discussion on 2.6.25-rc7: Ugh. - Kernel ; On Friday 28 March 2008, Ingo Molnar wrote: > > > Could somebody please fix the RTC mess in kconfig now ? > > > > My version has been sitting in MM for a while now. > > could ...

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 84

Thread: 2.6.25-rc7: Ugh.

  1. Re: 2.6.25-rc7: Ugh.

    On Friday 28 March 2008, Ingo Molnar wrote:
    > > > Could somebody please fix the RTC mess in kconfig now ?

    > >
    > > My version has been sitting in MM for a while now.

    >
    > could you please provide an URL or the patch itself so that others who
    > hit this issue and read this thread can apply the fix?


    I merged the two patches (gentle, then harsh) so the result is
    smaller. Here you go.

    - dave


    ========== CUT HERE
    Prevent the most significant RTC configuration problems:

    - If the new RTC framework is enabled, don't allow any of the
    legacy drivers to be configured.

    - When using generic RTC on x86, enable rtc-cmos by default.

    It seems too many people are used to enabling a legacy RTC despite
    the Kconfig help/comments; the gentle approach hasn't worked.

    Signed-off-by: David Brownell
    ---
    drivers/char/Kconfig | 8 ++++++++
    drivers/rtc/Kconfig | 5 +----
    2 files changed, 9 insertions(+), 4 deletions(-)

    --- linux-2.6.orig/drivers/char/Kconfig 2008-03-28 02:35:58.000000000 -0700
    +++ linux-2.6/drivers/char/Kconfig 2008-03-28 02:39:17.000000000 -0700
    @@ -704,6 +704,12 @@ config NVRAM
    To compile this driver as a module, choose M here: the
    module will be called nvram.

    +#
    +# These legacy RTC drivers just cause too many conflicts with the generic
    +# RTC framework ... let's not even try to coexist any more.
    +#
    +if RTC_LIB=n
    +
    config RTC
    tristate "Enhanced Real Time Clock Support"
    depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV && !ARM && !SUPERH && !S390
    @@ -812,6 +818,8 @@ config DS1302
    will get access to the real time clock (or hardware clock) built
    into your computer.

    +endif # RTC_LIB
    +
    config COBALT_LCD
    bool "Support for Cobalt LCD"
    depends on MIPS_COBALT
    --- linux-2.6.orig/drivers/rtc/Kconfig 2008-03-28 02:35:58.000000000 -0700
    +++ linux-2.6/drivers/rtc/Kconfig 2008-03-28 02:39:12.000000000 -0700
    @@ -20,10 +20,6 @@ menuconfig RTC_CLASS

    if RTC_CLASS

    -if GEN_RTC || RTC
    -comment "Conflicting RTC option has been selected, check GEN_RTC and RTC"
    -endif
    -
    config RTC_HCTOSYS
    bool "Set system time from RTC on startup and resume"
    depends on RTC_CLASS = y
    @@ -303,6 +299,7 @@ comment "Platform RTC drivers"
    config RTC_DRV_CMOS
    tristate "PC-style 'CMOS'"
    depends on X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPS
    + default y if X86
    help
    Say "yes" here to get direct support for the real time clock
    found in every PC or ACPI-based system, and some other boards.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: 2.6.25-rc7: Ugh.


    * David Brownell wrote:

    > Prevent the most significant RTC configuration problems:
    >
    > - If the new RTC framework is enabled, don't allow any of the
    > legacy drivers to be configured.


    yay!!!!

    > - When using generic RTC on x86, enable rtc-cmos by default.


    Amen.

    > It seems too many people are used to enabling a legacy RTC despite the
    > Kconfig help/comments; the gentle approach hasn't worked.


    Very-Much-Acked-by: Ingo Molnar

    it's not just about being gentle: it's that there are thousands of
    ..config options that are confusing to most users, so our defaults and
    rules must make sense. If we think that an approach is superior (which
    your new RTC code certainly is), we have to take up the responsibility
    of pushing that as a prominent, default choice and excluding the old
    code. That ends up benefiting everyone, reduces complexity of the
    kernel. You wont see anyone shed tears for the old code.

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

  3. Re: 2.6.25-rc7: Ugh.

    On Fri 2008-03-28 11:20:10, Ingo Molnar wrote:
    >
    > * David Brownell wrote:
    >
    > > Prevent the most significant RTC configuration problems:
    > >
    > > - If the new RTC framework is enabled, don't allow any of the
    > > legacy drivers to be configured.

    >
    > yay!!!!
    >
    > > - When using generic RTC on x86, enable rtc-cmos by default.

    >
    > Amen.
    >
    > > It seems too many people are used to enabling a legacy RTC despite the
    > > Kconfig help/comments; the gentle approach hasn't worked.

    >
    > Very-Much-Acked-by: Ingo Molnar

    Acked-by: Pavel Machek


    > it's not just about being gentle: it's that there are thousands of
    > .config options that are confusing to most users, so our defaults and
    > rules must make sense. If we think that an approach is superior (which
    > your new RTC code certainly is), we have to take up the responsibility
    > of pushing that as a prominent, default choice and excluding the old
    > code. That ends up benefiting everyone, reduces complexity of the
    > kernel. You wont see anyone shed tears for the old code.


    ....as I got bitten by this, too.

    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    On Fri, 28 Mar 2008 02:49:41 -0700, David Brownell wrote:
    > It seems too many people are used to enabling a legacy RTC despite
    > the Kconfig help/comments; the gentle approach hasn't worked.


    Gentleness is not the point. The Kconfig help/comments where just
    not clear at all.

    FWIW, it's still confusing to have an option "Enhanced Real Time
    Clock Support" under "Character Devices", then later an option
    "Real Time Clock" one level higher, none of the two in any way
    acknowledging the existence of the other one, and only after
    naively selecting both, you are told that there is some sort of
    conflict. Couldn't this be made more explicit, such as:
    - mentioning in both options' help text that the other one
    shouldn't be selected at the same time (if that's true)
    - noting explicitly which of the two RTC options is the "legacy"
    one (is it RTC_CLASS?)
    - enhancing the conflict message, which reads, in git-current:
    *** Conflicting RTC option has been selected, check GEN_RTC
    *** RTC interfaces ***
    Perhaps it's only me, but I do not know what to make of this.

    HTH
    T.

    --
    Tilman Schmidt E-Mail: tilman@imap.cc
    Bonn, Germany
    Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
    Unge÷ffnet mindestens haltbar bis: (siehe RŘckseite)


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.4 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFH7Om7Q3+did9BuFsRAgvBAJ44Qb2EJRPNmcjKspYwRY h0nwnLFACeIARi
    5JRZaHYw5/7rbnPE/jmDOpk=
    =eMpk
    -----END PGP SIGNATURE-----


  5. Re: Kconfig RTC selection

    Tilman Schmidt wrote:
    > On Fri, 28 Mar 2008 02:49:41 -0700, David Brownell wrote:
    >> It seems too many people are used to enabling a legacy RTC despite the
    >> Kconfig help/comments; the gentle approach hasn't worked.

    >
    > Gentleness is not the point. The Kconfig help/comments where just
    > not clear at all.
    >
    > FWIW, it's still confusing to have an option "Enhanced Real Time
    > Clock Support" under "Character Devices", then later an option
    > "Real Time Clock" one level higher, none of the two in any way
    > acknowledging the existence of the other one, and only after
    > naively selecting both, you are told that there is some sort of
    > conflict. Couldn't this be made more explicit, such as:
    > - mentioning in both options' help text that the other one
    > shouldn't be selected at the same time (if that's true)
    > - noting explicitly which of the two RTC options is the "legacy"
    > one (is it RTC_CLASS?)
    > - enhancing the conflict message, which reads, in git-current:
    > *** Conflicting RTC option has been selected, check GEN_RTC
    > *** RTC interfaces ***

    ...

    Exactly the issue. Mod++++++++++++++++++++++

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

  6. Re: 2.6.25-rc7: Ugh.

    David Brownell wrote:
    > On Friday 28 March 2008, Ingo Molnar wrote:
    >>>> Could somebody please fix the RTC mess in kconfig now ?
    >>> My version has been sitting in MM for a while now.

    >> could you please provide an URL or the patch itself so that others who
    >> hit this issue and read this thread can apply the fix?

    >
    > I merged the two patches (gentle, then harsh) so the result is
    > smaller. Here you go.
    >
    > - dave
    >
    >
    > ========== CUT HERE
    > Prevent the most significant RTC configuration problems:
    >
    > - If the new RTC framework is enabled, don't allow any of the
    > legacy drivers to be configured.
    >
    > - When using generic RTC on x86, enable rtc-cmos by default.
    >
    > It seems too many people are used to enabling a legacy RTC despite
    > the Kconfig help/comments; the gentle approach hasn't worked.
    >
    > Signed-off-by: David Brownell
    > ---
    > drivers/char/Kconfig | 8 ++++++++
    > drivers/rtc/Kconfig | 5 +----
    > 2 files changed, 9 insertions(+), 4 deletions(-)
    >
    > --- linux-2.6.orig/drivers/char/Kconfig 2008-03-28 02:35:58.000000000 -0700
    > +++ linux-2.6/drivers/char/Kconfig 2008-03-28 02:39:17.000000000 -0700
    > @@ -704,6 +704,12 @@ config NVRAM
    > To compile this driver as a module, choose M here: the
    > module will be called nvram.
    >
    > +#
    > +# These legacy RTC drivers just cause too many conflicts with the generic
    > +# RTC framework ... let's not even try to coexist any more.

    ....

    Thanks, David. Could you perhaps also update the option descriptions
    to clearly indicate which set of RTCs are the new ones, and which are
    the old ones that are going away someday?

    I didn't find it at all obvious, and I still don't know which set my
    configured kernel is actually using.

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

  7. Re: 2.6.25-rc7: Ugh.

    On Thu, 27 Mar 2008, Mark Lord wrote:

    > Same thing happens when I rmmod usbhid, and then rmmod ehci_hcd.
    > The rmmod ehci_hcd hangs.
    >
    > But since the rest of the system is still alive, including the non-USB touchpad(!),
    > here is the alt-sysrq-t from syslog:
    >
    > rmmod D f74c2ddc 0 4538 4492
    > f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be 00000000
    > 00000001 c0324a00 c0324a00 00000000 00000001 7fffffff 7fffffff f653cea8
    > 00000002 c02906f8 00000000 00000012 c038f6aa 00000086 c011aa05 00000000
    > Call Trace:
    > [__wake_up_common+46/88] __wake_up_common+0x2e/0x58
    > [schedule_timeout+19/134] schedule_timeout+0x13/0x86
    > [wake_up_klogd+43/45] wake_up_klogd+0x2b/0x2d
    > [wait_for_common+205/308] wait_for_common+0xcd/0x134
    > [default_wake_function+0/8] default_wake_function+0x0/0x8
    > [__cancel_work_timer+237/312] __cancel_work_timer+0xed/0x138
    > [wq_barrier_func+0/8] wq_barrier_func+0x0/0x8
    > [] usb_remove_hcd+0x63/0xd7 [usbcore]
    > [] usb_hcd_pci_remove+0x15/0x68 [usbcore]
    > [pci_device_remove+22/53] pci_device_remove+0x16/0x35
    > [__device_release_driver+88/118] __device_release_driver+0x58/0x76
    > [driver_detach+122/182] driver_detach+0x7a/0xb6
    > [bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e
    > [pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f
    > [sys_delete_module+388/445] sys_delete_module+0x184/0x1bd
    > [remove_vma+49/54] remove_vma+0x31/0x36
    > [do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0
    > [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
    > =======================
    >
    > If nothing else, this should point to where USB is getting deadlocked.
    >
    > ??


    rmmod is hanging up in a call to cancel_work_sync(), which means the
    real problem is in the workqueue. It's quite understandable that you
    wouldn't want to go any further into debugging this, but in case you
    don't mind, the workqueue task is ksuspend_usbd.

    On the other hand, I don't understand how problems with the RTC
    configuration could cause this sort of result.

    Alan Stern

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

  8. Re: 2.6.25-rc7: Ugh.

    Alan Stern wrote:
    > On Thu, 27 Mar 2008, Mark Lord wrote:
    >
    >> Same thing happens when I rmmod usbhid, and then rmmod ehci_hcd.
    >> The rmmod ehci_hcd hangs.
    >>
    >> But since the rest of the system is still alive, including the non-USB touchpad(!),
    >> here is the alt-sysrq-t from syslog:
    >>
    >> rmmod D f74c2ddc 0 4538 4492
    >> f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be 00000000
    >> 00000001 c0324a00 c0324a00 00000000 00000001 7fffffff 7fffffff f653cea8
    >> 00000002 c02906f8 00000000 00000012 c038f6aa 00000086 c011aa05 00000000
    >> Call Trace:
    >> [__wake_up_common+46/88] __wake_up_common+0x2e/0x58
    >> [schedule_timeout+19/134] schedule_timeout+0x13/0x86
    >> [wake_up_klogd+43/45] wake_up_klogd+0x2b/0x2d
    >> [wait_for_common+205/308] wait_for_common+0xcd/0x134
    >> [default_wake_function+0/8] default_wake_function+0x0/0x8
    >> [__cancel_work_timer+237/312] __cancel_work_timer+0xed/0x138
    >> [wq_barrier_func+0/8] wq_barrier_func+0x0/0x8
    >> [] usb_remove_hcd+0x63/0xd7 [usbcore]
    >> [] usb_hcd_pci_remove+0x15/0x68 [usbcore]
    >> [pci_device_remove+22/53] pci_device_remove+0x16/0x35
    >> [__device_release_driver+88/118] __device_release_driver+0x58/0x76
    >> [driver_detach+122/182] driver_detach+0x7a/0xb6
    >> [bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e
    >> [pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f
    >> [sys_delete_module+388/445] sys_delete_module+0x184/0x1bd
    >> [remove_vma+49/54] remove_vma+0x31/0x36
    >> [do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0
    >> [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
    >> =======================
    >>
    >> If nothing else, this should point to where USB is getting deadlocked.
    >>
    >> ??

    >
    > rmmod is hanging up in a call to cancel_work_sync(), which means the
    > real problem is in the workqueue. It's quite understandable that you
    > wouldn't want to go any further into debugging this, but in case you
    > don't mind, the workqueue task is ksuspend_usbd.
    >
    > On the other hand, I don't understand how problems with the RTC
    > configuration could cause this sort of result.

    ...

    Yeah, me neither. It's not clear whether simply changing the kernel
    config made a race condition "go away" for now, or whether it really
    fixed things for real.

    My system is working with the current config, that's all I know right now.
    Gotta fix VMware modules again, but that's de-rigour with new kernels.

    Cheers

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

  9. Re: 2.6.25-rc7: Ugh.


    On Friday 2008-03-28 10:49, David Brownell wrote:
    > @@ -303,6 +299,7 @@ comment "Platform RTC drivers"
    > config RTC_DRV_CMOS
    > tristate "PC-style 'CMOS'"
    > depends on X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPS
    > + default y if X86
    > help
    > Say "yes" here to get direct support for the real time clock
    > found in every PC or ACPI-based system, and some other boards.


    I do not see why it should default to y, given that udev loads my m
    perfectly fine.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: 2.6.25-rc7: Ugh.


    On Friday 2008-03-28 11:20, Ingo Molnar wrote:
    >
    > it's not just about being gentle: it's that there are thousands of
    > .config options that are confusing to most users, so our defaults and
    > rules must make sense. If we think that an approach is superior (which
    > your new RTC code certainly is), we have to take up the responsibility
    > of pushing that as a prominent, default choice and excluding the old
    > code. That ends up benefiting everyone, reduces complexity of the
    > kernel. You wont see anyone shed tears for the old code.


    Users with audio-related usage patterns do, as SND_RTCTIMER
    still depends on old rtc :-/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: 2.6.25-rc7: Ugh.

    David Miller wrote:
    > Builds are just over a minute on my box. I can do a full
    > kernel build plus reboot cycle in under 2 minutes.


    I've gotta get me some of that :-).

    --
    ------------------------------------------------------------------------
    Bob Tracy | "I was a beta tester for dirt. They never did
    rct@frus.com | get all the bugs out." - Steve McGrew on /.
    ------------------------------------------------------------------------
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: 2.6.25-rc7: Ugh.

    On Fri, Mar 28, 2008 at 03:56:49PM +0100, Jan Engelhardt wrote:
    >
    > On Friday 2008-03-28 10:49, David Brownell wrote:
    >> @@ -303,6 +299,7 @@ comment "Platform RTC drivers"
    >> config RTC_DRV_CMOS
    >> tristate "PC-style 'CMOS'"
    >> depends on X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPS
    >> + default y if X86
    >> help
    >> Say "yes" here to get direct support for the real time clock
    >> found in every PC or ACPI-based system, and some other boards.

    >
    > I do not see why it should default to y, given that udev loads my m
    > perfectly fine.


    Then there's no problem with having it default to "y".

    The usual case is to have a driver disabled by default, and when it's
    that common that we do not want it disabled by default we can as well
    immediately let it default to "y".

    The user still has all three choices.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  13. Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    On Friday 28 March 2008, Tilman Schmidt wrote:
    >
    > FWIW, it's still confusing to have an option "Enhanced Real Time
    > Clock Support" under "Character Devices", then later an option
    > "Real Time Clock" one level higher, none of the two in any way
    > acknowledging the existence of the other one, and only after
    > naively selecting both, you are told that there is some sort of
    > conflict.


    You mean "still, after applying that patch I sent"? I don't
    see how that could be; it doesn't allow both to be selected.


    > Couldn't this be made more explicit, such as:
    > - mentioning in both options' help text that the other one
    > shouldn't be selected at the same time (if that's true)


    I think that'd be more confusing, since it's not possible.
    Telling people not to do something will usually make them
    think it's possible ...


    > - noting explicitly which of the two RTC options is the "legacy"
    > one (is it RTC_CLASS?)


    That term isn't visible through the Kconfig user interfaces,
    so I'm not sure why it should be introduced except as part
    of a strategy to get rid of all those old drivers. Which is
    probably worth having, but isn't waht that patch addressed!


    > - enhancing the conflict message, which reads, in git-current:
    > *** Conflicting RTC option has been selected, check GEN_RTC
    > *** RTC interfaces ***
    > Perhaps it's only me, but I do not know what to make of this.


    Me either, since the patch I sent removed that message.
    I'm now quite sure you did *NOT* apply and try that patch
    before responding to it.

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

  14. Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    [ CC's trimmed a bit ]

    On Friday 28 March 2008, Mark Lord wrote:
    > > +# These legacy RTC drivers just cause too many conflicts with the generic
    > > +# RTC framework ... let's not even try to coexist any more.

    > ...
    >
    > Thanks, David. *Could you perhaps also update the option descriptions
    > to clearly indicate which set of RTCs are the new ones, and which are
    > the old ones that are going away someday?


    Hmm, I thought that would be clear from context.
    "These" (drivers/char) legacy RTC drivers (old),
    vs generic RTC framework (toplevel driver Kconfig).

    Admittedly the *previous* Kconfig was troublesome,
    at the UI level (vs. those comments outside the GUI).


    A more general issue seems to be what to do with
    those legacy RTC drivers. Few of them seem to
    have maintainers. I don't want to own them, and
    I doubt Alessandro does either. If their Kconfig
    is going to change, I'd rather just see them all
    flagged as deprecated ... with plans to delete them.

    The RTCs in question being:

    "RTC" ... replaced by new "rtc-cmos"
    --> ready to deprecate now ?

    "JS_RTC" ... a SPARC32 thing
    --> bug?? no "js-rtc.c" in the tree! patch sent

    "SGI_DS1286" ...
    --> needs conversion to new framework

    "SGI_IP27_RTC" ...
    --> needs conversion to new framework

    "GEN_RTC", "GEN_RTC_X" ... I never really saw the point
    --> who uses this?

    "EFI_RTC" ... IA64 only
    --> needs conversion to new framework

    "DS1302" ... M32R-specific, "rtc-ds1302" should replace it
    --> ready to deprecate now?

    Plus there are various chunks of RTC code elsewhere in the tree,
    mostly in arch subdirectories, which should be phased out but
    aren't such obvious targets.


    > I didn't find it at all obvious, and I still don't know which set my
    > configured kernel is actually using.


    If you enable the new framework, that's what it's
    using; there should be no other options visible.
    (At least, none that are even as loosely organized
    as the drivers/char stuff.)

    Else ... it's clearly not enabled! So it's some
    other (legacy) RTC driver. I don't see the issue.

    - Dave

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

  15. Re: 2.6.25-rc7: Ugh.

    On Friday 28 March 2008, Jan Engelhardt wrote:
    > > If we think that an approach is superior (which
    > > your new RTC code certainly is), we have to take up the responsibility
    > > of pushing that as a prominent, default choice and excluding the old
    > > code. That ends up benefiting everyone, reduces complexity of the
    > > kernel. You wont see anyone shed tears for the old code.

    >
    > Users with audio-related usage patterns do, as SND_RTCTIMER
    > still depends on old rtc :-/


    -ENOPATCH

    Last time this specific issue came up, a related point was
    that the relevant ALSA documentation in this area needed
    updating too. ISTR it assumed there was only one kind of
    RTC, and had a few other issues.

    - Dave

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

  16. Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    On Fri, Mar 28, 2008 at 01:04:38PM -0700, David Brownell wrote:
    > [ CC's trimmed a bit ]
    >
    > On Friday 28 March 2008, Mark Lord wrote:
    > > > +# These legacy RTC drivers just cause too many conflicts with the generic
    > > > +# RTC framework ... let's not even try to coexist any more.

    > > ...
    > >
    > > Thanks, David. ┬*Could you perhaps also update the option descriptions
    > > to clearly indicate which set of RTCs are the new ones, and which are
    > > the old ones that are going away someday?

    >
    > Hmm, I thought that would be clear from context.
    > "These" (drivers/char) legacy RTC drivers (old),
    > vs generic RTC framework (toplevel driver Kconfig).
    >
    > Admittedly the *previous* Kconfig was troublesome,
    > at the UI level (vs. those comments outside the GUI).
    >
    >
    > A more general issue seems to be what to do with
    > those legacy RTC drivers. Few of them seem to
    > have maintainers. I don't want to own them, and
    > I doubt Alessandro does either. If their Kconfig
    > is going to change, I'd rather just see them all
    > flagged as deprecated ... with plans to delete them.
    >
    > The RTCs in question being:
    >
    > "RTC" ... replaced by new "rtc-cmos"
    > --> ready to deprecate now ?


    The only reason against killing it immediately seems to be SND_RTCTIMER.

    > "JS_RTC" ... a SPARC32 thing
    > --> bug?? no "js-rtc.c" in the tree! patch sent


    Where's the bug?
    js-rtc is built from rtc.c

    >...
    > "DS1302" ... M32R-specific, "rtc-ds1302" should replace it
    > --> ready to deprecate now?
    >...


    Kconfig currently offers rtc-ds1302 only for an sh platform...

    > - Dave


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  17. Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    On Friday 28 March 2008, Adrian Bunk wrote:
    > > * "JS_RTC" ... a SPARC32 thing
    > > ******--> bug?? no "js-rtc.c" in the tree! *patch sent

    >
    > Where's the bug?
    > js-rtc is built from rtc.c


    In which case, just enable rtc.c ... a "egrep -r 'JS_RTC|js-rtc'"
    shows that it looks pretty pointless.


    > >...
    > > * "DS1302" ... M32R-specific, "rtc-ds1302" should replace it
    > > ******--> ready to deprecate now?
    > >...

    >
    > Kconfig currently offers rtc-ds1302 only for an sh platform...


    Right, I looked at that a bit more. The rtc-ds1302 code was
    not written portably. If it were updated to get addresses
    from platform resources -- like *normal* platform drivers do,
    since the addresses are platform specific -- and if those two
    M32R platforms got updated ... *then* this could be deprecated.

    - Dave



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

  18. Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    On Fri, Mar 28, 2008 at 02:23:45PM -0700, David Brownell wrote:
    > On Friday 28 March 2008, Adrian Bunk wrote:
    > > > ┬* "JS_RTC" ... a SPARC32 thing
    > > > ┬*┬*┬*┬*┬*┬*--> bug?? no "js-rtc.c" in the tree! ┬*patch sent

    > >
    > > Where's the bug?
    > > js-rtc is built from rtc.c

    >
    > In which case, just enable rtc.c ... a "egrep -r 'JS_RTC|js-rtc'"
    > shows that it looks pretty pointless.
    >...


    grep for CONFIG_SUN_MOSTEK_RTC and you'll get the point.

    > - Dave


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  19. Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)

    On Friday 28 March 2008, Adrian Bunk wrote:
    > > > > * "JS_RTC" ... a SPARC32 thing
    > > > > ******--> bug?? no "js-rtc.c" in the tree! *patch sent
    > > >
    > > > Where's the bug?
    > > > js-rtc is built from rtc.c

    > >
    > > In which case, just enable rtc.c ... a "egrep -r 'JS_RTC|js-rtc'"
    > > shows that it looks pretty pointless.
    > >...

    >
    > grep for CONFIG_SUN_MOSTEK_RTC and you'll get the point.


    Right: it doesn't mention JS_RTC at all. Whatever is up
    with that stuff, it's broken.

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

  20. Re: 2.6.25-rc7: Ugh.

    Mark Lord wrote:
    > Mark Lord wrote:
    >> Mark Lord wrote:
    >>>
    >>> When I rebuilt with all debug stuff on, the kernel was worse than
    >>> before, and just gave the "black screen of nothing" on resume,
    >>> with a hung system.
    >>>
    >>> At least before the system didn't hang.
    >>>
    >>> Now I've just booted with a differently configured kernel,
    >>> with only about half of the debug flags turned on.
    >>> This one resumes from suspend, and *with* working USB too.
    >>>
    >>> Ugh. Gotta love it when the bug is so subtle that turning on
    >>> the debug flags makes it (1) get worse, and/or (2) get cured.
    >>>
    >>> Here's the abbreviated diff between broken (no USB on resume, no hang),
    >>> and working (good USB, no hang) .config files.

    >> ..
    >>> -CONFIG_RTC_CLASS=y
    >>> +# CONFIG_RTC_CLASS is not set

    >>
    >> Mmm.. also had the RTC conflict resolved in that one.
    >> Time to try another kernel with just the RTC change now.

    > ..
    >
    > Okay, that might be it. I've booted and am running without debug flags again.

    ...

    An update: still mostly stable now.
    But I have seen one resume failure on this machine since then,
    and that's not "normal" -- suspend/resume are normally rock solid.

    My other pure Intel Dell X1 notebook has also hung a couple
    of time during startup -- usually with "switched to high resolution"
    messages near-last on the the screen. There's a long standing bug
    to do with that stuff, which I first reported back in 2.6.20 (or .21).
    Back then, it was kernel .config dependent, and has never been tracked down.

    Maybe the same thing here, maybe not.

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

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast