Messages in this thread |  | | Date | Fri, 6 Sep 2002 08:06:48 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: Uptime timer-wrap |
| |
On Thu, 5 Sep 2002, Andreas Dilger wrote:
> On Sep 05, 2002 16:16 -0400, Richard B. Johnson wrote: > > I tried to simulate your observation by making a driver that > > set the 'jiffies' count upon an 'open'. The idea was to get > > the jiffies count to something close to wrap so I didn't have to > > wait a long time. > > > > Anyway, I found that setting the jiffies count to more than a > > few hundred counts into the future, causes the machine to halt > > with no interrupts (no Capslock, no NumLock, no network ping, etc). > > > > The machine just stops and I don't understand why. > > > > > > spin_lock_irqsave(&xlock, flags); > > jiffies += 0x1000; > > spin_lock_irqrestore(&xlock, flags); > > > > ... works just fine, but, changing 0x1000 to 0x7fffffff causes > > the machine to stop as reported. > > > > Does anybody have a clue? > > Yes, because now some kernel code is going to wait 147 days - 1s > or something like that to finish. >
Yes. And isn't this a bug? I fear some code is waiting for some hardware timer value with the interrupts disabled. Since the CPU(s) are not the only user's of I/O (bus-masters), they may miss completely whatever they are spinning for. This could be the reason many machines simply "stop", could it not?
Do you have an idea where to look? I need to prevent the possibility of waiting forever for an event that may never occur, with interrupts disabled, on at least one embedded system. Any wait-forever possibility must be interruptible because any watch-dog timer that re-boots will end up destroying data that must never be lost.
Cheers, Dick Johnson Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). The US military has given us many words, FUBAR, SNAFU, now ENRON. Yes, top management were graduates of West Point and Annapolis.
- 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/
|  |