Bus error linux ошибка

Ошибки PCIe Bus Error при выключении Linux

После обновления Linux, при следующем выключении компьютера на экран повалилась куча одинаковых сообщений об ошибке: » pcieport 0000:00:1c.3: PCIe Bus Error: severity=Corrected, type=Physical Layer «. Причём длится это безобразие довольно долго, так что рука тянется принудительно выключить компьютер с кнопки, что я пару раз и проделал, пока не нашёл решения проблемы.

Как я уже сказал выше, выключение или перезагрузка компьютера стала адовой процедурой — лог повторяющихся ошибок бежал по экрану в течении (!) двух минут. Оказалось, что данная проблема постигла практически всех владельцев интеловских процессоров и, по всей видимости, связана с попытками понизить питание на порту PCIe. На тематических Linux-форумах предлагается добавить следующие два параметра при загрузке ядра:

pci = nomsi — отключает использование прерываний MSI;
pci = noaer — отключает расширенный отчёт об ошибках ядра.

Однако, возвращаться к использованию устаревших методов доставки прерываний мне совсем не хотелось — костыли, так себе. Решил пойти другим путём и просто отключить технологию ASPM (Active-State Power Management).

ASPM позволяет управлять энергопотреблением шин PCI Express (PCIe) посредством их перевода в энергосберегающий режим, если устройство не используются. В то же время, активация ASPM приводит к задержке ответа от устройств, так как требуется некоторое время на переключение режимов работы шины.

Поведением ASPM можно управлять, добавив параметр pcie_aspm в загрузчик или внеся изменения в файле /sys/module/pcie_aspm/parameters/policy (pcie_aspm=off отключает ASPM, а pcie_aspm=force принудительно задействует, даже на поддерживающих технологию устройствах). Я подправил загрузчик GRUB:

# открываем файл настроек grub в текстовом редакторе
sudo editor /etc/default/grub
# добавляем параметр pcie_aspm=off
GRUB_CMDLINE_LINUX_DEFAULT=»quiet pcie_aspm=off»
# сохраняем и обновляем загрузчик
sudo update-grub

В моём случае, ошибку выдавал встроенный Wi-Fi адаптер, который в принципе не отличался стабильностью в работе и постоянно отваливался. Отдельно отключить энергосбережение для WiFi поможет продвинутая консольная утилита для управления питанием TLP (/etc/default/tlp):

Подписывайтесь на канал Яндекс.Дзен и узнавайте первыми о новых материалах, опубликованных на сайте.

ЕСЛИ СЧИТАЕТЕ СТАТЬЮ ПОЛЕЗНОЙ,
НЕ ЛЕНИТЕСЬ СТАВИТЬ ЛАЙКИ И ДЕЛИТЬСЯ С ДРУЗЬЯМИ.

Источник

Arch Linux

You are not logged in.

#1 2015-06-07 00:46:22

svn Bus error (core dumped)

I can’t seem to get subversion to work. I just need the client utility (trying to set up an OpenWRT build environment). Most commands included with the package result in the terminal outputting «Bus error (core dumped)». I’ve tried to do some searching, but I haven’t come up with anything relevant.

#2 2015-06-07 05:49:49

Re: svn Bus error (core dumped)

Is there anything useful in the journal? Is your CPU an Intel one and if yes did you apply the microcode update? Can you also post the output of the following commands?

Last edited by mauritiusdadd (2015-06-07 05:50:08)

— When you have eliminated the impossible, whatever remains, however improbable, must be the truth — Spock | Sherlock Holmes

#3 2015-06-07 13:18:17

Re: svn Bus error (core dumped)

This machine was mothballed when the microcode changes happened, so that update had not been applied yet. Here’s some console output from the end of the microcode update, and my fresh attempts at running subversion.

I might need some more coffee, but I’m drawing a blank on journal output. I’m not sure what you’re looking for or how to get it.

#4 2015-06-07 14:58:26

Re: svn Bus error (core dumped)

That means your microcode update is not applied. a successful update looks like

Exactly what is your cpu? Is your system fully updated? Can you post the output of the following commands?

Also please read the wiki for further information on the microcode update: https://wiki.archlinux.org/index.php/Microcode.

I might need some more coffee, but I’m drawing a blank on journal output. I’m not sure what you’re looking for or how to get it.

Last edited by mauritiusdadd (2015-06-07 14:58:41)

— When you have eliminated the impossible, whatever remains, however improbable, must be the truth — Spock | Sherlock Holmes

#5 2015-06-07 17:58:28

Re: svn Bus error (core dumped)

Well, this thing is old, so there may not be any newer firmware.

It’s a Lenovo T60 type 2007-CTO, acquired in August 2006. It’s a 32-bit, non-SMT Centrino Duo. As of yesterday, it was fully updated.

I don’t seem to have stract. I’ll look into that and do some more reading on journalctl when I’m back at my computer later.

#6 2015-06-07 18:38:11

Re: svn Bus error (core dumped)

Well, this thing is old, so there may not be any newer firmware.

You’re right, you already have the last microcode available (which dates to 2005-11-15).

I don’t seem to have stract.

Oh, sorry, that is a typo. The actual command is

— When you have eliminated the impossible, whatever remains, however improbable, must be the truth — Spock | Sherlock Holmes

#7 2015-06-08 00:19:05

Re: svn Bus error (core dumped)

Okay, back at my computer. I guess I didn’t realize that journalctl kept tabs on damn near everything, and I just had to look for the relevant lines.

I installed strace, so here’s the output from that.

In that output I see complaints regarding libssl. I do have openssl installed.

Any further help is greatly appreciated.

#8 2015-06-08 05:24:30

Re: svn Bus error (core dumped)

The disk errors seems to be almost harmless (Here there is a related thread https://bbs.archlinux.org/viewtopic.php?id=190775).
Everything else seems ok. I think that the SIGBUS error is caused by an hardware failure: you should install and run memtest86+ and see if the RAM is damaged.

— When you have eliminated the impossible, whatever remains, however improbable, must be the truth — Spock | Sherlock Holmes

#9 2015-06-09 15:22:39

Re: svn Bus error (core dumped)

I let memtest86+ run for a few hours, and, wow. Lots of errors. All of them seemed to from one of the two DIMM’s, and most of those came when it was testing with core 1 (>300, as opposed to Offline

#10 2015-06-13 19:12:21

Re: svn Bus error (core dumped)

Finally got around to figuring out the hardware on this thing. I determined that one of the modules was faulty, but both slots are fine. So, running with just the one module, I ran a fresh pacman -Syu and tried again. Still no luck. Fresh strace output is as follows:

#11 2015-06-14 07:25:32

Re: svn Bus error (core dumped)

So it always fails when mprotect tries to use the address 0xb70a7dfb. The GNU C Library documentation says:

SIGBUS signals often result from dereferencing a misaligned pointer, such as referring to a four-word integer at an address not divisible by four.

It could just be a coincidence but from your strace, every address used by mprotect seems to be divisible by four execpt 0xb70a7dfb:

Can you please post the output of the following commands?

Can you also try to re-compile the svn package yourself on that machine using ABS and makepkg?
You do not have to download the whole ABS tree, just create a new folder (

/abs for example) and use the following command to download the PKGBUILD:

Actually in your first trace the address was 0xb709cdfb, but it also is not divisible by four.

Last edited by mauritiusdadd (2015-06-14 15:29:48)

— When you have eliminated the impossible, whatever remains, however improbable, must be the truth — Spock | Sherlock Holmes

Источник

Ошибка шины — Bus error

В вычислении , А ошибка шины является неисправность поднят с помощью аппаратных средств, уведомляя об операционной системе (ОС) , что процесс пытается получить доступ к памяти , что процессор не может физически адрес: недопустимый адрес для адресной шины , отсюда и название. При современном использовании на большинстве архитектур они гораздо реже, чем ошибки сегментации , которые возникают в основном из-за нарушений доступа к памяти: проблем с логическим адресом или разрешениями.

На платформах, совместимых с POSIX , ошибки шины обычно приводят к отправке сигнала SIGBUS процессу, вызвавшему ошибку. SIGBUS также может быть вызван любой общей ошибкой устройства, которую обнаруживает компьютер, хотя ошибка шины редко означает, что компьютерное оборудование физически сломано — обычно это вызвано ошибкой в программном обеспечении . Ошибки шины могут также возникать для некоторых других ошибок пейджинга; увидеть ниже.

Содержание

Причины

Есть как минимум три основных причины ошибок шины:

Несуществующий адрес

Программное обеспечение инструктирует ЦП читать или записывать определенный адрес физической памяти . Соответственно, ЦП устанавливает этот физический адрес на своей адресной шине и запрашивает все остальное оборудование, подключенное к ЦП, для ответа с результатами, если они отвечают на этот конкретный адрес. Если никакое другое оборудование не отвечает, ЦП вызывает исключение , заявляя, что запрошенный физический адрес не распознается всей компьютерной системой. Обратите внимание, что это касается только адресов физической памяти. Попытка получить доступ к неопределенному адресу виртуальной памяти обычно считается ошибкой сегментации, а не ошибкой шины, хотя, если MMU является отдельным, процессор не может заметить разницу.

Невыровненный доступ

Большинство процессоров имеют байтовую адресацию , где каждый уникальный адрес памяти относится к 8-битному байту . Большинство процессоров могут получить доступ к отдельным байтам из каждого адреса памяти, но обычно они не могут получить доступ к более крупным блокам (16 бит, 32 бита, 64 бита и т. Д.) Без того, чтобы эти блоки были » выровнены » по определенной границе ( платформа x86 является заметным исключением. ).

Например, если многобайтовый доступ должен быть выровнен по 16 битам, адреса (в байтах) 0, 2, 4, 6 и т. Д. Будут считаться выровненными и, следовательно, доступными, в то время как адреса 1, 3, 5 и так далее будет считаться невыровненным. Точно так же, если многобайтовый доступ должен быть выровнен по 32 бита, адреса 0, 4, 8, 12 и так далее будут считаться выровненными и, следовательно, доступными, а все адреса между ними будут считаться невыровненными. Попытка получить доступ к блоку размером больше байта по невыровненному адресу может вызвать ошибку шины.

Некоторые системы могут иметь их гибрид в зависимости от используемой архитектуры. Например, для оборудования на основе мэйнфрейма IBM System / 360 , включая IBM System z , Fujitsu B8000, RCA Spectra и UNIVAC Series 90 , инструкции должны находиться на 16-битной границе, то есть адреса выполнения должны начинаться с даже байт. Попытки перейти на нечетный адрес приводят к исключению спецификации. Однако данные могут быть получены с любого адреса в памяти и могут быть одним байтом или больше в зависимости от инструкции.

Обычно процессоры всегда обращаются к данным по всей ширине шины данных . Для адресации байтов они обращаются к памяти по всей ширине своей шины данных, затем маскируют и сдвигают для адресации отдельного байта. Системы терпимо относятся к этому неэффективному алгоритму, поскольку это важная функция для большинства программ, особенно для обработки строк . В отличие от байтов, блоки большего размера могут охватывать два выровненных адреса и, таким образом, потребуют более одной выборки по шине данных. ЦП может поддерживать это, но эта функция редко требуется непосредственно на уровне машинного кода , поэтому разработчики ЦП обычно избегают ее реализации и вместо этого выдают ошибки шины для доступа к невыровненной памяти.

Ошибки подкачки

FreeBSD , Linux и Solaris могут сигнализировать об ошибке шины, когда страницы виртуальной памяти не могут быть выгружены , например, потому что она исчезла (например, доступ к файлу с отображением памяти или выполнение двоичного образа, который был усечен во время работы программы), или потому что только что созданный файл с отображением памяти не может быть физически выделен, потому что диск заполнен.

Отсутствующий сегмент (x86)

На x86 существует более старый механизм управления памятью, известный как сегментация . Если приложение загружает регистр сегмента с помощью селектора отсутствующего сегмента (что в POSIX-совместимых операционных системах может быть выполнено только на языке ассемблера ), генерируется исключение. Некоторые операционные системы использовали это для свопинга, но в Linux это генерирует SIGBUS.

пример

Это пример невыровненного доступа к памяти, написанный на языке программирования C с синтаксисом ассемблера AT&T .

Компиляция и запуск примера в POSIX- совместимой ОС на x86 демонстрирует ошибку:

В GDB отладчик показывает , что непосредственное значение 0x2a в настоящее время хранятся в местоположении , хранящейся в EAX регистр , используя X86 язык ассемблера . Это пример косвенной адресации регистров .

Печать младших битов адреса показывает, что он не выровнен по границе слова («двойное слово» в терминологии x86).

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Ошибка на шине (Операционные Системы)

Ошибка на шине (bus error)- это ошибка, которая была вызвана аппаратным обеспечением, уведомляющим операционную систему о том , что процесс пытается получить доступ к памяти, которую процессор не может физически адресовать из-за того, что у адресной шины недопустимый адрес, а следовательно, и имя. В современном использовании на большинстве архитектур они встречаются гораздо реже , чем ошибки сегментации, которые возникают в основном из-за нарушений доступа к памяти: проблем с логическим адресом или разрешениями. На платформах, совместимых с портативным интерфейсом операционной системы( POSIX), ошибки шины обычно приводят к тому, что сигнал SIGBUS, который сигнализирует об ошибке шины, при обращении к физической памяти, передается процессу, который вызвал ошибку. SIGBUS также может быть вызван любой общей неисправностью устройства, которую обнаруживает компьютер, хотя ошибка шины редко означает, что компьютерное оборудование физически сломано, в основном это вызвано ошибкой в программном обеспечении.

Содержание

Причины возникновения

Существует 4 основных причины возникновения данной ошибки. Рассмотрим каждую из них.

Недействующий адрес

Программное обеспечение указывает процессору на чтение или запись определенного адреса физической памяти . Соответственно, центральный процессор устанавливает этот физический адрес на своей адресной шине и запрашивает все другое оборудование, подключенное к нему, чтобы ответить с результатами, если они отвечают за этот конкретный адрес. Если никакое другое оборудование не отвечает, центральный процессор вызывает исключение, указывающее, что запрошенный физический адрес не распознан всей компьютерной системой. Состоит отметить, что это касается только физических адресов памяти. Попытка доступа к неопределенному адресу виртуальной памяти обычно считается ошибкой сегментации, а не ошибкой шины, хотя если блок управления памятью (MMU) является отдельным, процессор не может определить разницу.

Несогласованный доступ

В основном центральные процессоры (CPU) являются байт-адресуемыми, где каждый уникальный адрес памяти ссылается на 8-битный байт . Большинство из них могут получить доступ к отдельным байтам из каждого адреса памяти, но они, как правило, не могут получить доступ к более крупным блокам (16 бит, 32 бит, 64 бит и т. д.) без «выравнивания» структуры данных этих блоков к определенной границе. К примеру, если многобайтовый доступ должен быть 16-битным, адреса (заданные в байтах) в 0, 2, 4, 6 и так далее будут считаться выровненными и, следовательно, доступными, в то время как адреса 1, 3, 5 и так далее будут считаться не выровненными. Аналогично, если многобайтовый доступ должен быть 32-разрядным, адреса 0, 4, 8, 12 и так далее будут считаться выровненными и, следовательно, доступными, а все промежуточные адреса будут считаться не выровненными. Попытка получить доступ к блоку размером больше байта по не выровненному адресу может привести к ошибке шины. Некоторые системы могут быть смешанные в зависимости от используемой архитектуры. Например, для аппаратного обеспечения, основанного на мэйнфрейме IBM System/360 , включая IBM System z, Fujitsu B8000, RCA Spectra и UNIVAC Series 90 , инструкции должны находиться на 16-разрядной границе, то есть адреса выполнения должны начинаться с четного байта. Попытка ветвления на нечетный адрес приводит к исключению спецификации. Данные, однако, могут быть извлечены из любого адреса в памяти, и могут быть размером от одного байта или больше, в зависимости от инструкции. Процессоры, как правило, получают доступ к данным на всей ширине своей шины данных в любое время. Система связи , которая передает данные между компонентами внутри компьютера или между компьютерами.Шина это система связи , которая передает данные между компонентами внутри компьютера или между компьютерами. Чтобы обратиться к байтам, они обращаются к памяти на всей ширине своей шины данных, затем маскируют и сдвигают для обращения к отдельному байту. Системы терпят этот неэффективный алгоритм, так как он является неотъемлемой особенностью большинства программ, особенно обработки строк. В отличие от байтов, большие блоки могут охватывать два выровненных адреса и, таким образом, требуют более одной выборки на шине данных. Процессоры могут поддерживать эту функцию, но эта функциональность редко требуется непосредственно в машинном коде уровень, таким образом, проектировщики центрального процессора обычно избегают его реализации и вместо этого выдают ошибки шины для не выровненного доступа к памяти.

Ошибка страницы

Такие ОС как,FreeBSD, Linux и Solaris могут сигнализировать об ошибке шины, когда страницы виртуальной памяти не могут быть выгружены, например, потому, что она исчезла (например, доступ к файлу с отображением памяти или выполнение двоичного образа, который был усечен во время работы программы), или потому, что только что созданный файл с отображением памяти не может быть физически выделен, потому что диск заполнен.

Несуществующий сегмент(x86)

На x86(емейство архитектур наборов команд,основанных на микропроцессоре Intel 8086 ) существует старый механизм управления памятью, известный как сегментация. Если приложение загружает регистр сегмента с селектором несуществующего сегмента , генерируется исключение. Некоторые ОС использовали это для подкачки, но под Linux это генерирует SIGBUS.

Источник