345590 |
27-Mar-2019 |
wulf |
MFC: r344982, r345022
atrtc(4): install ACPI RTC/CMOS operation region handler
FreeBSD base system does not provide an ACPI handler for the PC/AT RTC/CMOS device with PnP ID PNP0B00; on some HP laptops, the absence of this handler causes suspend/resume and poweroff(8) to hang or fail [1], [2]. On these laptops EC _REG method queries the RTC date/time registers via ACPI before suspending/powering off. The handler should be registered before acpi_ec driver is loaded.
This change adds handler to access CMOS RTC operation region described in section 9.15 of ACPI-6.2 specification [3]. It is installed only for ACPI version of atrtc(4) so it should not affect old ACPI-less i386 systems.
It is possible to disable the handler with loader tunable: debug.acpi.disabled=atrtc
Informational debugging printf can be enabled by setting hw.acpi.verbose=1 in loader.conf
[1] https://wiki.freebsd.org/Laptops/HP_Envy_6Z-1100 [2] https://wiki.freebsd.org/Laptops/HP_Notebook_15-af104ur [3] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf
PR: 207419, 213039 Submitted by: Anthony Jenkins <Scoobi_doo@yahoo.com> Reviewed by: ian Discussed on: acpi@, 2013-2015, several threads Differential Revision: https://reviews.freebsd.org/D19314 |
340016 |
01-Nov-2018 |
jhb |
MFC 338360,338415,338624,338630,338631,338725: Dynamic x86 IRQ layout.
338360: Dynamically allocate IRQ ranges on x86.
Previously, x86 used static ranges of IRQ values for different types of I/O interrupts. Interrupt pins on I/O APICs and 8259A PICs used IRQ values from 0 to 254. MSI interrupts used a compile-time-defined range starting at 256, and Xen event channels used a compile-time-defined range after MSI. Some recent systems have more than 255 I/O APIC interrupt pins which resulted in those IRQ values overflowing into the MSI range triggering an assertion failure.
Replace statically assigned ranges with dynamic ranges. Do a single pass computing the sizes of the IRQ ranges (PICs, MSI, Xen) to determine the total number of IRQs required. Allocate the interrupt source and interrupt count arrays dynamically once this pass has completed. To minimize runtime complexity these arrays are only sized once during bootup. The PIC range is determined by the PICs present in the system. The MSI and Xen ranges continue to use a fixed size, though this does make it possible to turn the MSI range size into a tunable in the future.
As a result, various places are updated to use dynamic limits instead of constants. In addition, the vmstat(8) utility has been taught to understand that some kernels may treat 'intrcnt' and 'intrnames' as pointers rather than arrays when extracting interrupt stats from a crashdump. This is determined by the presence (vs absence) of a global 'nintrcnt' symbol.
This change reverts r189404 which worked around a buggy BIOS which enumerated an I/O APIC twice (using the same memory mapped address for both entries but using an IRQ base of 256 for one entry and a valid IRQ base for the second entry). Making the "base" of MSI IRQ values dynamic avoids the panic that r189404 worked around, and there may now be valid I/O APICs with an IRQ base above 256 which this workaround would incorrectly skip.
If in the future the issue reported in PR 130483 reoccurs, we will have to add a pass over the I/O APIC entries in the MADT to detect duplicates using the memory mapped address and use some strategy to choose the "correct" one.
While here, reserve room in intrcnts for the Hyper-V counters.
338415: Fix build of x86 UP kernels after dynamic IRQ changes in r338360.
338624: msi: remove the check that interrupt sources have been added
When running as a specific type of Xen guest the hypervisor won't provide any emulated IO-APICs or legacy PICs at all, thus hitting the following assert in the MSI code:
panic: Assertion num_io_irqs > 0 failed at /usr/src/sys/x86/x86/msi.c:334 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff826ffa70 vpanic() at vpanic+0x1a3/frame 0xffffffff826ffad0 panic() at panic+0x43/frame 0xffffffff826ffb30 msi_init() at msi_init+0xed/frame 0xffffffff826ffb40 apic_setup_io() at apic_setup_io+0x72/frame 0xffffffff826ffb50 mi_startup() at mi_startup+0x118/frame 0xffffffff826ffb70 start_kernel() at start_kernel+0x10
Fix this by removing the assert in the MSI code, since it's possible to get to the MSI initialization without having registered any other interrupt sources.
338630: lapic: skip setting intrcnt if lapic is not present
Instead of panicking. Legacy PVH mode doesn't provide a lapic, and since native_lapic_intrcnt is called unconditionally this would cause the assert to trigger. Change the assert into a continue in order to take into account the possibility of systems without a lapic.
338631: xen: legacy PVH fixes for the new interrupt count
Register interrupts using the PIC pic_register_sources method instead of doing it in apic_setup_io. This is now required, since the internal interrupt structures are not yet setup when calling apic_setup_io.
338725: Fix a regression in r338360 when booting an x86 machine without APIC.
The atpic_register_sources callback tries to avoid registering interrupt sources that would collide with an I/O APIC. However, the previous implementation was failing to register IRQs 8-15 since the slave PIC saw valid IRQs from the master and assumed an I/O APIC was present. To fix, go back to registering all 8259A interrupt sources in one loop when the master's register_sources method is invoked.
PR: 229429, 130483, 231291 |
339928 |
30-Oct-2018 |
jhb |
MFC 338148: Remove 'imen' global variable from atpic(4).
In pre-SMPng, the global 'imen' was used to track mask state of the hardware interrupts and was aligned to the masks used by spl*(). When the atpic code was converted to using the x86 interrupt source abstraction, the global 'imen' was preserved by having each PIC instance point to an individual byte in the global 'imen' to hold its 8-bit interrupt mask. The global 'imen' is no longer used for anything however, so rather than storing pointers in 'struct atpic', just store the individual 8-bit mask for each PIC as a char.
While here, convert the ATPIC macro to using C99 initializers. |
331521 |
25-Mar-2018 |
ian |
MFC r330773, r330778, r330782, r330797
r330773: Use separate mutexes for atrtc and i8254 locking. Change all the strange un-function-like RTC_LOCK/UNLOCK macro usage into normal function calls. Since there is no longer any need to handle register access from a debugger context, those function calls can just be regular mutex lock/unlock calls.
Requested by: bde
r330778: Everywhere that multiple registers are accessed in sequence, lock/unlock just once around the whole group of accesses.
r330782: Remove MTX_NOPROFILE from atrtc_lock, it was inappropriately copy/pasted from the i8254 driver when I created separate mutexes for each. The i8254 driver could be the active timecounter, leading to recursion during mutex profiling, but the atrtc driver cannot be a timecounter, so it isn't needed.
r330797: Give the atrtc_time_lock a unique name.
Reported by: hps@ |
331503 |
24-Mar-2018 |
ian |
MFC r325233, r328956, r329170, r329172-r329173, r329224, r330403-r330407, r330411-r330412, r330416, r330430-r330431, r330433, r330528-r330529, r330767
r325233: [i2c/clock] add support for EPSON RTC-8583
RTC-8583 is time-of-day clock used in some SOHO routers. This clock has only 2 bits for year values, but thanks to user SRAM it's possible to save year value and keep it up to date via driver code.
Tested on Planex_MZK-W300NAG (SoC is RT2880)
Submitted by: Hiroki Mori <yamori83@yahoo.co.jp> Differential Revision: https://reviews.freebsd.org/D12833
r328956: Use const pointers for input data not modified by clock utility functions.
r329170: Replace the existing print_ct() private debugging function with a set of three public functions to format and print the three major data structures used by realtime clock drivers (clocktime, bcd_clocktime, and timespec).
r329172: Add a set of convenience routines for RTC drivers to use for debug output, and a debug.clock_show_io sysctl to control debugging output.
r329173: Add a new sysctl, debug.clock_do_io, to allow manully triggering a one-shot read or write of all registered realtime clocks. In the read case, the values read are simply discarded. For writes, there's no alternative but to actually write the current system time to the device.
r329224: Fix bad indentation. Whitespace only, no functional changes.
Reported by: bde@
r330403: Add calls to the new clock_dbgprint_xxx() functions.
r330404: Add calls to the new clock_dbgprint_xxx() functions.
r330405: Oops, fix a paste-o.
r330406: Add calls to the new clock_dbgprint_xxx() functions.
r330407: Add calls to the new clock_dbgprint_xxx() functions. Also, stop applying a local .5 second adjustment to the time, since that is now done by the code in subr_rtc.c.
r330411: Convert to the new(ish) bcd_clocktime conversion functions, add calls to the new debug output functions, and when setting the clock, propagate the timespec nsecs to the 1/100ths register.
r330412: Build iicbus/rtc8583 as a module.
r330416: The year is stored in a single byte in sram, in binary format, as a count of years since the century, so strip the century out when converting to or from bcd_clocktime format (the conversion routines will infer century by pivoting on 70).
r330430: Switch to the new bcd_clocktime conversion routines, and add calls to the new clock_dbgprint_xxx() functions.
r330431: Switch to the new bcd_clocktime conversion routines, and add calls to the new clock_dbgprint_xxx() functions.
r330433: Switch to the new bcd_clocktime conversion routines, and add calls to the new clock_dbgprint_xxx() functions.
r330528: Fix a paste-o that broke the build. There is no softc pointer here, just use the dev arg.
Reported by: Jonathan Looney <jonlooney@gmail.com> Pointy hat: ian@
r330529: Build the ds1672 driver as a module. Add a detach() to unregister the rtc.
r330767: Convert atrtc the new style rtc debugging output. Remove the db show command handler which provided much the same information. Removing the possibility of accessing the hardware regs from the debugger context paves the way for simplifying the locking code in the driver. |
331496 |
24-Mar-2018 |
ian |
MFC r306288, r314936, r325527, r327971, r328005, r328039, r328068-r328069, r328301-r328303
r306288: Fix ds1307 probing
'compat' can never be NULL, because the compatible check loop ends when compat->ocd_str is NULL. This causes ds1307 to attach to any unclaimed i2c device.
r314936: Validate values read from the RTC before trying BCD decoding
Submitted by: cem Reported by: Michael Gmelin <freebsd@grem.de> Tested by: Oleksandr Tymoshenko <gonzo@bluezbox.com> Sponsored by: Dell EMC
r325527: DS1307: Add the mcp7941x enable bit
Summary: Existing code recognizes the mcp7941x RTC, but this RTC has an enable bit at the same location as the "Clock Halt" bit on the ds1307, with an opposite assertion (set == on, whereas CH set == clock stopped). Thus the current code halts the clock, with no way to enable it.
Reviewed By: ian Differential Revision: https://reviews.freebsd.org/D12961
r327971: Add RTC clock conversions for BCD values, with non-panic validation.
RTC clock hardware frequently uses BCD numbers. Currently the low-level bcd2bin() and bin2bcd() functions will KASSERT if given out-of-range BCD values. Every RTC driver must implement its own code for validating the unreliable data coming from the hardware to avoid a potential kernel panic.
This change introduces two new functions, clock_bcd_to_ts() and clock_ts_to_bcd(). The former validates its inputs and returns EINVAL if any values are out of range. The latter guarantees the returned data will be valid BCD in a known format (4-digit years, etc).
A new bcd_clocktime structure is used with the new functions. It is similar to the original clocktime structure, but defines the fields holding BCD values as uint8_t (uint16_t for year), and adds a PM flag for handling hours using AM/PM mode.
PR: 224813 Differential Revision: https://reviews.freebsd.org/D13730 (no reviewers)
r328005: Convert the x86 RTC driver to use new validated BCD<->timespec conversions.
New common routines were added to kern/subr_clock.c for converting between calendrical time expressed in BCD and struct timespec. The new functions return EINVAL on error, as expected when the clock hardware does not provide valid time.
PR: 224813 Differential Revision: https://reviews.freebsd.org/D13731 (no reviewers)
r328039: Add static inline rtcin_locked() and rtcout_locked() functions for doing a related series of operations without doing a lock/unlock for each byte. Use them when reading and writing the entire set of time registers.
The original rtcin() and writertc() functions which do lock/unlock on each byte still exist, because they are public and called by outside code.
r328068: Move some code around and rename a couple variables; no functional changes.
The static atrtc_set() function was called only from clock_settime(), so just move its contents entirely into clock_settime() and delete atrtc_set().
Rename the struct bcd_clocktime variables from 'ct' to 'bct'. I had originally wanted to emphasize how identical the clocktime and bcd_clocktime structs were, but things evolved to the point where the structs are not at all identical anymore, so now emphasizing the difference seems better.
r328069: Remove redundant critical_enter/exit() calls. The block of code delimited by these calls is now protected by a spin mutex (obscured within the RTC_LOCK/RTC_UNLOCK macros).
Reported by: bde@
r328301: Switch to using the bcd_clocktime conversion functinos that validate the BCD data without panicking, and have common code for handling AM/PM mode.
r328302: Switch to using the bcd_clocktime conversion functions that validate the BCD data without panicking, and have common code for handling AM/PM mode.
r328303: Switch to using the bcd_clocktime conversion functions that validate the BCD data without panicking, and have common code for handling AM/PM mode. |
323472 |
11-Sep-2017 |
ian |
MFC r322411:
Stop calling atrtc_set() from the xen timer clock_settime() method. That removes the only reference to atrtc_set() from outside of atrtc.c, so make it static.
The xen timer driver registers as a realtime clock with 1us resolution. In the past that resulted in only the xen timer's clock_settime() getting called, so it would call atrtc_set() to set the hardware clock as well. As of r32090, the clock_settime() method of all registered realtime clocks gets called, so the xen driver no longer needs to chain-call the lower-resolution driver.
Thanks to royger@ for talking me through the xen stuff, and for testing. |
323447 |
11-Sep-2017 |
ian |
MFC r320901-r320902, r320996-r320997, r321002, r321048, r321400, r321743, r321745
r320901: Protect access to the AT realtime clock with its own mutex.
The mutex protecting access to the registered realtime clock should not be overloaded to protect access to the atrtc hardware, which might not even be the registered rtc. More importantly, the resettodr mutex needs to be eliminated to remove locking/sleeping restrictions on clock drivers, and that can't happen if MD code for amd64 depends on it. This change moves the protection into what's really being protected: access to the atrtc date and time registers.
This change also adds protection when the clock is accessed from xentimer_settime(), which bypasses the resettodr locking.
Differential Revision: https://reviews.freebsd.org/D11483
r320902: Support multiple realtime clocks, and remove locking/sleeping restrictions on clock drivers.
This tracks multiple concurrent realtime clock drivers in a list sorted by clock resolution. When system time changes (and periodically) the clock_settime() methods of all registered clocks are invoked.
To initialize system time, each driver is tried in turn from best to worst resolution, until one succesfully returns a valid time.
The code no longer holds a mutex while calling the clock_settime() and clock_gettime() methods of the registered clocks. This allows clock drivers to do whatever kind of locking or sleeping is necessary (this is especially important for i2c clock chips since i2c drivers often need to sleep).
A new clock_register_flags() function allows the clock driver to pass flags. The flags currently defined help support drivers that use their own techniques to avoid roundoff errors (prevents the 4/5 rounding done by the subr_rtc code). A driver which may need to wait for resources (such as bus ownership) may pass a flag to indicate that it will obtain system time for itself after waiting for resources; this is merely an optimization to avoid the common code retrieving a timespec that will never get used.
Relnotes: yes Differential Revision: https://reviews.freebsd.org/D11484
r320996: Allow setting debug.clocktime as a tunable. Print 64-bit time_t correctly on 32-bit systems.
r320997: Minor optimization: instead of converting between days and years using loops that start in 1970, assume most conversions are going to be for recent dates and use a precomputed number of days through the end of 2016.
r321002: Revert r320997. There are reports of it getting the wrong results, so clearly my testing was insuffficent, and it's best to just revert it until I get it straightened out.
r321048: Minor optimization: instead of converting between days and years using loops that start in 1970, assume most conversions are going to be for recent dates and use a precomputed number of days through the end of 2016.
This is a do-over of r320997, hopefully this time with 100% more workiness.
The first attempt had an off-by-one error, but instead of just adding another mysterious +1 adjustment, this rearranges the relationship between recent_base_year and recent_base_days so that the latter is the number of days that occurred before the start of the associated year (instead of the count thru the end of that year). This makes the recent_base stuff work more like the original loop logic that didn't need any +1 adjustments.
r321400: Add common code to support realtime clocks that store year without century.
Most realtime clocks store the year as 2 BCD digits. Some add a century bit to extend the range another hundred years. Every clock driver has its own code to determine the century and pass a full year value to clock_ct_to_ts(). Now clock drivers can just convert BCD to bin and store the result in the clocktime struct and let the common code figure out the century. Clocks with a century bit can just add 100 to year if the century bit is on.
r321743: Add taskqueue_enqueue_timeout_sbt(), because sometimes you want more control over the scheduling precision than 'ticks' can offer, and because sometimes you're already working with sbintime_t units and it's dumb to convert them to ticks just so they can get converted back to sbintime_t under the hood.
r321745: Add clock_schedule(), a feature that allows realtime clock drivers to request that their clock_settime() methods be called at a given offset from top-of-second. This adds a timeout_task to the rtc_instance so that each clock can be separately added to taskqueue_thread with the scheduling it prefers, instead of looping through all the clocks at once with a single task on taskqueue_thread. If a driver doesn't call clock_schedule() the default is the old behavior: clock_settime() is queued immediately. |
299746 |
14-May-2016 |
jhb |
Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot.
This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed.
This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs.
However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu.
Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case.
As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code.
These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling).
PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
|
295832 |
20-Feb-2016 |
jhibbits |
Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.
This simplifies checking for default resource range for bus_alloc_resource(), and improves readability.
This is part of, and related to, the migration of rman_res_t from u_long to uintmax_t.
Discussed with: jhb Suggested by: marcel
|
294883 |
27-Jan-2016 |
jhibbits |
Convert rman to use rman_res_t instead of u_long
Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of u_long.
Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI.
Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
|
273446 |
22-Oct-2014 |
marcel |
Virtual machines can easily have more than 16 option ROMs and when that happens, we happily access our resource array out of bounds. Make sure we stay within the MAX_ROMS limit. While here, bump MAX_ROMS from 16 to 32 to minimize the chance of leaving option ROMs unaccounted for.
Obtained from: Juniper Networks, Inc.
|
269675 |
07-Aug-2014 |
royger |
atpic: make sure atpic_init is called after IO APIC initialization
After r269510 the IO APIC and ATPIC initialization is done at the same order, which means atpic_init can be called before the IO APIC has been initalized. In that case the ATPIC will take over the interrupt sources, preventing the IO APIC from registering them.
Reported by: David Wolfskill <david@catwhisker.org> Tested by: David Wolfskill <david@catwhisker.org>, Trond Endrestøl <Trond.Endrestol@fagskolen.gjovik.no> Sponsored by: Citrix Systems R&D
|
255726 |
20-Sep-2013 |
gibbs |
Add support for suspend/resume/migration operations when running as a Xen PVHVM guest.
Submitted by: Roger Pau Monné Sponsored by: Citrix Systems R&D Reviewed by: gibbs Approved by: re (blanket Xen) MFC after: 2 weeks
sys/amd64/amd64/mp_machdep.c: sys/i386/i386/mp_machdep.c: - Make sure that are no MMU related IPIs pending on migration. - Reset pending IPI_BITMAP on resume. - Init vcpu_info on resume.
sys/amd64/include/intr_machdep.h: sys/i386/include/intr_machdep.h: sys/x86/acpica/acpi_wakeup.c: sys/x86/x86/intr_machdep.c: sys/x86/isa/atpic.c: sys/x86/x86/io_apic.c: sys/x86/x86/local_apic.c: - Add a "suspend_cancelled" parameter to pic_resume(). For the Xen PIC, restoration of interrupt services differs between the aborted suspend and normal resume cases, so we must provide this information.
sys/dev/acpica/acpi_timer.c: sys/dev/xen/timer/timer.c: sys/timetc.h: - Don't swap out "suspend safe" timers across a suspend/resume cycle. This includes the Xen PV and ACPI timers.
sys/dev/xen/control/control.c: - Perform proper suspend/resume process for PVHVM: - Suspend all APs before going into suspension, this allows us to reset the vcpu_info on resume for each AP. - Reset shared info page and callback on resume.
sys/dev/xen/timer/timer.c: - Implement suspend/resume support for the PV timer. Since FreeBSD doesn't perform a per-cpu resume of the timer, we need to call smp_rendezvous in order to correctly resume the timer on each CPU.
sys/dev/xen/xenpci/xenpci.c: - Don't reset the PCI interrupt on each suspend/resume.
sys/kern/subr_smp.c: - When suspending a PVHVM domain make sure there are no MMU IPIs in-flight, or we will get a lockup on resume due to the fact that pending event channels are not carried over on migration. - Implement a generic version of restart_cpus that can be used by suspended and stopped cpus.
sys/x86/xen/hvm.c: - Implement resume support for the hypercall page and shared info. - Clear vcpu_info so it can be reset by APs when resuming from suspension.
sys/dev/xen/xenpci/xenpci.c: sys/x86/xen/hvm.c: sys/x86/xen/xen_intr.c: - Support UP kernel configurations.
sys/x86/xen/xen_intr.c: - Properly rebind per-cpus VIRQs and IPIs on resume.
|
220433 |
07-Apr-2011 |
jkim |
Use atomic load & store for TSC frequency. It may be overkill for amd64 but safer for i386 because it can be easily over 4 GHz now. More worse, it can be easily changed by user with 'machdep.tsc_freq' tunable (directly) or cpufreq(4) (indirectly). Note it is intentionally not used in performance critical paths to avoid performance regression (but we should, in theory). Alternatively, we may add "virtual TSC" with lower frequency if maximum frequency overflows 32 bits (and ignore possible incoherency as we do now).
|
213918 |
16-Oct-2010 |
avg |
atrtc: remove (pre-)historic check of RTC NVRAM at address 0x0e
Old scrolls tell that once upon a time IBM AT BIOS was known to put some useful system diagnostic information into RTC NVRAM. It is not really known if and for how long PC BIOSes followed that convention, but I believe that many, if not all, modern BIOSes do not do that any more (not mentioning other types of x86 firmware). Some diagnostic bits don't even make any sense any longer. The check results in confusing messages upon boot on some systems. So I am removing it.
Discussed with: bde, jhb, mav MFC after: 3 weeks
|
212778 |
17-Sep-2010 |
mav |
Add one-shot mode support to attimer (i8254) event timer.
Unluckily, using one-shot mode is impossible, when same hardware used for time counting. Introduce new tunable hint.attimer.0.timecounter, setting which to 0 disables i8254 time counter and allows one-shot mode. Note, that on some systems there may be no other reliable enough time counters, so this tunable should be used with understanding.
|
209440 |
22-Jun-2010 |
mav |
Add "legacy route" support to HPET driver. When enabled, this mode makes HPET to steal IRQ0 from i8254 and IRQ8 from RTC timers. It can be suitable for HPETs without FSB interrupts support, as it gives them two unshared IRQs. It allows them to provide one per-CPU event timer on dual-CPU system, that should be suitable for further tickless kernels.
To enable it, such lines may be added to /boot/loader.conf: hint.atrtc.0.clock=0 hint.attimer.0.clock=0 hint.hpet.0.legacy_route=1
|
209371 |
20-Jun-2010 |
mav |
Implement new event timers infrastructure. It provides unified APIs for writing event timer drivers, for choosing best possible drivers by machine independent code and for operating them to supply kernel with hardclock(), statclock() and profclock() events in unified fashion on various hardware.
Infrastructure provides support for both per-CPU (independent for every CPU core) and global timers in periodic and one-shot modes. MI management code at this moment uses only periodic mode, but one-shot mode use planned for later, as part of tickless kernel project.
For this moment infrastructure used on i386 and amd64 architectures. Other archs are welcome to follow, while their current operation should not be affected.
This patch updates existing drivers (i8254, RTC and LAPIC) for the new order, and adds event timers support into the HPET driver. These drivers have different capabilities: LAPIC - per-CPU timer, supports periodic and one-shot operation, may freeze in C3 state, calibrated on first use, so may be not exactly precise. HPET - depending on hardware can work as per-CPU or global, supports periodic and one-shot operation, usually provides several event timers. i8254 - global, limited to periodic mode, because same hardware used also as time counter. RTC - global, supports only periodic mode, set of frequencies in Hz limited by powers of 2.
Depending on hardware capabilities, drivers preferred in following orders, either LAPIC, HPETs, i8254, RTC or HPETs, LAPIC, i8254, RTC. User may explicitly specify wanted timers via loader tunables or sysctls: kern.eventtimer.timer1 and kern.eventtimer.timer2. If requested driver is unavailable or unoperational, system will try to replace it. If no more timers available or "NONE" specified for second, system will operate using only one timer, multiplying it's frequency by few times and uing respective dividers to honor hz, stathz and profhz values, set during initial setup.
|
208494 |
24-May-2010 |
mav |
- Implement MI helper functions, dividing one or two timer interrupts with arbitrary frequencies into hardclock(), statclock() and profclock() calls. Same code with minor variations duplicated several times over the tree for different timer drivers and architectures. - Switch all x86 archs to new functions, simplifying the code and removing extra logic from timer drivers. Other archs are also welcome.
|
204641 |
03-Mar-2010 |
attilio |
Improving the clocks auto-tunning by firstly checking if the atrtc may be correctly initialized and just then assign to softclock/profclock. Right now, some atrtc seems reporting strange diagnostic error* making the current pattern bogus.
In order to do that cleanly, lapic_setup_clock(), on both ia32 and amd64, now accepts as arguments the desired sources to handle, and returns the actual ones (LAPIC_CLOCK_NONE is forbidden because otherwise there is no meaning in calling such function). This allows to bring out into commont x86 code the handling part for machdep.lapic_allclocks tunable, which is retained.
Sponsored by: Sandvine Incorporated Tested by: yongari, Richard Todd <rmtodd at ichotolot dot servalan dot com> MFC: 3 weeks X-MFC: r202387, 204309
|
204309 |
25-Feb-2010 |
attilio |
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98.
This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow.
Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
|