Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4.7, 10.4.8, 10.4.9, 10.4.10, 10.4.11, 10.4.12, 10.5.0, 10.5.1, 10.4.13, 10.5.4, 10.5.2, 10.5.3
-
FreeBSD, aarch64
Description
The commit that handles MDEV-19845 makes a mention in the commit message about how it may lead to runtime failures on ARM systems. In trying to use both the 10.4 line and 10.5 line of MariaDB on a Raspberry Pi 3 running FreeBSD, which uses an ARM Cortex-A53 processor, I am running into just that runtime failure. As it says in the subject line, I get a SIGILL when MariaDB tries to call __builtin_readcyclecounter. The easiest fix for this would be to add a preprocessor condition to the check for the builtin's availability for it to not be used when __arm__ is defined. And example of this can be found here.
Attachments
Issue Links
- blocks
-
MDEV-15952 SQL Server linked server to MariaDB - getting error 7303
-
- Closed
-
- is caused by
-
MDEV-19845 Adaptive spin loops
-
- Closed
-
- relates to
-
MDEV-21212 buf_page_get_gen -> buf_pool->stat.n_page_gets++ is a cpu waste (0.5-1%)
-
- Closed
-
I see that my_timer_cycles() is frequently called by the function get_rnd_value():
get_rnd_value()
{
}
so we have to have the plan B for the counter. */
#if !defined(_WIN32)
#else
LARGE_INTEGER cnt;
QueryPerformanceCounter(&cnt);
#endif /* !_WIN32 */
}
This function is used in sync_array_get() and in ib_counter_t::add() (which could be related to
MDEV-21212).Other callers of my_timer_cycles() outside server initialization are in:
It seems that returning 0 from my_timer_cycles() could cause reduced InnoDB scalability and useless results being returned by Exec_time_tracker.
krunalbauskar, can you check if the InnoDB code actually ‘works’ on the ARMv8 hardware that you have access to, possibly after applying pull request #1620?