Идентификация кода из предупреждения в журнале ядра
При загрузке моего ядра Linux я получаю файл журнала, как это, что вызывает это и как решить..?
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:1423 0xa02147ab()
Modules linked in:
Backtrace: no frame pointer
---[ end trace ccc3de96c2b87179 ]---
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:1423 0xa02147ab()
Modules linked in:
Backtrace: no frame pointer
---[ end trace ccc3de96c2b8717a ]---
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:1423 0xa02147ab()
Modules linked in:
Backtrace: no frame pointer
---[ end trace ccc3de96c2b8717b ]---
ds3232 0-0068: rtc core: registered ds3232 as rtc0
i2c-gpio i2c-gpio.0: using pins 27 (SDA) and 28 (SCL)
1 ответ
Обратите особое внимание на следующую строку в журнале ядра: WARNING: at drivers/gpio/gpiolib.c:1423 0xa02147ab()
Это означает, что эта печать запускается из номера строки 1423
файла drivers/gpio/gpiolib.c
WARN_ON()
запускается из драйверов /gpio/gpiolib.c:1423 в ядре Linux.
int __gpio_get_value(unsigned gpio)
{
struct gpio_chip *chip;
chip = gpio_to_chip(gpio);
WARN_ON(extra_checks && chip->can_sleep);
return chip->get ? chip->get(chip, gpio - chip->base) : 0;
}
ПРИМЕЧАНИЕ. Код выше (v2.6.33 для arch=x86). Прежде чем приступить к приведенному выше анализу, убедитесь, что вы действительно используете Linux Kernel v2.6.33 на оборудовании x86. Номера строк меняются в зависимости от версии ядра. Вы могли случайно натолкнуться на WARN_ON()
в другой функции в той же строке в другой версии ядра.
Обновление:
Так как эта проблема возникает во время связи с периферийным устройством RTC-DS3232 (в остальном работает нормально), мы можем отключить предупреждения.
Один из способов сделать это - отключить CONFIG_DEBUG
в конфигурации сборки ядра Linux. Это в свою очередь отключает extra_checks
в драйвере GPIO.
Поочередно можно переопределить определение extra_checks
в драйверах /gpio/gpiolib.c:34 следующим образом
/* When debugging, extend minimal trust to callers and platform code.
* Also emit diagnostic messages that may help initial bringup, when
* board setup or driver bugs are most common.
*
* Otherwise, minimize overhead in what may be bitbanging codepaths.
*/
#ifdef DEBUG
#define extra_checks 1
#else
#define extra_checks 0
#endif
/* override extra_checks irrespective of debug-mode */
#define extra_checks 0