[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #24158 [Core Tor/Tor]: I get this error "Looks like our kernel doesn't have the support for KIST anymore." on my relay



#24158: I get this error "Looks like our kernel doesn't have the support for KIST
anymore." on my relay
---------------------------+------------------------------------
 Reporter:  Dbryrtfbcbhgf  |          Owner:  (none)
     Type:  defect         |         Status:  needs_revision
 Priority:  Medium         |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  tor-sched      |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+------------------------------------
Changes (by dgoulet):

 * status:  new => needs_revision


Comment:

 @Dbryrtfbcbhgf: The notice shouldn't be logged more than once after KIST
 has been disabled. So if this log is being seen over and over (probably at
 each consensus), we have a bug. Are you seeing it constantly? If yes, what
 time rate?

 {{{
 [notice] Looks like our kernel doesn't have the support for KIST anymore.
 We will fallback to the naive approach. Remove KIST from the Schedulers
 list to disable.
 }}}

 `kist_no_kernel_support` is set to 1 in the case of no support for KIST so
 the fallback is KISTLite. That notice can't be logged after that unless
 that value changes back to 0 which it doesn't unless tor restarts.

 I think that notice will be logged each time the conf changed or new
 consensus while having KIST disabled by no kernel support. We should
 probably log it once and only once.

 {{{
         log_notice(LD_SCHED, "Scheduler type KIST has been disabled by "
                              "the consensus or no kernel support.");
 }}}

 With regards of logging the change even though the user never specified
 anything in `Schedulers`, I do think we should keep it because KIST is a
 default and if there was a fallback, user should get informed. This is
 especially important on non-Linux system where KIST is not supported which
 informs of the choice of Tor at startup. But it shouldn't be that loud
 especially after bootstrap.

 @pastly: The man page change lgtm *except* that I wouldn't put `and
 doesn't prioritize very well`. It is good to be honest but then also it is
 kind of weird to document how shitty it is in the manual page but still
 offer the option :P.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24158#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs