Pavel Machek wrote:
Hi!
I agree. Still in all that follows, no one has addressed the apparent
race described above. The reason the system reported the errors that
started this thread is that the APM restore code was trying to read the
cmos clock (I assume to set the xtime clock) WHILE the
Pavel Machek wrote:
Hi!
I agree. Still in all that follows, no one has addressed the apparent
race described above. The reason the system reported the errors that
started this thread is that the APM restore code was trying to read the
cmos clock (I assume to set the xtime clock) WHILE the
Hi!
> >>I agree. Still in all that follows, no one has addressed the apparent
> >>race described above. The reason the system reported the errors that
> >>started this thread is that the APM restore code was trying to read the
> >>cmos clock (I assume to set the xtime clock) WHILE the timer
Pavel Machek wrote:
Hi!
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume that the time is wrong at
this
time and we are about to save that wrong time. Possibly the APM code
should
change time_status to STA_UNSYNC on the
Pavel Machek wrote:
Hi!
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume that the time is wrong at
this
time and we are about to save that wrong time. Possibly the APM code
should
change time_status to STA_UNSYNC on the
Hi!
I agree. Still in all that follows, no one has addressed the apparent
race described above. The reason the system reported the errors that
started this thread is that the APM restore code was trying to read the
cmos clock (I assume to set the xtime clock) WHILE the timer interrupt
Hi!
> >>And more... That this occures implies we are attempting to update the cmos
> >>clock on resume seems wrong. One would presume that the time is wrong at
> >>this
> >>time and we are about to save that wrong time. Possibly the APM code
> >>should
> >>change time_status to STA_UNSYNC on
Hi!
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume that the time is wrong at
this
time and we are about to save that wrong time. Possibly the APM code
should
change time_status to STA_UNSYNC on the way into the
On Sat, 2005-03-12 at 07:56 -0800, George Anzinger wrote:
> J. Bruce Fields wrote:
> > On APM resume this morning on my Thinkpad X31, I got a "spin_lock is
> > already locked" error; see below. This doesn't happen on every resume,
> > though it's happened before. The kernel is 2.6.11 plus a
On Sat, Mar 12, 2005 at 07:56:10AM -0800, George Anzinger wrote:
> Yesterday's night mare, todays bug :(
Actually, I think people have been hitting this bug for a few months on
Fedora Core, so it's not really *today's* bug... This might be the first
time it's getting discussed on LKML though. (I
Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
I agree. Still in all that follows, no one has addressed the apparent race
described above. The reason the system reported the errors that started this
thread is that the APM restore code was trying to read the cmos clock (I
On Sat, 12 Mar 2005, George Anzinger wrote:
> I agree. Still in all that follows, no one has addressed the apparent race
> described above. The reason the system reported the errors that started this
> thread is that the APM restore code was trying to read the cmos clock (I
> assume to set the
Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
Looks like we need the irq on the read clock also. This is true both before
and after the prior cmos_time changes.
The attached replaces the patch I sent yesterday.
For those wanting to fix the kernel with out those patches, all
On Sat, Mar 12, 2005 at 09:46:54AM -0700, Zwane Mwaikambo wrote:
> On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
>
> > On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
> >
> > How about this patch? Also fixes one other use of rtc_lock in
> > acpi/sleep/proc.c
> >
> > rtc_lock
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
> On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
> > On Sat, 12 Mar 2005, George Anzinger wrote:
> >
> > > And more... That this occures implies we are attempting to update the cmos
> > > clock on resume seems wrong. One would
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
> On Sat, 12 Mar 2005, George Anzinger wrote:
>
> > And more... That this occures implies we are attempting to update the cmos
> > clock on resume seems wrong. One would presume that the time is wrong at
> > this
> > time and we
On Sat, 12 Mar 2005, George Anzinger wrote:
> Looks like we need the irq on the read clock also. This is true both before
> and after the prior cmos_time changes.
>
> The attached replaces the patch I sent yesterday.
>
> For those wanting to fix the kernel with out those patches, all that is
J. Bruce Fields wrote:
On APM resume this morning on my Thinkpad X31, I got a "spin_lock is
already locked" error; see below. This doesn't happen on every resume,
though it's happened before. The kernel is 2.6.11 plus a bunch of
(hopefully unrelated...) NFS patches.
Any ideas?
Yesterday's night
On APM resume this morning on my Thinkpad X31, I got a "spin_lock is
already locked" error; see below. This doesn't happen on every resume,
though it's happened before. The kernel is 2.6.11 plus a bunch of
(hopefully unrelated...) NFS patches.
Any ideas?
--Bruce Fields
Mar 12 07:07:29 puzzle
On APM resume this morning on my Thinkpad X31, I got a spin_lock is
already locked error; see below. This doesn't happen on every resume,
though it's happened before. The kernel is 2.6.11 plus a bunch of
(hopefully unrelated...) NFS patches.
Any ideas?
--Bruce Fields
Mar 12 07:07:29 puzzle
J. Bruce Fields wrote:
On APM resume this morning on my Thinkpad X31, I got a spin_lock is
already locked error; see below. This doesn't happen on every resume,
though it's happened before. The kernel is 2.6.11 plus a bunch of
(hopefully unrelated...) NFS patches.
Any ideas?
Yesterday's night
On Sat, 12 Mar 2005, George Anzinger wrote:
Looks like we need the irq on the read clock also. This is true both before
and after the prior cmos_time changes.
The attached replaces the patch I sent yesterday.
For those wanting to fix the kernel with out those patches, all that is needed
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume that the time is wrong at
this
time and we are about
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume that
On Sat, Mar 12, 2005 at 09:46:54AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
How about this patch? Also fixes one other use of rtc_lock in
acpi/sleep/proc.c
rtc_lock is held during
Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
Looks like we need the irq on the read clock also. This is true both before
and after the prior cmos_time changes.
The attached replaces the patch I sent yesterday.
For those wanting to fix the kernel with out those patches, all
On Sat, 12 Mar 2005, George Anzinger wrote:
I agree. Still in all that follows, no one has addressed the apparent race
described above. The reason the system reported the errors that started this
thread is that the APM restore code was trying to read the cmos clock (I
assume to set the
Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
I agree. Still in all that follows, no one has addressed the apparent race
described above. The reason the system reported the errors that started this
thread is that the APM restore code was trying to read the cmos clock (I
On Sat, Mar 12, 2005 at 07:56:10AM -0800, George Anzinger wrote:
Yesterday's night mare, todays bug :(
Actually, I think people have been hitting this bug for a few months on
Fedora Core, so it's not really *today's* bug... This might be the first
time it's getting discussed on LKML though. (I
On Sat, 2005-03-12 at 07:56 -0800, George Anzinger wrote:
J. Bruce Fields wrote:
On APM resume this morning on my Thinkpad X31, I got a spin_lock is
already locked error; see below. This doesn't happen on every resume,
though it's happened before. The kernel is 2.6.11 plus a bunch of
30 matches
Mail list logo
