> So people using normal hardware and good kernels with proper RTC > interrupts don't want to use --directisa. Setting it by default would > work everywhere, but with degraded functionality for the majority. > It would be a pity.
Where is the real problem, that it doesn't work for me without the --directisa? Is it a kernel problem, or a hardware problem? > - Make HWCLOCKPARS="--directisa" option easyier to find and setup. > Propose it during installation. Set it inside a simple config file, > sourced from /etc/init.d/hwclock.sh. See David's bug report #439593. Well, definitely /usr/share/doc/util-linux/README.Debian.hwclock needs to be updated, explaining the current situation and workarounds. This can be done immediatelly. > - Enhance detection of interrupt failures, and enhance automatic > fallback methods to detect tick in code. Today only few failure > scenarios are detected, some are detected too late, and the fallback > method (busywait for change of time) seems to be much less accurate than > with --directisa itself (busywait for UIP fall). Testing this fallback > method gave me the tick detected between 8 and 20 ms late, when normal > methods stay in a 10 µs range... That's only 2000 times worse. > > - Check interrupt failure during installation script, and then install > with --directisa option. Exactly this should be done - if the hwclock reports timeout, install directisa automatically. > But those are only random ideas: I can't test nor discuss this seriously, > because none of my machines have interrupt problems. However I think we > should not just fail, or poorly fallback. We should not require the > impacted users to notice, understand, and fix the problem. Instead, we > should detect and fix it ourselves. If not at runtime, then at install. Exactly. As I said, detect if hwclock works during install and fix it automatically if it doesn't. But maybe it's easier to fix the real problem, see my question above. Ondrej
