Platform first error handling bios

acm_fan:(да, автор, привет передаю — спасибо за спрятанную колонку со средним значением частот ядер)

а я тебе передать привет забыл… это ж ты мне говорил про SMU, что ничего не поделать , а это для тебя и Романа ответ реальность
средней колонки нет,но есть результат по синглу, который замеряется не за доли секунды, а за определенный отрезок времени (почти 10 минут в случае CB20)
у вас сударь висит HWBOT OC Team под ником , но тем не менее то «скрины слишком большие» то «эта всьо всплески»

_______

UPD к материалу

46.3 множитель будет в случае 3900Х если зашить мод SMU , а если сюда добавить BCLK то получается 4717 мгц для однопотока

спойлер

напряжение при этом не перелазит дефолт черту

Отправлено спустя 8 минут 18 секунд:

Vad1mk:1usmus, немного не по теме, можно ли таким же способом в HEX-редакторе вернуть pciex v4 со «старых» в более новые прошивки на б350 чипсете? Вчера смотрел вашу тему на ов.нет, где про редактирование, по идее если они просто скрыли такой вариант в менюхе то это изи, а вот если они вырезали то надо искать что и откуда они убрали
пс. надо будет самому сегодня чекнуть первый вариант со скрытием параметра.

буду откровенным — я не проверял где эти разделы находятся и насколько они спрятаны
сейчас первоочередная задача была показать где буст спрятался

Отправлено спустя 2 минуты 45 секунд:

daem0ns:
ээ может наоборот — драйвер чипсета ?

это пасхалка
p.s. мне приятно что читаете внимательно и полностью

Отправлено спустя 6 минут 12 секунд:

Megaclite:
Настолько задрали планки буста, что началась деградация
Надо было всем камням в спеках срезать по 100мгц, меньше бы вони было и никто бы не возмущался, да и это было бы честно.
А то этот буст на Zen2 — как неуловимый Джо

3900х 3,8/4,5
3800X 3,9/4,4
3700X 3,6/4,3
3600Х 3.8.4.3
3600 3.6/4.1

Возможно перестарались, а возможно эта беда из-за неверной заводской маркировки ядер, которая далека от совершенства и нагружаются те ядра, которые физически это не могут при этом качественные просто «массовка».
Должны быть некоторые подвижки с релизом 3950Х , но это в любом случае плохо и так не должно быть. Как некоторые камрады тут писали , если б это случилось у интел — их бы сожрали а тут такая серьезная поблажка и кредит ожидания доработки продукта. При чем кредит длинной в квартал

• #1

I have seen one other post from June 2020 address this issue but the resolution doesn’t seem to apply to my problem. I just built my first TrueNAS system with the components below. I have run three different tests and none confirm that ECC is actually working. The motherboard BIOS manual page 73 says BIOS should display an «ECC Support» option that can be enabled/disabled. ECC Support is not being displayed in either BIOS version 1.6 or 1.8, the latest BIOS. Supermicro support claims the manual is out of date, that «ECC Support» is no longer displayed in the BIOS, but ECC is enabled by default. However, the three tests I ran all show ECC capability but none confirm that ECC is actually working. The most explicit test was PassMark MemTest86 Pro v10.1 which supports ECC injection for this CPU. That test shows no ECC errors being caught and corrected each time an error is injected by the test; injection is occurring but no correction. A screenshot of intermediate test results and an explanation from PassMark are also shown below.

Does anyone have this motherboard with «ECC Support» showing in the BIOS displayed under Advanced/Chipset Configuration/System Agent (SA) Configuration/Memory Configuration/ECC Support? Does anyone know if this option is supposed to appear in BIOS v1.8? I suspect I have a motherboard or BIOS issue preventing ECC operation but Supermicro isn’t yet convinced. Does anyone have any other explanation for ECC not working with these components?

Selected System Components
Motherboard: Supermicro X11SCL-IF
CPU: Intel Xeon E-2234
RAM: Samsung 64GB (32×2) DDR4 2666
BIOS: v1.6 and v1.8 (I tested both)

PassMark MemTest86 Pro Test Results and Explanation

Test results:

ECC injection explanation from PassMark:
“If ECC errors were successfully injected and detected by the system, the user shall see an [ECC Inject] message followed by an [ECC Errors Detected] message. If [ECC Errors Detected] message does not appear, it is highly likely the ECC injection is locked or disabled by BIOS.”

Note that the [ECC Errors Detected] message would appear immediately after and under each [ECC Inject] message in the screenshot above. No errors are being detected, hence ECC detection is not functioning.

Community thoughts, anyone? Thank you!

• #2

At the very least I suggest that you ask Supermicro specifically if ECC injection is locked or disabled by the BIOS on your board.

Also, ask PassMark if you can send them a debug file so that they can indicate if ECC injection is locked or disabled by the BIOS on your board — they did so for me whan I pursued this topic a few years ago on my FreeNAS Mini’s ASROCK board (it was disabled in that case) see post #65 at https://www.truenas.com/community/threads/memory-error-on-freenas-mini.59216/page-4

• #3

The Pro version ends up being of dubious value because most vendors do not expose an option to unlock the IMC error injection capabilities, unfortunately.

• #4

At the very least I suggest that you ask Supermicro specifically if ECC injection is locked or disabled by the BIOS on your board.

Also, ask PassMark if you can send them a debug file so that they can indicate if ECC injection is locked or disabled by the BIOS on your board — they did so for me whan I pursued this topic a few years ago on my FreeNAS Mini’s ASROCK board (it was disabled in that case) see post #65 at https://www.truenas.com/community/threads/memory-error-on-freenas-mini.59216/page-4

Thanks. I’ve been communicating with Supermicro and am waiting for a reply but earlier they had said—to paraphrase—«don’t worry ECC is enabled in BIOS» but that doesn’t really answer the question you posed. I will follow up with them on this question.

I’m communicating with PassMark. They asked me for the log file and said it was in EFIBOOT of the USB flash drive but I ran the test through IPMI on a virtual drive image so I’m not sure I can access a log until I am able to run the test from a real USB drive on my device. I won’t have physical access to my system for a week or more. Will be following up with PassMark as soon as I get a log file.

• #5

The Pro version ends up being of dubious value because most vendors do not expose an option to unlock the IMC error injection capabilities, unfortunately.

PassMark does give a list of CPUs they say «may» support their ECC injection test, stating that these CPUs «may support this feature [ECC Injection] but may be disabled (depending on your BIOS configurations).» The list includes «Intel 8th/9th Gen Core/Xeon E-2100 family (Coffee Lake).» Of course, my CPU is a Xeon E-2234 (Coffee Lake) so I assume it «may» support ECC injection. There is no feature in the Supermicro BIOS to enable ECC injection tests.

PassMark provides this more complete explanation of ECC Injection testing and various motherboards. It kind of leaves me even more confused, especially the statement at the bottom about using IPMI on Supermicro motherboards.

How do I know if my system supports ECC injection?​

In general, ECC injection is not a feature that is normally accessible by end-users. Even if the chipset supports the ECC injection feature, details are often sparse and not described in publicly available datasheets. Consult the datasheet for your CPU/memory controller chipset to determine whether the ECC injection feature is available and fully specified.

In particular, some Intel chipsets (Broadwell, Xeon Scalable) use Intel Trusted Execution Technology (Intel TXT) to lock ECC injection. Intel TXT, using secure hardware modules, verifies the integrity of the BIOS, firmware, OS and hypervisor in order to guarantee a trusted operating environment. As a result, this requires preventing access to specific memory controller registers from being compromised, including ECC injection registers.

Some chipsets that support ECC injection have a locking mechanism that once enabled in the BIOS, effectively disables the ECC injection capability. For these cases, a BIOS option may be available to leave the feature unlocked. Otherwise, a custom BIOS is required for unlocking the feature.

Why are ECC errors not being reported on my AMD Ryzen system?​

There is a possibility that a BIOS setting, Platform First Error Handling (PFEH), is preventing ECC errors from being reported to MemTest86.

An example of this setting is shown in the following screenshot.

If this setting is enabled, set to disabled and try running MemTest86 again.

Another explanation is the use of out-of-band (OOB) monitoring solutions such as Baseboard Management Controller (BMC) and Intelligent Platform Management Interface (IPMI), which is used in server platforms (eg. Supermicro servers)

• #6

It kind of leaves me even more confused, especially the statement at the bottom about using IPMI on Supermicro motherboards.

The two topics are somewhat unrelated. You can still test for ECC correctable errors without injecting them — you might get lucky, or double-lucky and have a predictably-defective DIMM. IPMI logs will show memory errors, typically. The main exception is where vendors felt that their products needed a sprinkle of fascist naming conventions for a dumb anti-feature that benefits nobody and decided that «Platform-first error handling» was somehow not a terrible idea.

• #7

vendors felt that their products needed a sprinkle of fascist naming conventions for a dumb anti-feature that benefits nobody

That’s like the second time in the space of a week, @Ericloewe … STOP MAKING ME SPLORF MY DRINK. Or else!

• #8

The main exception is where vendors felt that their products needed a sprinkle of fascist naming conventions for a dumb anti-feature that benefits nobody and decided that «Platform-first error handling» was somehow not a terrible idea.

Hmmm… Can I coax you to expand on this some for my own edification? What does «platform-first error handling» imply?

• #9

If you get out your vendorese decoder ring, you’ll see that «platform», when not used to mean the literal platform (CPU, chipset and associated capabilities), means «system firmware».
So you need to turn around the ring and look at the compound words section, «-first» means «only works with».
In other words, «error handling only works with system firmware».

«Wait, what?», you might ask — «That doesn’t make any sense.». You’d be right, it doesn’t.

What’s going on here is that some idiot thought that they were seeing too many ECC correctable errors and that the solution was to suppress these errors from reaching the host OS or some relevant logs. Perhaps they desperately needed to dump a truckload of marginal DIMMs that would error out frequently, or they figured they could undercut someone, or fudge some requirement, or weasel out of warranties…

So, end result: Someone (likely at AMI, because I’ve heard of it both on AMD and Intel systems) implemented a hack that prevents ECC correctable errors from being reported and this «feature» has made its way into some systems. Worse, on some systems, it’s apparently not even shown as an option and always enabled. So you’ll end up with a system that all of a sudden has uncorrectable errors, despite you never having seen a single correctable error (which is a statistically dubious scenario if the latter are reported).

I first heard of this nonsense in this talk, where Bryan Cantrill describes a rather extreme scenario and discussions with an unnamed vendor. At the time of the talk, the slightly less opaque «firmware-first» terminology was in use.

• #10

Not reporting ECC correctable errors (a visual demonstration):

Last edited: Dec 28, 2022

• #11

In other words, «error handling only works with system firmware».

«Wait, what?», you might ask — «That doesn’t make any sense.». You’d be right, it doesn’t.

Thanks for taking the time — my non-decoder-ring inference was close enough to give me pause, that’s why I asked.

Введение в обработку ошибок в Swift 3

Сегодня мы приготовили перевод для тех, кто так же, как автор статьи, при изучении Документации языка программирования Swift избегает главы «Error Handling».

Из статьи вы узнаете:

• что такое оператор if-else и что с ним не так;
• как подружиться с Error Handling;
• когда стоит использовать Try! и Try?

Моя история

Когда я был младше, я начинал изучать документацию языка Swift. Я по несколько раз прочёл все главы, кроме одной: «Error Handling». Отчего-то мне казалось, что нужно быть профессиональным программистом, чтобы понять эту главу.

Я боялся обработки ошибок. Такие слова, как catch, try, throw и throws, казались бессмысленными. Они просто пугали. Неужели они не выглядят устрашающими для человека, который видит их в первый раз? Но не волнуйтесь, друзья мои. Я здесь, чтобы помочь вам.

Как я объяснил своей тринадцатилетней сестре, обработка ошибок – это всего лишь ещё один способ написать блок if-else для отправки сообщения об ошибке.

Сообщение об ошибке от Tesla Motors

Как вы наверняка знаете, у автомобилей Tesla есть функция автопилота. Но, если в работе машины по какой-либо причине происходит сбой, она просит вас взять руль в руки и сообщает об ошибке. В этом уроке мы узнаем, как выводить такое сообщение с помощью Error Handling.

Мы создадим программу, которая будет распознавать такие объекты, как светофоры на улицах. Для этого нужно знать как минимум машинное обучение, векторное исчисление, линейную алгебру, теорию вероятности и дискретную математику. Шутка.

Знакомство с оператором if-else

Чтобы максимально оценить Error Handling в Swift, давайте оглянемся в прошлое. Вот что многие, если не все, начинающие разработчики сделали бы, столкнувшись с сообщением об ошибке:

Самая большая проблема заключается в удобочитаемости кода, когда блок else становится слишком громоздким. Во-первых, вы не поймёте, содержит ли сама функция сообщение об ошибке, до тех пор, пока не прочитаете функцию от начала до конца или если не назовёте ее, например, selfDriveCanCauseError, что тоже сработает.

Смотрите, функция может убить водителя. Необходимо в недвусмысленных выражениях предупредить свою команду о том, что эта функция опасна и даже может быть смертельной, если невнимательно с ней обращаться.

С другой проблемой можно столкнуться при выполнении некоторых сложных функций или действий внутри блока else. Например:

Блок else раздувается, и работать с ним – все равно что пытаться играть в баскетбол в зимней одежде (по правде говоря, я так и делаю, так как в Корее достаточно холодно). Вы понимаете, о чём я? Это некрасиво и нечитабельно.

Поэтому вы просто могли бы добавить функцию в блок else вместо прямых вызовов.

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

Знакомство с Error Handling

К настоящему времени вы уже знаете о проблеме If-else с сообщениями об ошибках. Пример выше был слишком простым. Давайте предположим, что есть два сообщения об ошибке:

1. вы заблудились
2. аккумулятор автомобиля разряжается.

Я собираюсь создать enum, который соответствует протоколу Error.

Честно говоря, я точно не знаю, что делает Error протокол, но при обработке ошибок без этого не обойдешься. Это как: «Почему ноутбук включается, когда нажимаешь на кнопку? Почему экран телефона можно разблокировать, проведя по нему пальцем?»

Разработчики Swift так решили, и я не хочу задаваться вопросом об их мотивах. Я просто использую то, что они для нас сделали. Конечно, если вы хотите разобраться подробнее, вы можете загрузить программный код Swift и проанализировать его самостоятельно – то есть, по нашей аналогии, разобрать ноутбук или iPhone. Я же просто пропущу этот шаг.

Если вы запутались, потерпите еще несколько абзацев. Вы увидите, как все станет ясно, когда TeslaError превратится в функцию.

Давайте сперва отправим сообщение об ошибке без использования Error Handling.

Итак, если бы я запустил это:

Но давайте используем Error Handling. В первую очередь вы должны явно указать, что функция опасна и может выдавать ошибки. Мы добавим к функции ключевое слово throws.

Теперь функция автоматически говорит вашим товарищам по команде, что autoDriveTesla – особый случай, и им не нужно читать весь блок.

Звучит неплохо? Отлично, теперь пришло время выдавать эти ошибки, когда водитель сталкивается с lostGPA или lowBattery внутри блока Else-If. Помните про enum TeslaError?

Я вас всех поймаю

Если lostGPS равно true, то функция отправит TeslaError.lostGPS. Но что делать потом? Куда мы будем вставлять это сообщение об ошибке и добавлять код для блока else?

Окей, я не хочу заваливать вас информацией, поэтому давайте начнём с того, как выполнить функцию, когда в ней есть ключевое слово throws.

Так как это особый случай, вам необходимо добавлять try внутрь блока do при работе с этой функцией. Вы такие: «Что?». Просто последите за ходом моих мыслей ещё чуть-чуть.

Я знаю, что вы сейчас думаете: «Я очень хочу вывести на экран моё сообщение об ошибке, иначе водитель умрёт».

Итак, куда мы вставим это сообщение об ошибке? Мы знаем, что функция способна отправлять 2 возможных сообщения об ошибке:

1. TeslaError.lowBattery
2. TeslaError.lostGPS.

Когда функция выдаёт ошибку, вам необходимо её “поймать” и, как только вы это сделаете, вывести на экран соответствующее сообщение. Звучит немного запутанно, поэтому давайте посмотрим.

Теперь всё должно стать понятно. Если понятно не всё, вы всегда можете посмотреть моё видео на YouTube.

Обработка ошибок с Init

Обработка ошибок может применяться не только к функциям, но и тогда, когда вам нужно инициализировать объект. Допустим, если вы не задали имя курса, то нужно выдавать ошибку.

Если вы введёте tryUdemyCourse(name: «»), появится сообщение об ошибке.

Когда использовать Try! и Try?

Хорошо. Try используется только тогда, когда вы выполняете функцию/инициализацию внутри блока do-catch. Однако если у вас нет цели предупредить пользователя о том, что происходит, выводя сообщение об ошибке на экран, или как-то исправить ее, вам не нужен блок catch.

Давайте начнём с try? Хотя это не рекомендуется,

try? всегда возвращает опциональный объект, поэтому необходимо извлечь newCourse

Если метод init выбрасывает ошибку, как, например

то myCourse будет равен nil.

В отличие от try? оно возвращает не опциональное значение, а обычное. Например,

bobCourse не опционально. Однако, если при методе инициализации выдается ошибка вроде,

то приложение упадёт. Так же как и в случае с принудительным извлечением с помощью !, никогда не используйте его, если вы не уверены на 101% в том, что происходит.

Ну вот и всё. Теперь вы вместе со мной поняли концепцию Error Handling. Легко и просто! И не нужно становиться профессиональным программистом.

Источник

Platform UI Error Handling

This proposal is for error messages only. It does not include Log, trace or Application Life Cycle linked to errors in a software application. Yet, this proposal should fit very nicely in above mentioned features.

Contents

Use cases

We will use 4 different customers to ensure the proposal is scalable

• BigCompany is using Eclipse 3.3. They decide to buy different features from different companies. They want an AJAX feature from company AjaxWorldCom and they decide on a database tooling feature from SQLForever Company. All user will have the same desktop feature and all call should be routed to the BigCompany’s help desk. Users do not have access to the web.

• TaxInc develops an Tax Solution software. It has RCP clients and a server. TaxRUS bought the tax solution. They installed a server internally and deployed the RCP client to 250 employees around the world. The employees are not developers. They just use the RCP application to do Tax related tasks. They have an internal help desk.

• BigSoftware develops a set of Eclipse feature for a product named: J2EE development 13.0. User can buy the product off the shelf or order a large amount of products and install them in their enterprise. BigSoftware has a huge support center. BigSoftware also ships 3rd party features it supports in its tooling.

• John is a Java Perl developer. He downloaded Eclipse 3.3 and a Perl feature from the open source web site.

Issue to solve

This is the main issue to solve for the 4 customers

When an error occurs in the tooling (Error message, error dialog, error in the console view, error in the log view, error in the job dialog or any other error), Eclipse needs to provide a way for the users to:

• see what the error is
• understand what it means to the them
• how can they act on the error.

The behavior for each is based on policies.

• The feature who threw the error should have a chance to handle the error and help the customer.
• The feature should have an idea about what the error handler wants it to do.
  • i.e. when there is an error opening a view should we show the error view or not
  • also do we prompt when the workbench layout cannot be reset?
• The product/branding that is installed can override all feature’s behavior it ships and manage or delegate to them as appropriate.

See the error

It is very important to distinguish between expected and unexpected error.

• Expected Error is when a developer expects the exception to be thrown in particular situation (network not available, resource locked by another person, invalid license etc).
• Unexpected Error is an error that should not happen (internal error, NPE etc).

Generally expected errors should come with idea how to solve the problem, while it should be easy to report unexpected one and/or to get workaround.

When an error occurs, the developer may decide to show the error to the user. The code is opening an error dialog. However handler may ignore developer request and handle the error in different way, f.e. log it. Before opening the error dialog, and based on the policy, the flow can be re-routed and the error dialog may never show up like the developer intended to. There should be a hook in the code, based on policy that will express manage the behavior.

What does it mean to me the user?

Most users are not interested in the ‘stack trace’ of the error. When a user sees an error or actively double clicks on an error we ought to see the information on how to solve the error (without technological background). This presumes the feature or the product or the company provided the data the user can understand and that the associated policy allows such data to be shown.

What can I do next?

Based on the policy, it is the responsibility of the feature provider (component provider), the product provider or the company to decide what the ‘what to do next’ action will do. Eclipse could still provide a ‘show log’ button that policy provider can extend (this is a nice to have…)

Status manager & Status handlers

Status manager

StatusManager is the entry point for all statuses to be reported in the user interface. Handlers are not intended to be used directly. They should be referenced via the StatusManager which selects the handler corresponding to the product to apply. Right now it is impossible to have more than one handler per product because of scalability issues.

The following methods are the API entry points to the StatusManager

The StatusManager singleton is accessed using

The int parameter are for supplying style for handling. See Acceptable styles.

NOTE! the style is a suggestion and may not be honoured by the current handler. For instance a handler may choose to not show the user anything when the SHOW flag is sent. See Status handlers for more details.

The StatusManager gets it’s list of handlers from the extension point org.eclipse.ui.statusHandlers . Should none of those handlers process the status it will fall through to the default handler (the the SDk this is WorkbenchAdvisor#getWorkbenchErrorHandler() ). If a handler is associated with a product, it is used instead of this defined in advisor.

Styles

Below is a list of StatusManager styles which can be combined with logical OR.

• NONE — a style indicating that the status should not be acted on. This is used by objects such as log listeners that do not want to report a status twice
• LOG — a style indicating that the status should be logged only
• SHOW — a style indicating that handlers should show a problem to an user without blocking the calling method while awaiting user response. This is generally done using a non modal dialog
• BLOCK — a style indicating that the handling should block the calling method until the user has responded. This is generally done using a modal window such as a dialog

Status handlers

Status handlers are part of the status handling facility. The handlers are responsible for presenting statuses by logging or showing appropriate feedback to the user (generally dialogs). All status handlers extend org.eclipse.ui.statushandlers.AbstractStatusHandler which requires each handler to implement handle(StatusAdapter status, int style) . This method handles statuses based on a handling style. The style indicates how status handler should handle a status. See Acceptable styles.

There are two ways for adding handlers to the handling flow.

• using extension point org.eclipse.ui.statusHandlers
• by the workbench advisor and its method <@link WorkbenchAdvisor#getWorkbenchErrorHandler()>.

If a handler is associated with a product, it is used instead of this defined in advisor.

A status handler has the id and a set of parameters. The handler can use them during handling. If the handler is added as an extension, both are set during initialization of the handler using elements and attributes of statusHandler element.

WARNING! We have to take the extra action when something has to be logged using the default logging mechanism, because the facility is hooked into it. See Hooking the facility into Platform. For this special case the status manager provides API.

And below is the example of addLoggedStatus(IStatus status) proper usage.

StatusAdapter

The StatusAdapter wraps an instance of IStatus subclass and can hold additional information either by using properties or by adding a new adapter. Used during status handling process.

The facility and Platform

The places where the facility is hooked in

• WorkbenchAdvisor#eventLoopException(Throwable) — it handles all uncaught exceptions from main application loop
• Jobs framework
• Error log file (all logged messages are forwarded to the facility with the LOG style)
• Exceptions from opening a part (the error view and error editor)

Platform is still under refactoring aimed at introducing the status handling facility.

WARNING! The facility isn’t hooked into JFace ErrorDialog or MessageDialog in any way. The code has to be refactored if the facility is to be used.

should be refactored into

WorkbenchStatusHandler and IDEWorkbenchStatusHandler

There are two implementation of status handlers

• org.eclipse.ui.application.WorkbenchErrorHandler which is assigned to WorkbenchAdvisor
• org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler assigned to IDEWorkbenchAdvisor

The current advisor indicates which handler is the workbench one.

Error Messages: User Interface

Error Messages User Interface Use Cases

There are three types of user interfaces that will present a message, an error or a warning to a user. The three categories are

• Message that requires user’s action now
• Message that requires user’s action that can be done later
• List of messages.

Message that requires action now.

They are typically represented in a modal dialog box. The user has to act on it or he/she will not be able to finish the task. Such a dialog should provide a standard view with an icon and a message. The message can provide an advanced view, in which case a ‘details’ or ‘advanced’ button is present on the standard view. When the user selects the details button, the advanced information about the message are displayed. The provider of the message or the Error handler will provide the user interface that will be embedded in the dialog. The user can pres the details button again, and this will collapse the advanced view. Messages must be persisted in an external file. The message in the modal window is the most relevant to the user and is decided by the ErrorHandler. If the message has offspring, they will be rendered in the advanced user interface.

Message that can have action later.

They are messages that can be error, but do not prevent the user from pursuing his/her task. All message may need to be solved at a certain point, but do not require immediate action. They are usually represented by information and icon in the user interface. The user can finish some other part of the interface before solving the message. Concrete examples are wizard pages and editors. In wizard pages the message is presented at the top of the page, in an editor it is usually embedded in the form editor or on the side of the editor (right or left side) To get more information about the message, the user clicks on it. A modeless window opens with the information. When the user clicks elsewhere, the window closes. Messages do not have to be persistent. The owner of the user interface can decide to save them or decide to recalculate the messages when the user interface is reopened. The owner of the user interface can decide to not allow the task to be saved or finished if the message is not act upon.

The user is presented with a double pane view. One pane represents the list of messages. The user can filter them and reorganized them. Some filter could be based on the resources, the format (tree, table) or the dependency (ex: acting on this message will also resolve the following messages…). The filtering mechanism should be lighter in its usage than the current one. When the user selects a message, the second pane is filled with the details of the message. This will show the exact same information as #1. The messages are persistent. PS: the semantic of this user interface is like an ‘email reader’ where you select the email message to see the content of the email. A provider could replace the first pane of the list of errors. ErrorView and Problem view should be merged in a unique view.

Eclipse mapping

The user must act of them. The best practice is that only error message should appear to the user using this format. Warning and Information messages should not. The error handler can decide if a message is worth showing or not and will also provide the details.

Errors in a background process are of type 2.

We should not open a modal dialog when an issue occurs. The user can ‘glance’ in the result in the bottom right corner, click on it to see the list of errors and click on an error to see a detail.

Wizard messages are of type 1.

The user must act on them to go to the next page but also clicking on them will open a pop up. There is no ‘details’ button in the wizard user interface

Error log is of type 3

The view shows the different errors from the log. The user can click on an error in the list to see more details.

Use cases

The User Interface behavior will depend from the context of the error. If an error occurs during a Job, we will not prompt the user but rather notify the Job View. If the same error occurs in the plug-in itself, we will open a modal window.

The error manager framework must keep track of the context and if the error handler decides to show the error to the user, the Error Manager Framework should use the appropriate User Interface.

Context of the use cases

The plug-in is looking for a file named ‘result.txt’ on a web site. When executing, the plug-in is unable to connect to the web server. The plug-in throws an error using the error handler mechanism. The error is modified to notify the user that the remote site does not answer and that the user should check if there is any proxy of if the site is actually down.

Use Case 1 Modal Dialog

The framework realizes the context and opens an ErrorDialog. The ErrorDialog detail is filled with content from the plug-in error handler.

Use Case 2 Job Error

The framework realizes the context and modifies the user interface for the Job. A red ‘x’ appears in the bottom right hand corner of eclipse. The User double clicks on the red ‘x’ and a window opens, showing the message of the error. When the user clicks on the message; the framework opens a modal window like in use case #1.

Use Case 3 Wizard

The framework realizes the context and updates the top of the wizard with the message. When the user hovers over the message a pop up appears. If the user wants to see more details, a modal window opens.

Use Case 4 Error Log

The error handler decided to not show the user about the error. It decided to only log it. The error appears in the error log view. The user clicks on the entry and a modal dialog (like in #1) opens.

Main requirements

• shows list of the problems
• shows details of the problems
• shows view which helps user to handle or report the problems

Each problem on the list should have error reporting view associated to it. This relation can be set in error handler which handles the problem. This reporting view will be showed in the tray part of the dialog.

For workbench handler it can be simply a basic view with stack trace. For product handler it can be a html view with a form for registering the problem or for checking the state of the problem.

New StatusDialog

Overview

New Status Dialog is integrated with Status Handling facility. Unless no other handler is specified, the default dialog will be used.

• Message — This is the most important piece of information.
• Details — Sometimes there is not enough place to display all necessary info on the dialog, or we do not want to scary the user. Then we can place leading message on the dialog, and all other things make accessible via details area. Currently it is possible to set up one kind of details area provider, but there is no further requirement.
• Support — It is possible to place some contact form on the dialog, so the user will know where to look for help or will be able to easily contact vendor.

Support and Details are terms introduced to distinct the behavior and functionality although they extend common abstract class. One should remember that user expects more information after pressing «Details >>>» button.

Status Dialog uses following messages hierarchy:

• Job name (if available)
• StatusAdapter title
• IStatus message
• MultiStatus information (applies only if MultiStatus is handled).
• message extracted from exception
• exception name

Status Dialog displays always two the most important messages. If first one is not found then the dialog should give information about general error instead. If the second one is not found, dialog should point to the details.

• Only one status is handled
  • First message displayed is the most important message.
  • Second message displayed is the second most important message.
  • Timestamp is displayed in the details (if available)
• More statuses handled — the selection list appears
  • There is the most important message used on the selection list.
  • The second most important message is displayed right to the severity icon.
  • Timestamp (if available) is appended to the message in the selection list.

• Details area can be replaced — it does not display stack trace anymore, rather the error hierarchy (message from Status, Exception, Nested statuses, etc) by default. Product may decide to provide some high level description, or even retrieve description from database.
• Support area can be added — product may hook into the error dialog and place there f.e. browser with url pointing to the helpdesk, or some reporting mechanism.

The basic idea is that even unexperienced user should be able to understand what is going on while looking at details, and should be able to report/get help using support area.

• Only one status is reported. Primary message and secondary message should be displayed. Secondary message should have timestamp if one is available.

• Job reported an error. Display message informing which job, and primary message.

• Multiple errors occured. On the list should be displayed job name or primary message of the status. In the title primary message should appear for jobs and secondary for statuses.

• One stastus has been reported and support is available.

after pressing bug icon:

and many statuses. The selected in the list Status is a base for support area.

Use cases

Usage

Note for WorkbenchStatusDialog clients
Please note that WorkbenchStatusDialog#getPrimaryMessage & WorkbenchStatusDialog#getSecondaryMessage begin searching for the message from StatusAdapter title. It means that when we are handling job statuses we display:

• single status
  • job name as the first message
  • WorkbenchStatusDialog#getPrimaryMessage result as second message
• list
  • job name (and eventually timestamp) as the position on the list.
  • WorkbenchStatusDialog#getPrimaryMessage result right to the severity icon.

Источник

BIOS

Intel® Server Board SDS2

Revision 1.2

Order Number: A85874-002

36

•

OEM customization

•

PCI and Plug and Play (PnP) BIOS interface

•

Console redirection

•

Resource allocation support

6.2 BIOS Error Handling

This section defines how errors are handled by the system BIOS on the SDS2 server board.
Also discussed are the role of BIOS in error handling, and the interaction between the BIOS,
platform hardware, and server management firmware with regard to error handling. In addition,
error-logging techniques are described and beep codes for errors are defined.

6.2.1

Error Sources and Types

One of the major requirements of server management is to correctly and consistently handles
system errors. System errors, which can be disabled and enabled individually or as a group, can
be categorized as follows:

•

PCI bus

•

Memory correctable- and uncorrectable errors

•

Sensors

•

Processor internal error, bus/address error, thermal trip error, temperatures and
voltages, and GTL voltage levels

The BMC manages the sensors. It is capable of receiving event messages from individual
sensors and logging system events.

6.2.2

Handling and Logging System Errors

This section describes actions taken by the SMI handler with respect to the various categories of
system errors. It covers the events logged by the BIOS and the format of data bytes associated
with those events. The BIOS is responsible for monitoring and logging certain system events.
The BIOS sends a platform event message to BMC to log the event. Some of the errors, such
as processor failure, are logged during early POST and not through the SMI handler.

6.2.2.1

Logging Format Conventions

The BIOS complies with the Intelligent Platform Management Interface Specification, Revision
1.5. The BIOS always uses system software ID within the range 00h-1Fh to log errors. As a
result, the Generator ID byte is an odd number in the range 01h-3fh. OEM user binary should use
software IDs of 1. The Software ID allows external software to find the origin of the event
message.