Hello,
I am still not sure why you cannot use an IPI for this... on the CPU that
you want to access this resource, send an IPI to all other CPUs, and add
code in handling that IPI that they should spin and wait till you are done
with accessing the chip... then let the other CPUs continue.
Best Wishes,
Lyle
On Wed, 18 Oct 2000, Alan Cox wrote:
> > spin_lock_irqsave(&local_lock, flags);
> > Muck_With_The_RTC_Chip();
> > spin_unlock_irqrestore(&local_lock, flags);
> > > This protects only the local procedure. In the meantime, somebody
> > else, using another CPU is mucking with the same RTC Chip. The
>
>You need to put the spinlock in for every other use of the chip
>
I can't control somebody else's use of `hwclock` or even some future
kernel module.
> > the data register. The "somebody else" is a realtime-clock ISR.
>
>Thata fine. You can compute worst case accesses for your Muck_with_..
>
>Alan
>
Hmmm. Care to explain? What I am expected to do is to make a log
entry showing the time at which a system crashed (if it crashed).
The log entry must be time-stamped within one second of the crash
time. This is so the customer can correlate this event with some
other events such as a power failure, etc.
This seems 'impossible' but it's not. Even though the machine is
dead (power is lost), it can retain information that will allow
the previously described specification to be met.
What I do is have a daemon which wakes up at 1 second intervals
and writes 'time_t' to a spare group of CMOS registers and then
re-checksums the CMOS. If the normal shutdown occurs, this value
is set to 0L and the CMOS is re-checksummed.
Access to the realtime clock is made through an installed module
driver with appropriate locking.
Upon startup, the system time is set to the stored CMOS time value
if it is non-zero. The appropriate log entries are made, then the
system time is set to the real CMOS clock time before the usual startup
log entries are made. So, even though the crash occurred several
days ago (the system crashed on a weekend), the log entries show,
within a second, the time at which the actual crash occurred.
It is 'impressive' to hit the power switch of a server and, upon
reboot, see the actual time at which the power was lost in a log
file.
Oct 12 10:35:29 chaos monitor[11]: Power failure
This all runs fine except when a SMP machine is used that has
the RTC interrupt enabled for time-keeping. Since I can't control
all the applications that a user might run on this server, I need
to disable all access to that chip during the time that I am
using it.
Currently, I cache any contents of command and status register 'B',
disable any periodic interrupt, do my thing, then put it back. However,
although this 'seems' to work, there is still room for a race because
these things can't be done simultaneously. What I really need is
a way of (effectively) disabling all interrupts. I note that the
common interrupt code could (but does not) contain a semaphore that
could be used to cause a spin when some driver needs all interrupts
disabled.
This might be very useful for problems like this.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:14 EST