Sorry for slow response, I've just noticed this thread.
On Tuesday, 31 July 2007 23:20, Chuck Ebbert wrote:
> When resuming, systems print this when booted on 07/31/07:
>
> Date: 06/31/107
>
> /drivers/base/power/trace.c::read_magic_time():
> 114 get_rtc_time(&time);
> 115 printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
> 116 time.tm_hour, time.tm_min, time.tm_sec,
> 117 time.tm_mon, time.tm_mday, time.tm_year);
>
> include/asm-generic/rtc.h:
> 102 /*
> 103 * Account for differences between how the RTC uses the values
> 104 * and how they are defined in a struct rtc_time;
> 105 */
> 106 if (time->tm_year <= 69)
> 107 time->tm_year += 100;
> 108
> 109 time->tm_mon--;
Do you mean that systems display bad date after resuming if PM_TRACE is set,
even if /sys/power/pm_trace contains 1 ?
If that's the case, are they i386 or x86_64?
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
On Wednesday, 1 August 2007 17:47, Rafael J. Wysocki wrote:
> Sorry for slow response, I've just noticed this thread.
>
> On Tuesday, 31 July 2007 23:20, Chuck Ebbert wrote:
> > When resuming, systems print this when booted on 07/31/07:
> >
> > Date: 06/31/107
> >
> > /drivers/base/power/trace.c::read_magic_time():
> > 114 get_rtc_time(&time);
> > 115 printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
> > 116 time.tm_hour, time.tm_min, time.tm_sec,
> > 117 time.tm_mon, time.tm_mday, time.tm_year);
> >
> > include/asm-generic/rtc.h:
> > 102 /*
> > 103 * Account for differences between how the RTC uses the values
> > 104 * and how they are defined in a struct rtc_time;
> > 105 */
> > 106 if (time->tm_year <= 69)
> > 107 time->tm_year += 100;
> > 108
> > 109 time->tm_mon--;
>
> Do you mean that systems display bad date after resuming if PM_TRACE is set,
> even if /sys/power/pm_trace contains 1 ?
s/1/0/ (sorry)
On 08/01/2007 11:47 AM, Rafael J. Wysocki wrote:
> Sorry for slow response, I've just noticed this thread.
>
> On Tuesday, 31 July 2007 23:20, Chuck Ebbert wrote:
>> When resuming, systems print this when booted on 07/31/07:
>>
>> Date: 06/31/107
>>
>> /drivers/base/power/trace.c::read_magic_time():
>> 114 get_rtc_time(&time);
>> 115 printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
>> 116 time.tm_hour, time.tm_min, time.tm_sec,
>> 117 time.tm_mon, time.tm_mday, time.tm_year);
>>
>> include/asm-generic/rtc.h:
>> 102 /*
>> 103 * Account for differences between how the RTC uses the values
>> 104 * and how they are defined in a struct rtc_time;
>> 105 */
>> 106 if (time->tm_year <= 69)
>> 107 time->tm_year += 100;
>> 108
>> 109 time->tm_mon--;
>
> Do you mean that systems display bad date after resuming if PM_TRACE is set,
> even if /sys/power/pm_trace contains 1 ?
>
> If that's the case, are they i386 or x86_64?
>
i386:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250238
On Wednesday, 1 August 2007 20:15, Chuck Ebbert wrote:
> On 08/01/2007 11:47 AM, Rafael J. Wysocki wrote:
> > Sorry for slow response, I've just noticed this thread.
> >
> > On Tuesday, 31 July 2007 23:20, Chuck Ebbert wrote:
> >> When resuming, systems print this when booted on 07/31/07:
> >>
> >> Date: 06/31/107
> >>
> >> /drivers/base/power/trace.c::read_magic_time():
> >> 114 get_rtc_time(&time);
> >> 115 printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
> >> 116 time.tm_hour, time.tm_min, time.tm_sec,
> >> 117 time.tm_mon, time.tm_mday, time.tm_year);
> >>
> >> include/asm-generic/rtc.h:
> >> 102 /*
> >> 103 * Account for differences between how the RTC uses the values
> >> 104 * and how they are defined in a struct rtc_time;
> >> 105 */
> >> 106 if (time->tm_year <= 69)
> >> 107 time->tm_year += 100;
> >> 108
> >> 109 time->tm_mon--;
> >
> > Do you mean that systems display bad date after resuming if PM_TRACE is set,
> > even if /sys/power/pm_trace contains 1 ?
> >
> > If that's the case, are they i386 or x86_64?
> >
>
> i386:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250238
OK, I now see what you mean.
On my x86_64 test box this also happens after a fresh boot without
suspending/resuming, so I think the problem is that we just shouldn't add 100
to the year and decrease the month in get_rtc_time().
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
On Wednesday, 1 August 2007 20:15, Chuck Ebbert wrote:
> On 08/01/2007 11:47 AM, Rafael J. Wysocki wrote:
> > Sorry for slow response, I've just noticed this thread.
> >
> > On Tuesday, 31 July 2007 23:20, Chuck Ebbert wrote:
> >> When resuming, systems print this when booted on 07/31/07:
> >>
> >> Date: 06/31/107
> >>
> >> /drivers/base/power/trace.c::read_magic_time():
> >> 114 get_rtc_time(&time);
> >> 115 printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
> >> 116 time.tm_hour, time.tm_min, time.tm_sec,
> >> 117 time.tm_mon, time.tm_mday, time.tm_year);
> >>
> >> include/asm-generic/rtc.h:
> >> 102 /*
> >> 103 * Account for differences between how the RTC uses the values
> >> 104 * and how they are defined in a struct rtc_time;
> >> 105 */
> >> 106 if (time->tm_year <= 69)
> >> 107 time->tm_year += 100;
> >> 108
> >> 109 time->tm_mon--;
> >
> > Do you mean that systems display bad date after resuming if PM_TRACE is set,
> > even if /sys/power/pm_trace contains 1 ?
s/1/0/
> > If that's the case, are they i386 or x86_64?
> >
>
> i386:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250238
OK, I think the appended patch is needed.
Greetings,
Rafael
---
The way in which read_magic_time() displays the date read from the RTC is
apparently confusing to the users
(cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250238). Make it
print dates in the standard way.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
drivers/base/power/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc1/drivers/base/power/trace.c
===================================================================
--- linux-2.6.23-rc1.orig/drivers/base/power/trace.c 2007-07-23 22:06:42.000000000 +0200
+++ linux-2.6.23-rc1/drivers/base/power/trace.c 2007-08-01 22:51:16.000000000 +0200
@@ -114,7 +114,7 @@ static unsigned int read_magic_time(void
get_rtc_time(&time);
printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
time.tm_hour, time.tm_min, time.tm_sec,
- time.tm_mon, time.tm_mday, time.tm_year);
+ time.tm_mon + 1, time.tm_mday, time.tm_year % 100);
val = time.tm_year; /* 100 years */
if (val > 100)
val -= 100;
The patch below seems to have got dropped on the floor.
We've had it in Fedora since it was posted, and it does the
right thing, so I'm happy to give this an
ACKed-by: Dave Jones <[email protected]>
if it helps it into upstream.
Dave
On Wed, Aug 01, 2007 at 11:04:34PM +0200, Rafael J. Wysocki wrote:
> > On 08/01/2007 11:47 AM, Rafael J. Wysocki wrote:
> > > Sorry for slow response, I've just noticed this thread.
> > >
> > > On Tuesday, 31 July 2007 23:20, Chuck Ebbert wrote:
> > >> When resuming, systems print this when booted on 07/31/07:
> > >>
> > >> Date: 06/31/107
> > >>
> > >> /drivers/base/power/trace.c::read_magic_time():
> > >> 114 get_rtc_time(&time);
> > >> 115 printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
> > >> 116 time.tm_hour, time.tm_min, time.tm_sec,
> > >> 117 time.tm_mon, time.tm_mday, time.tm_year);
> > >>
> > >> include/asm-generic/rtc.h:
> > >> 102 /*
> > >> 103 * Account for differences between how the RTC uses the values
> > >> 104 * and how they are defined in a struct rtc_time;
> > >> 105 */
> > >> 106 if (time->tm_year <= 69)
> > >> 107 time->tm_year += 100;
> > >> 108
> > >> 109 time->tm_mon--;
> > >
> > > Do you mean that systems display bad date after resuming if PM_TRACE is set,
> > > even if /sys/power/pm_trace contains 1 ?
>
> s/1/0/
>
> > > If that's the case, are they i386 or x86_64?
> > >
> >
> > i386:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250238
>
> OK, I think the appended patch is needed.
>
> Greetings,
> Rafael
>
>
> ---
> The way in which read_magic_time() displays the date read from the RTC is
> apparently confusing to the users
> (cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250238). Make it
> print dates in the standard way.
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
> drivers/base/power/trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.23-rc1/drivers/base/power/trace.c
> ===================================================================
> --- linux-2.6.23-rc1.orig/drivers/base/power/trace.c 2007-07-23 22:06:42.000000000 +0200
> +++ linux-2.6.23-rc1/drivers/base/power/trace.c 2007-08-01 22:51:16.000000000 +0200
> @@ -114,7 +114,7 @@ static unsigned int read_magic_time(void
> get_rtc_time(&time);
> printk("Time: %2d:%02d:%02d Date: %02d/%02d/%02d\n",
> time.tm_hour, time.tm_min, time.tm_sec,
> - time.tm_mon, time.tm_mday, time.tm_year);
> + time.tm_mon + 1, time.tm_mday, time.tm_year % 100);
> val = time.tm_year; /* 100 years */
> if (val > 100)
> val -= 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/
---end quoted text---
--
http://www.codemonkey.org.uk
On Wed, 17 Oct 2007 15:48:40 -0400
Dave Jones <[email protected]> wrote:
> The patch below seems to have got dropped on the floor.
> We've had it in Fedora since it was posted, and it does the
> right thing, so I'm happy to give this an
>
> ACKed-by: Dave Jones <[email protected]>
>
> if it helps it into upstream.
I have it queued for 2.6.24, but the entire PM patch series is presently
twiddling thumbs awaiting an acpi merge.