Bug 156608 - [RHEL3 U4] The system clock gains much time when netconle is activated.
[RHEL3 U4] The system clock gains much time when netconle is activated.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Anderson
Depends On:
Blocks: 156321
  Show dependency treegraph
Reported: 2005-05-02 10:01 EDT by Issue Tracker
Modified: 2010-10-21 22:57 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 11:01:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Issue Tracker 2005-05-02 10:01:01 EDT
Escalated to Bugzilla from IssueTracker
Comment 9 Dave Anderson 2005-05-02 17:04:50 EDT
Adding Jeff Moyer to cc: list in hopes he can help explain this one.

zap_completion_queue() is called in both the netconsole and netump
code paths AFAICT.  This code then, seemingly could wreak havoc,
i.e., the jiffies bump below (and what happens if they set idle_timeout?):

        if (idle_timeout) {
                if (t0) {
                        if (((t1 - t0) >> 20) > mhz_cycles * (unsigned long
long)idle_timeout) {
                                t0 = t1;
                                printk("netdump idle timeout - rebooting in 3
        /* maintain jiffies in a polling fashion, based on rdtsc. */
                static unsigned long long prev_tick;

                if (t1 - prev_tick >= jiffy_cycles) {
                        prev_tick += jiffy_cycles;

Since the code has always been like this, what am I missing?
Comment 10 Dave Anderson 2005-05-02 17:10:34 EDT
setting back to kernel...
Comment 11 Dave Anderson 2005-05-02 17:14:00 EDT
Jeff, looks like those two if statements need a netdump_mode check?
Comment 12 Dave Anderson 2005-05-03 08:50:40 EDT
The user-land mhz argument sent to the netconsole module is basically
ignored, unless, during module load, upon reading the tsc two successive
times with an mdelay() in between, it happens to have done so when the
tsc wrapped around:


In other works, if t1 > 0, mhz is completely ignored.  So let's put
that issue out of the picture.

The question is whether netconsole should be doing anything at all
with jiffies during runtime.  Doing an alt-sysrq-t operation with
thousands of processes, or simply repeated keyboard-generated attempts
(instead of echoing to /proc/sysrq-trigger), is essentially one huge
interrupt handler.  I don't know what the author's intent was -- to
"help" jiffies along, or whether it was meant to only do so in a netdump

What would happen say, if a 9600-baud serial console were hooked up,
without netconsole registered, where a single alt-sysrq-t on a system
with thousands of processes could consume several minutes?

It should also be kept in mind that alt-sysrq-t is a debug strategy,
not something that should be done in the normal course of events.
Furthermore, using /proc/sysrq-trigger does the operation in process
context so clock interrupts wouldn't be blocked.

Comment 13 Dave Anderson 2005-05-05 09:28:42 EDT
Ok, the fix will be to make this simple change to zap_completion_queue():

        /* maintain jiffies in a polling fashion, based on rdtsc. */
-       {
+       if (netdump_mode) {
                 static unsigned long long prev_tick;
                 if (t1 - prev_tick >= jiffy_cycles) {
                         prev_tick += jiffy_cycles;

Note that there is no way the idle_timeout check above it can cause a problem,
because t0 can never be set until a netdump operation is set in motion.

netconsole.c has no business mucking around with jiffies during runtime.
Comment 16 Dave Anderson 2005-05-13 14:54:44 EDT
Should be -- the patch will be posted in conjunction with BZ #157439,
which I'm waiting for IBM to test.
Comment 18 Ernie Petrides 2005-06-08 23:25:09 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.7.EL).
Comment 27 Red Hat Bugzilla 2005-09-28 11:01:29 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.