RAM info with dmidecode --type 17

#linux #memory #hardware #ram

На материнской плате ASUS V-PRO Z77 установлены 2х2 (Kingston и Corsair) планок оперативной
памяти. Все четыре планки оперативной памяти нареканий в работе не вызывают. Работают
исправно. Но, ниже представлен вывод результата запуска программы Dmidecode и в выводе
меня интересуют следующие строки:  

Error Information Handle: 0x0060  
Error Information Handle: 0x0063  


Что это значит и с чем связана такая информация?  

$ sudo dmidecode --type 17
# dmidecode 2.12
# SMBIOS entry point at 0x000f04c0
SMBIOS 2.7 present.

Handle 0x005B, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x005C
    Error Information Handle: 0x0060
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: ChannelA-DIMM0
    Bank Locator: BANK 0
    Type: DDR3
    Type Detail: Synchronous
    Speed: 1333 MHz
    Manufacturer: Kingston
    Serial Number: 9333B00B
    Asset Tag: 9876543210
    Part Number: 99U5584-007.A00LF 
    Rank: 1
    Configured Clock Speed: 1333 MHz

Handle 0x005F, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x005C
    Error Information Handle: No Error
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: ChannelA-DIMM1
    Bank Locator: BANK 1
    Type: DDR3
    Type Detail: Synchronous
    Speed: 1333 MHz
    Manufacturer: 029E
    Serial Number: 00000000
    Asset Tag: 9876543210
    Part Number: CMZ8GX3M2A1600C9  
    Rank: 2
    Configured Clock Speed: 1333 MHz

Handle 0x0062, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x005C
    Error Information Handle: 0x0063
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: ChannelB-DIMM0
    Bank Locator: BANK 2
    Type: DDR3
    Type Detail: Synchronous
    Speed: 1333 MHz
    Manufacturer: Kingston
    Serial Number: 1D10C373
    Asset Tag: 9876543210
    Part Number: 99U5584-018.A00LF 
    Rank: 1
    Configured Clock Speed: 1333 MHz

Handle 0x0065, DMI type 17, 34 bytes
Memory Device
    Array Handle: 0x005C
    Error Information Handle: No Error
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 4096 MB
    Form Factor: DIMM
    Set: None
    Locator: ChannelB-DIMM1
    Bank Locator: BANK 3
    Type: DDR3
    Type Detail: Synchronous
    Speed: 1333 MHz
    Manufacturer: 029E
    Serial Number: 00000000
    Asset Tag: 9876543210
    Part Number: CMZ8GX3M2A1600C9  
    Rank: 2
    Configured Clock Speed: 1333 MHz  


UPD

$ sudo dmidecode --type 18
# dmidecode 2.12
# SMBIOS entry point at 0x000f04c0
SMBIOS 2.7 present.

Handle 0x005D, DMI type 18, 23 bytes
32-bit Memory Error Information
    Type: OK
    Granularity: Unknown
    Operation: Unknown
    Vendor Syndrome: Unknown
    Memory Array Address: Unknown
    Device Address: Unknown
    Resolution: Unknown

Handle 0x0060, DMI type 18, 23 bytes
32-bit Memory Error Information
    Type: OK
    Granularity: Unknown
    Operation: Unknown
    Vendor Syndrome: Unknown
    Memory Array Address: Unknown
    Device Address: Unknown
    Resolution: Unknown

Handle 0x0063, DMI type 18, 23 bytes
32-bit Memory Error Information
    Type: OK
    Granularity: Unknown
    Operation: Unknown
    Vendor Syndrome: Unknown
    Memory Array Address: Unknown
    Device Address: Unknown
    Resolution: Unknown

Handle 0x0066, DMI type 18, 23 bytes
32-bit Memory Error Information
    Type: OK
    Granularity: Unknown
    Operation: Unknown
    Vendor Syndrome: Unknown
    Memory Array Address: Unknown
    Device Address: Unknown
    Resolution: Unknown

    

Ответы

Ответ 1

Это значит, что информация об ошибках находится в других записях с номерами 0x0060
и 0x0063 соответственно.

Дабы узнать, что за ними скрывается dmidecode следует запустить без параметров и
просмотреть вывод. Номера handel'ов указываются в заголовках в выводе следующим образом:


  Handle 0x005B, DMI type 17, 34 bytes
  Memory Device


Вероятно их тип будет 18 (32-bit Memory Error Information) или 33 (64-bit Memory
Error Information).

По всей видимости само наличие значения в поле Error Information Handle покуда в
структуре на которую он ссылается значение Type: OK. Как именно представляются данные
определяется реализацией.

Низкое разрешение экрана

#linux #ubuntu #hardware

Внезапно компьютер начал загружаться с низким разрешением монитора.

Симптомы:
GRUB загружается с низким разрешением.
Потом Ubuntu 14.04 загружается с низким разрешением.
Параметры системы -> Настройка экранов  говорит «Неизвестный монитор» и максимальное
разрешение у него 1024 x 768.

xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767
VGA1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768       60.0*
   800x600        60.3     56.2
   848x480        60.0
   640x480        59.9
VIRTUAL1 disconnected (normal left inverted right x axis y axis)


Windows тоже загружается с низкой резолюцией, но дает поменять на нормальную.

Я подозреваю, что поломалась какая-то компонента оборудования, но если Windows может
это исправить, то и в Ubuntu это можно починить?
    

Ответы

Ответ 1

1. Установка разрешения монитора для сессии

(Эта часть решения найдена в здесь.
О команде xrandr можно почитать по-русски здесь,
а конкретнее по данному вопросу здесь.)

Сначала нужно запустить команду cvt и задать ей нужное разрешение.
Я не помнила, какое разрешение было раньше. Для того, чтобы это узнать, я посмотрела
размер обоев для рабочего стола.


cvt 1440 900 60
# 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync


Нам нужно то, что написано после слова Modeline.
Копируем это в xrandr --newmode (создать новый режим):

xrandr --newmode "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync
+vsync


Теперь добавляем новый режим:

xrandr --addmode VGA1 1440x900_60.00


(название монитора "VGA1" берется из вывода xrandr без параметров, как в вопросе)

на этом этапе у меня поменялось разрешение, хотя в документации предлагают запустить
еще одну команду.

xrandr --output VGA1 --mode 1440x900_60.00


Последние три команды меняют разрешение экрана в текущей сессии.

2. Постоянное разрешение

Внимание! Если в решении, приведенном ниже, что-то не сработает, то графический интерфейс
не загрузится и появится черный экран.
Вы можете нажать Ctrl+Alt+Fn, где n от 1 до 6, чтобы вызвать виртуальную консоль,
и там откатить или что-то изменить (например, с помощью команды sudo nano).

Итак, лучшее решение, что я нашла:
Создаем скрипт с этими тремя командами xrandr

xrandr --newmode "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync
+vsync
xrandr --addmode VGA1 1440x900_60.00
xrandr --output VGA1 --mode 1440x900_60.00


например, такой командой:

gksudo gedit /usr/bin/lightdmxrandr.sh &


Затем делаем его исполняемым:

sudo chmod +x /usr/bin/lightdmxrandr.sh


Теперь добавляем строку

display-setup-script=/usr/bin/lightdmxrandr.sh


в файл /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf, например, с помощью команды

gksudo gedit /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf


Теперь LightDM будет запускать этот скрипт перед X Windows.

Вторая часть основана на этом вопросе.

Программа на Си (32\64 бит)

#hardware

Привет Всем ! Изучаю "Си", если я пишу программу например в Windows\Linux 32bit то
она уже не будет работать в такой среде только 64-х битной и на оборот ? Просто после
Java иногда сложно вникнуть ! Ведь int в Си на 32-х битных системах имеет 4 байта а
в 64-х битных 8 байт тоесть он платфоромозависим ! Или всё же будет работать ? Спасибо
...    

Ответы

Ответ 1

Вот для этого используют #defineы, typedefы и оператор sizeof в C/C++ самым лютым
образом =)
Меняя подстановки на необходимый эквивалент (первые два варианта выше), можно поддерживать
переносимость. Например, отрывок из OpenGL:
typedef unsigned int GLenum;
typedef unsigned char GLboolean;
typedef unsigned int GLbitfield;
typedef signed char GLbyte;
typedef short GLshort;
typedef int GLint;
typedef int GLsizei;
typedef unsigned char GLubyte;
typedef unsigned short GLushort;
typedef unsigned int GLuint;
typedef float GLfloat;
typedef float GLclampf;
typedef double GLdouble;
typedef double GLclampd;
typedef void GLvoid;

На разных платформах разработчик библиотеки просто меняет typedef на необходимый
(совместимый) тип, а клиент обязуется не использовать типы напрямую. Клиентский код
получается переносимым между разными версиями библиотеки на уровне исходных кодов.
На бинарном уровне, конечно, такой совместимости не будет (если 64бит код на 32бит
системе), потребуется перекомпиляция с "местной" версией библиотеки.


Ответ 2

Если есть моменты, когда важны длины разных типов, то могут возникнуть проблемы.
Но они могут быть решены использованием типов с фиксированной длиной из заголовка sdint.h
вроде int64_t, int32_t и т.д. В остальном в случае использования стандартных функций
проблем возникнуть не должно.

Как работает процессор на уровне Физики? [закрыт]

#hardware #cpu

        
             
                
                    
                        
                            Закрыт. Данный вопрос необходимо конкретизировать. Ответы
на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы он был сосредоточен только на одной проблеме, отредактировав его.
                        
                        Закрыт 2 года назад.
                                                                                
           
                
        
Изучая C++ у меня возник вопрос, как устроен ПК и как так происходит, что он «понимает»
данные ему команды? То есть как он понимает, что 2+2=4, он же не человек? 
    

Ответы

Ответ 1

Если хотите узнать подробно, то советую почитать классический труд Тоненбаума - "Архитектура
компьютера", где рассматриваются большинство уровней функционирования компьютера, начиная
с самого низкого. Большинство схем ниже взяты оттуда.

В современных компьютерах есть такой электрический элемент, как транзистор. Он представляет
из себя элемент с тремя ножками: коллектор, базу, эммитер. Но суть в том, что он умеет
в зависимости от сигнала на базу, выпускать ток или нет.



Сигнал на базу поступает из различных внешних источников - намагниченная дорожка
жесткого диска, проходящий луч лазера через CD-R или же замкнутый нажатой кнопкой на
клавиатуре контакт. Не важно, главное, что у нас теперь есть два состояния - есть сигнал
и нет сигнала.

А теперь самое интересное, мы может комбинировать эти транзисторы и получить различные
результаты на основе входящих на их базы сигналов.



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



А это значит, что теперь у нас есть целый конструктор! И на этом конструкторе мы
может создавать различные схемы, которые будут давать разный результат. Подали на базы
различные сигналы и получили на выходе результат.

Вот так выглядит схема сдвига и схема полусумматора. Объединив несколько полусумматоров,
мы как раз получим побайтовое сложение чисел, о чем вы и спрашиваете в вопросе.



Есть даже схемы, которые умеют хранить значение, так называемые защелки выполняющие
роль памяти (RS-триггер).



Как видите никакой магии, ну почти - на одном процессоре таких транзисторов умещается
миллиарды... нет, не так - МИЛЛИАРДЫ! Это огромнейшее количество различных схем различной
сложности и различного направления на паре квадратных сантиметров. Расчетом их упаковки
на процессор как правило занимаются специальные программы, человеку это не под силу
и создаются они с помощью высокоточной электроники. Сложно представимый научный прогресс
в маленькой коробочке рядом с вами. В общем как-то так.

Возможно ли использовать вход mic-in, как audio-out в ноутбуке с Ubuntu

#linux #ubuntu #hardware #pulseaudio

На ноутбуке Asus A72D аудио-выход не подлежит восстановлению. Возможно ли программно
настроить микрофонный вход для использования наушников?

lspci определяет аудио-устройство как: Azalia (Intel HDA)

Если возможно, то, что для этого нужно?

(после поверхностного поиска, судя по тому, что удалось найти - аппаратно такая возможность
существует)
    

Ответы

Ответ 1

Вот, здесь нашлось решение:
Using microphone input port as headphone output

Оказывается достаточно установить:

sudo apt-get install alsa-tools-gui


Открыть приложение:

hdajackretask


Выбрать свою аудио-карту, на Pink Mic, Rear side поставить галочку Override и выбрать
Headphone. Нажать кнопку Install boot override и перезагрузиться. После этого у меня
микрофонный вход заработал как аудио-выход.

вопросы по поводу работы с жесткими дисками в linux

#linux #многопоточность #hardware

Здравствуйте, читаю "Системное программирование" Роберта Лава, он пишет про fsync(),
O_SYNC, но не понятно о назначении этих функций...


Где необходимы вызовы этих функций? Если б это было нужно всегда, то синхронизация
бы была по дефолту установлена. 
Цитата из книжки.


  Налицо огромное увеличение издержек, поэтому синхронизированный ввод-вывод следует
использовать только при отсутствии альтернатив.

Со сколькими параллельными операциями ввода / вывода может работать жесткий диск?
Ну т.е. хочу я в 1000 нитях параллельно читать или писать в разные файлы на диске,
будет ли толк, или начнет всё тормозить (имеется ввиду не из-за переключения контекста,
а из-за каких-то причин с самим диском)?

    

Ответы

Ответ 1

fsync и его подвиды требуются, когда приложение хочет получить гарантию, что данные
уже записаны на физический диск, а не будут записаны на диск.

Впрочем, начну лучше со второго вопроса:


  со сколькими параллельными операциями ввода/вывода может работать жесткий диск?


С одной. Потому что внутри HDD только один блок головок чтения-записи. И из-за ограничений
физических законов нашей вселенной этот блок может одновременно находиться только над
одним местом магнитного диска.

И следующее механическое ограничение - магнитные диски вращаются с постоянной скоростью,
а читать-писать можно только в одном месте. Значит если мы хотим прочитать сектора
в разных местах диска нам требуется:


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


Простым математическим подсчётом получаем механический предел в 120 операций в секунду
для 7200 rpm дисков (с частотой вращения 7200 оборотов в минуту). Будет меньше операций
если надо читать с разных областей диска, т.к. перемещение магнитной головки штука
медленная мало того из-за того что механическая операция но должна осуществляться точно
(речь о микрометрах), так ещё и в условиях вибрации от собственно самого диска и всех
прочих вибраций. Как итог вполне можно попасть не на ту дорожку и придётся перепозиционировать
головки ещё раз.

Но зато можно успеть прочитать больше данных, если они идут последовательно в секторах
одной дорожки.

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

И чтобы дать приложениям возможность попросить систему именно записать какие-то данные
в энергонезависимую память и добавили вызов fsync, который синхронизирует кэш записи
с дисками.



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

Но, к счастью, за последние лет 10 сильно подешевела flash-память и появились SSD
диски. Дисками их называют только по привычке, на самом деле никакой механики там уже
нет. И параллельная обработка запросов (пусть и за счёт обращений к разным кристаллам
памяти) и куда более внушительная производительность по метрике количества операций
в секунду (iops) - всё возможно. И, вероятно, со временем будут пересмотрены в сторону
упрощения и планировщики ввода-вывода (собственно blk_mq в ядре linux уже) и упрощены
другие нагромождения этих десятилетий когда для хранения данных использовалась медлительная
механика. У flash-памяти своих интересных фокусов тоже хватает (например, есть не 2
операции чтение и запись, а чтение, стирание, запись - запись возможна только в предварительно
очищенную страницу. Отсюда выросла необходимость в команде trim) - но это уже тема
отдельных изысканий.


Ответ 2

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

Прямой доступ к оборудованию под Linux

#hardware #c #cpp #linux

Имеется рабочая машинка с ОС Linux. Требуется получить из консольного пользовательского
приложения (ring3) доступ к портам ввода-вывода.
Под ОС Windows эта проблема решается следующими способами:

драйвер типа userport или giveio -> прямо в программе делаем ввод-вывод через команды
asm'а in/out
собственный драйвер "виртуального у-ва", который в ring0 делает всю черновую работу
и      предоставляет некий интерфейс с помощью IOCTL прикладным программам. Пользовательское
приложение вызывает соответствующие IOCTL'ы.

Какие варианты есть под Linux? Прошу снадбить короткими примерами кода.
PS: ес-но root'овые привилегии имеют место быть.    

Ответы

Ответ 1

Ну, основной способ в Linux следовать тем же путём: делаете модуль ядра, который
работает с портами ввода-вывода и предоставляет какой-то интерфейс для приложений,
например, создаёт tty или какой-то другой файл-устройство и, возможно, предоставляет
IOCTL; а из приложения обращаетесь к этому файлу-устройству и работаете с драйвером
через него. Пример приведу позже, если другие не приведут. Однако, кое какие примеры
можно легко найти в интернете. Например: Character Device Drivers. И вообще, если вы
планируете идти по первому пути, то не мешает пролистать этот The Linux Kernel Module
Programming Guide, который является классикой жанра из категории MUST READ. Вот ещё
то же (или почти то же), на русском: The Linux Kernel Module Programming Guide (RU).
Или вот ещё пример: Implementing a Simple Char Device in Linux
Ну и конечно многие устройства при подключении определяются как serial port или что-то
подобное и тогда соответствующий модуль ядра создаёт этот самый файл-устройство и тогда
вам надо просто понять, что с этим файлом-устройством делать.
Второй путь - это использовать user space device driver API. Почитайте, например
тут: User-space device drivers

Функции железа и ОС

#linux #hardware #os #bios #uefi

Прошу пояснить некоторые вещи, которые я опишу ниже. Я много читал о том, как загружается
система, какие функции выполняет железо, какие - система, но пока что полной картины
сложить не могу.

Итак. Как я понимаю, при загрузке системы сначала просыпается bios. Он проверяет
все железо, делает диагностику. Когда он решит, что все нормально, он считывает 512
(не уверен) первых байт с диска, проверяет 2 "магических" байта, и если они говорят
о том, что этот диск - загрузочный, то bios начинает выполнять код загрузчика, т.е.
этих 510 байт. При этом начинает выполнять не сразу, а записав их по некоторому адресу
в оперативную память. Здесь вроде все понятно. А еще как процессор адресует память
- постранично - вроде тоже понятно. 

А теперь то, что мне непонятно: допустим, я загружаю linux. Загрузчик с диска поднял
grub, grub загрузил ядро, ядро начало выполняться. Окай. Но как ядро адресует память?
Получается напрямую физическую? Ну т.е. без виртуальной. Тогда другой вопрос. Получается
весь user-space код, который адресует виртуальную память, выполняется в некой "песочнице"
ядра, которая позволяет транслировать адреса виртуальные в физические? Или же есть
какие-то именно процессорные механизмы? И как работает uefi?

В общем, меня интересует то, какие возможности предоставляет процессор, да и железо
в целом, а что реализовано на системном уровне, и если можно, то почему оно так работает. 

И да, еще интересно, как процессор общается с различным железом вроде видеокарт,
и какие интерфейсы он предоставляет для управления этим железом программно.
    

Ответы

Ответ 1

Загрузка кажется только простой, правда, это очень сложный и многошаговый процесс,
я постараюсь Вам описать его. Хоть это и будет похоже на маленькую книжку, но я надеюсь,
что многим будет интересно это почитать.

Вы нажали кнопку питания

Линия PS_ON замыкает на "землю" и происходит подача питания на все железо! ОНО ОЖИЛО!.
Блок питания включен. Начинается тестирование блока питания на соответствие всех напряжений
требованиям. В случае удачного завершения данной операции, спустя 0.1-0.5с, вырабатывается
сигнал Power Good, свидетельствующий о том, что загрузку компьютера можно продолжать.
Головки жесткого диска выходят из парковочной зоны, остальное оборудование включается...ПОЕХАЛИ!



Блок питания проверился, а что дальше?

Дальше на специальный вход центрального процессора подается сигнал сброса (Reset).
Процессор обнуляет содержимое своей памяти и начинает работу.

В чем заключается начало работы процессора?

Системная память сделана так, что первая команда которую будет считывать процессор
после сброса находится в BIOS. Это инструкции по проведению самотестирования. Программа
POST выполняет тестирование процессора, оперативной памяти, чипсета, видеосистемы,
накопителей, системы управления питанием, клавиатуры, портов LPT и COM (а также подключенных
к ним устройств), других компонентов компьютера.

POST завершился, что делать дальше системе?

После того как успешно завершилась процедура POST, вызывается программное прерывание
BIOS INT 19h и запускается процедура поиска загрузочного сектора порядок поиска которого
установлен непосредственно в BIOS.

Теперь будем искать загрузочную запись?

Да, но сначала немного терминологии, без которой дальше делать нечего:


  Сектор - минимальный участок хранения информации на жестком диске
  равный 512 байтам;
  MBR (Master Boot Record) - Главная загрузочная запись, она находится в
  нулевом секторе диска и по сути является загрузочным сектором жесткого
  диска;


Дальше с указанного жесткого диска BIOS`ом считывается главная загрузочная запись
MBR и управление дальнейшей загрузкой передается ей. Далее микропрограмма, находящаяся
в MBR, сканирует таблицу разделов на наличие активного загрузочного раздела, после
того как системный раздел будет найден, MBR загружает в память компьютера его нулевой
сектор и выполняет код находящийся в нем. Загрузочный сектор раздела содержит код операционной
системы, которую нужно загружать. В случае, когда на жестком диске нет системного раздела,
BIOS отобразит сообщение об ошибке. Если системный раздел будет найден, загрузка продолжится.
Все вышесказанное относится к запуску абсолютно любой операционной системы.

Хочу загружать Windows!

А теперь, если вы например загружаете WINDOWS, после всего вышесказанного, загрузчик
ntldr который находится в системном разделе считывает из загрузочного файла boot.ini
информацию о количестве операционных систем и их расположении, и предлагает пользователю
выбрать из списка операционную систему.

Система выбрана!

Отлично, загружаем ядро в память, система готова к работе, но как же ядро управляет
распределением памяти? 

Что представляет собой ОЗУ?

Логически ОЗУ представляет собой упорядоченный (одномерный) массив элементов. Элементы
(минимальные адресуемые единицы МАЕ) пронумерованы, причем номер каждой МАЕ фиксирован
и определяется схемотехнической реализацией устройства памяти. Номер элемента реально
существующего в системе устройства памяти в дальнейшем будем называть адресом (Address)
этого элемента. В каждой такой ячейке может храниться двоичное слово фиксированной длины

Распределяем память

И так, адресная шина процессора работает...Нет, это слишком долго.. Будем считать,
что процессор работает с диапазоном последовательных адресов от нуля до максимально
доступного в системе адреса (в зависимости от количества оперативной памяти) и может
при необходимости обратиться к любому байту в этом диапазоне. 

Если сгенерировать для программы адреса, как они расположены в физическом виде, без
виртуальной, то одновременное выполнение двух программ просто невозможно из-за перекрывания
данных одной программы другой. Например, компилятор генерирует адреса для виртуального
адресного пространства заданного диапазона, а устройство управления памятью, называемое
диспетчером памяти, транслирует виртуальные адреса, сгенерированные компилятором, в
адреса ячеек, расположенных в физической памяти. Компилятору нет необходимости знать,
в какое место в памяти ядро потом загрузит выполняемую программу. 


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




Диспетчер памяти, это не какой-то процесс! Это устройство и оно может находиться
на микросхеме процессора или на отдельной микросхеме рядом с процессором. 

Вы обратились на какой-нибудь 32 битный адрес, то модуль разделяет его на 20 разрядный
адрес страницы и 12 разрядное смещение внутри страницы. Все это называется прозрачной
работой с памятью, когда программист даже не подозревает о существовании страничной
организации памяти. Хотя, есть страничная организация памяти с процессом сегментации,
при котором программисту требуется знать о существовании сегментов. 

UEFI

Код микропрограммы UEFI написан на C и выполняется в современном 64-битном режиме.
По сути это полноценная операционная система, которая  работает на неограниченном уровне
доступа к ресурсам "ring 0". Выполняется фаза PEI, и DXE перед загрузкой. Я не вижу
смысла здесь все это описывать, вот картинка вам:



Источники: IBM.com, Habrahabr.ru, Overclockers.ru, Таненбаум Э. "Архитектура компьютера"

Для более четкого понимания работы компьютера и решения ваших вопросов, присоединюсь
к ответу @AlexanderBlinov, прочитайте Архиктуру компьютера, очень полезная книга.


Ответ 2

В рамках StackOverflow невозможно развёрнуто ответить на Ваш вопрос, хотя он весьма
интересен.

Для получения ответа рекомендую Вам прочитать книгу "Архитектура компьютера" Э. Таненбаум,
Т. Остин. В данной книге Вы найдёте ответы на эти вопросы.

Крайне интересная и полезная литература. В принципе, в Сети есть pdf этой книги,
найти его несложно.

Как связаны разрядность процессора, разрядность его регистров, размер адресуемой памяти и как все это влияет на быстродействие?

Изучаю архитектуру компьютера по книгам Танненбаума  и Харрис.

И все равно не понимаю многих вроде бы простых вещей. Вопросов много, но почти все они так или иначе связаны с машинным словом. Это самая непонятная для меня тема.

Хочу оговориться, что я понимаю, что между разрядностью процессора, разрядность
регистров, размером адресуемой памяти и быстродействием компьютера существует прямая связь. Я не понимаю почему так.  


Как рязрядность процессора влияет на его быстродействие. Вроде как
64-разрядные быстрее чем 32-разрядные. Но почему? Не понимаю.
Приведу пример: Система команд для процессоров MIPS-32. Там ведь
сама архитектура команд такая, что все команды убираются в 32 бита.
То есть, если сделать 64 бита, старшие 32 бита придется просто
заполнить нулями. И что, процессор станет от этого быстрее?
Из Википедии: 


  разрядность процессора (разрядность его машинного слова). Машинное
  слово — машинно-зависимая и платформозависимая величина, измеряемая в
  битах или байтах (тритах или трайтах), равная разрядности регистров.


Почему машинное слово обязательно должно быть равно разрядности
регистров? Почему мы не можем читать данные по 64 бита за раз имея
16-разрядные регистры, например?
Теперь про память. Снова из Википедии:


  64-битный регистр способен хранить в себе одно из 264 = 18 446 744 073
  709 551 616 значений. Процессор с 64-битной адресацией памяти может
  напрямую обращаться к 16 ЭБ памяти.


Я понимаю что количество памяти зависит от адреса количества бит в
адресе. Но опять же, как это связано с регистрами? Я вижу только
одну связь: если мы собираемся хранить адреса в регистрах, то
регистры должны иметь ту же разрядность что и адреса. Но разве
обязательно хранить адреса в регистрах?
Про разрядность ОС я вроде понимаю, но хотелось бы уточнить. Как я
понимаю, ОС связана со всем этим так: 64-разрядная ОС работает на
64-разрядном процессоре, 32-разрядная - на 32-разрядном. То есть с
появлением 64-разрядного процессора было неизбежно появление
64-разрядной ОС. Правильно ли я понимаю это?
И вот тут вопрос скорее исторический, но так же очень важный для
меня. Я всегда считал что 64-разрядный процессор появился недавно и
это преподносилось как большой прорыв. А на Википедии вот что
написано: 


  Требования к точности научных вычислений возросли, и в 1974 году
  появилась первая машина с 64-битным словом — суперкомпьютер Cray-1

В чем вообще была сложность создать 64-разрядный процессор? И в чем
сейчас сложность создать, например, 128-разрядный процессор? От чего
это вообще зависит? Чем определяется? Разрядностью регистров? А в
чем сложность увеличить разрядность регистров? Чем она определяется?

    

Ответы

Ответ 1

Основная работа процессора заключается не в передаче информации, а в ее преобразовании
Регистр - это та же оперативная память, но от которой идет прямая разводка к куче исполняющи
устройств, которые производят арифметические и другие действия с данными. Этих лини
делается очень много. На каждый разряд регистра будет свой и большой набор транзисторов для выполнения конкретных операций. Отсюда и сложность увеличения количества разрядов. При росте размерности регистра в 2 раза как минимум удваивается и объем всех исполняющих устройств. растет кристалл, растет тепловыделение.

Посмотрите на систему команд, любые преобразования данных требуют участия как миниму
одного регистра. А часть операций происходит исключительно в регистрах. В x86 архитектур
можно добавить к регистру память. Но например нельзя произвести сдвиг или умножение ячейки памяти. нельзя сложить значения двух ячеек памяти не забрав предварительно одну из них в регистр. потому что исполнительный механизм данной операции имеет прямую разводку только с регистром.


  В: Почему мы не можем читать данные по 64 бита за раз имея 16-разрядные регистры


Можем, но куда читать и зачем ? Вообще современные процессоры так и делают, заполняю
внутренний кеш и оперируют при этом разрядностью шины, регистры тут не участвуют. Прочитал
мы 64 бита в кеш, а теперь нам надо их умножить на 3, например. А регистр у нас 16 битный, как умножать ? Правильно, частями, применяя кучу дополнительных преобразований и тратя на это драгоценные такты. Поэтому размерность шины передачи вторична. Главное - это разрядность регистра. И это назвали машинным словом.


  В: Но разве обязательно хранить адреса в регистрах?


Да, обязательно. Процессору как то надо сказать - возьми вот там данные. А там эт
где ? В памяти ? А как тогда будет выглядеть инструкция - возьми адрес, находящийс
по адресу, вон по тому адресу лежащему в инструкции ... А если нам надо работать подряд с блоком данных (мы в цикле обрабатываем массив) и этот адрес надо увеличивать (т.е. выполнять сложение, которое мы можем произвести только в регистре)

Кстати, разрядность команды и разрядность процессора разные вещи. В MIPS упаковал
все команды в 32 бита. А x86 платформа с незапамятных времен была с переменной разрядность
операций. от коротких однобайтных, до длиннющих монстров с кучей префиксов. Разрядность процессора = разрядность регистра = максимальный размер обрабатываемой одной инструкцией информации (в обычных командах, из которых состоит основной код, всякие SSE не берем).

Быстродействие - кто сказал, что разрядность играет ключевую роль. Да, разрядност
влияет. Бум на 64 битные процессоры и ОС отличный пример маркетинга. 64 битный код част
оказывается медленнее 32 битного. Если программе не надо адресовать более 4 Гб памяти
а ее  код хранит 64 битные адреса - то размер программы в 2 раза больше. Больше размер - дольше читать в кеш. Требуется больше памяти. Начинается гонка за гигабайтами оперативки ... Сейчас даже пошел обратный процесс. во всю развивается x32 ABI - работа 32 битного кода в 64 битном режиме.

Но давайте возьмем RSA-шифрование, которое используется в том же повсеместном SSL
Для него необходимы сложные расчеты с очень большими числами. Предположим, что у на
нет специализированных инструкций процессора для него. Разумеется если процессор оперирует 64 битными регистрами он выполнит расчет в 2 раза быстрее, просто потому, что за один такт он способен обработать в 2 раза больше информации. Да, на расчетных задачах с большими числами выигрыш от увеличения разрядности сложно переоценить. 


  В:  64-разрядная ОС работает на 64-разрядном процессоре, 32-разрядная - на 32-разрядном.


Нет, 64 битная ОС состоит из 64 битного кода, способного адресовать память 64 битным
адресами. Конечно она может это делать только на 64 битном процессоре. Появление О
конечно было неизбежно. Хотя и тут маркетинг сыграл значительную роль. 90% разбирающег
в компах народа считают, что для адресации свыше 4 Гб оперативной памяти на платформе intel нужна 64 Бит ОС. Да, в Windows было насильно введено такое ограничение. Процессоры Intel в 32 битном режиме PAE адресуют до 64 Гб оперативки, при этом правда один процесс ограничен 4 Гб. 32 Бит linux отлично себя чувствует с такими объемами.

По поводу истории и сложности построения 128 битных регистров ... вопрос только 
цене. Да, на каких то системах не массового рынка это сделано давно, на массовом рынк
было не нужно, вот и не появлялось. И тогда оно стоило баснословно, ибо как мы говорил
в начале - каждый бит регистра - это куча исполняющих устройств, а при тех технология
производства разместить на кристалле столько транзисторов было, скажем так, затруднительно. Полноценные 128 битные процессоры попросту не нужны, особенно для массового рынка, адресовать больше 64 ЭБ памяти, где бы ее еще найти. Вообще сейчас во всех процессорах intel есть 16 регистров SSE размером 128 бит, это не регистры общего назначения, они для расчетов. А на современных Xeon, предназначенных для серьезных вычислений, 32 регистра ZMM по 512 бит (см. AVX)...


Ответ 2

Я вижу только одну связь: если мы собираемся хранить адреса в регистрах, то регистры должны иметь ту же разрядность что и адреса.


Чтобы окончательно вас запутать: Не должны.

К примеру, восьмибитные процессоры умеют адресовать 16 бит: инструкция доступа 
памяти выбирает адрес не из регистра, а из регистровой пары. 8086-й процессор с 16-ю разрядными регистрами умеет адресовать 20 бит (базовый регистр << 4 + регистр смещения).

Упомянутый Cray-1 имел 64-разрядные регистры данных и 24-разрядные регистры адреса.


Ответ 3

Всё относительно.

К примеру, рас-параллеливание алгоритмов может выигрывать на процессорах с нескольким
ядрами, но лишь в случае - если алгоритм поддаётся распараллеливанию. Т.е. если задачу можно разделить на две параллельные нити.

Так же и с разрядностью процессора. Если алгоритм можно оптимизировать под большие регистры - то да, на x86_64 он будет выполняться быстрее, чем на i386. 

Но если сам алгоритм не поддаётся оптимизации и его скорость не зависит от размера регистра - то никакого ускорения Вы не получите.

linux использует только часть процессоров

Имеется восьмипроцессорный сервер. Каждый процессор по 10 ядер, итого 80 физических ядер. ОС Oracle Linux Server release 6.7, ядро 3.8.13-98.2.1.el6uek.x86_64
Проблема в том, что ОС использует только два процессора из 8:

При этом lscpu, говорит что все ядра задействованы
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 160 On-line CPU(s) list: 0-159 Thread(s) per core: 2 Core(s) per socket: 10 Socket(s): 8 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 47 Stepping: 2 CPU MHz: 2393.990 BogoMIPS: 4787.90 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 30720K NUMA node0 CPU(s): 0-159
Пробовал запустить strees -c 80, количество задействованных ядер не изменилось, только выросла la. Не знаю куда копать. Признателен за любую помощь. Спасибо.

Ответ

Было обновлено ядро ОС. В биосе выставил вручную количество задействованных ядер на CPU (опция Enhanced Processor Core Disable (Intel Core Select)).
После загрузки в ОС все ядра стали использоваться, stress -c 160, соответственно, нагрузил их все. Доподлинно сказать, что именно помогло не могу.
Всем спасибо за помощь.

Web vs. периферия

Дано: Web сервер и клиентское устройство. На клиентском устройстве имеются порты (COM, USB и тп.) через которые устройство получает данные от периферии (датчики, сенсоры и пр. оборудование) На устройстве доступен браузер, любые плагины к нему и, в принципе, возможно установить любое доп. п.о. Клиентских устройств много. Их кол-во заранее не известно.
Вопрос: С помощью каких технологий возможно реализовать первичную обработку и отображение данных с периферийных устройств в браузере на клиентской машине. Ну и передачу данных на сервер ? Дополнение: Есть ли что-то подходящее в .Net?
В качестве примера: Есть, скажем, датчики температуры, давления и влажности. Подключены к ПК по USB, COM и Ethernet. Я на данном пк открываю в браузере некоторую страницу на моём сервере и хочу чтобы на сервере по данным с датчиков был рассчитан, скажем, прогноз погоды на ближайший час или данные просто были занесены в БД для дальнейшей обработки и, при этом, не хочу ручками забивать показания датчиков в форму для отправки на сервер.

Ответ

Вам нужно разрабатывать кроссплатформенное ПО для ваших устройств. Технологий тьма что-то конкретное советовать сложно, нужно знать требования по архитектуре и производительности. (С++ Qt/Poco, Python, NodeJS..., если win можно и .net ) Софт этот будет вести сбор данных и передавать на удаленный сервер(HTTP-REST или Websocket). Браузер я вобще не понял зачем тут. На вашем удаленном сервере необходимо организовать бекенд для веб-сервера который будет вести пост обработку. Тут что-то советовать по технологиям, тоже сложно. Не понятно под какой ос сервер и какие требования по произоводительности.

Магнитометр mpu 9150 вывод данных

Проблема заключается в выводе откалиброванных данных с магнитометра. Поворот вокруг оси Z(вперед) и X(вправо) показывает нормально, но как только поворачиваю его вокруг оси Y(вверх), поворот немного виден, но амплитуда значительно сужается сужается, т.е. как будто данные о направлении севера есть, но они смещены относительно 0,0,0. На картинке 3 видно как поворот вокруг оси Y меньшей амплитуды, чем поворот вокруг осей X и Z (круг меньшего диаметра). Возможно я не правильно откалибровал магнитометр? Пунктир - то, что ожидается при повороте вокруг вертикальной оси. Возможно, эти данные нужно каким-то образом нормализовать, чтобы привести к реальному вектору относительно севера, но не имею представления как это сделать.

Вот откалиброванные значения, один в один с моими, взятые в сети из другого источника. Красные, синие и зеленые точки - это те данные, которые получаются при повороте вокруг вертикальной оси. Как теперь их привести к нормальному виду, для отображения реальной ориентации?

Ответ

Теперь я вас понял. Вы описывали окружность осью магнитометра с центром в воображаемой оси Земли. Когда воображаемая ось была направлена вперёд и вправо, всё было в порядке. Когда вы описывали окружность вокруг воображаемой оси, направленной вверх, проблема возникла от того, что вектор магнитной индукции не параллелен поверхности Земли. Вот что у вас получилось:

Теперь, как я понимаю, ваша задача - вычислить азимут. В простейшем случае можно воспользоваться формулой:
float azimuth = atan2(z, x); if (azimuth < 0) azimuth += 360;
Однако крен и тангаж вносят большие искажения в показания магнитометра. Поэтому магнитометр должен всегда работать в паре с акселерометром (либо нужно обеспечивать строго горизонтальное положение). Методику расчёта углов поворота с помощью магнитометра и акселерометра можно найти здесь

Шаблон для организации работы на предприятии

В рамках данного вопроса, разобъю его на несколько разделов: 1.На предприятии встал вопрос об организации работы сотрудников с программным обеспечением, в формате подключения к 1 центральному компьютеру, который будет оснащен всем необходимым программным обеспечением(компьютер на базе Windows 10 Pro либо иной другой). Касательно программного обеспечения: стандартный пакет Office(excel,word,powerpoint), софт для SEO(KeyKollector,Seo spider), Adobe Photoshop, Adobe InDesign, CorelDraw. Формат работы состоит в том, что сотрудник подключается к компьютеру под своей учетной записью, и работает. Результат работы выкладывает например на файловый сервер либо в облачное хранилище. Одной из основных целей подобной организации работы является сократить количество закупленных лицензий программного обеспечения. Насколько возможен такой формат работы, если количество одновременно подключенных пользователей будет варьироваться от 5 до 10. По аппаратному обеспечению достаточно ли будет core i7(i9) с 64гб оперативной памяти DDR4, ssd 1-2Тб на базе Samsung 960.

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

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

Ответ

По первому пункту: Microsoft - жадная контора и за одной десктопной виндой может работать только один человек. Не важно локально он сидит или удалённо. Для одновременной работы нужен Windows server + лицензии на клиентов для сервера терминалов. В магазине не покупается, надо искать дистрибьютеров\интеграторов. Они и по железу подсказать могут. Но в любом случае: смотреть на то сколько памяти\проца жрёт обычный фотошоп на обычной машине + запас хотя бы в половину. И это - на одного человека.

RAM info with dmidecode --type 17

На материнской плате ASUS V-PRO Z77 установлены 2х2 (Kingston и Corsair) планок оперативной памяти. Все четыре планки оперативной памяти нареканий в работе не вызывают. Работают исправно. Но, ниже представлен вывод результата запуска программы Dmidecode и в выводе меня интересуют следующие строки:
Error Information Handle: 0x0060 Error Information Handle: 0x0063
Что это значит и с чем связана такая информация?
$ sudo dmidecode --type 17 # dmidecode 2.12 # SMBIOS entry point at 0x000f04c0 SMBIOS 2.7 present.
Handle 0x005B, DMI type 17, 34 bytes Memory Device Array Handle: 0x005C Error Information Handle: 0x0060 Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: ChannelA-DIMM0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 1333 MHz Manufacturer: Kingston Serial Number: 9333B00B Asset Tag: 9876543210 Part Number: 99U5584-007.A00LF Rank: 1 Configured Clock Speed: 1333 MHz
Handle 0x005F, DMI type 17, 34 bytes Memory Device Array Handle: 0x005C Error Information Handle: No Error Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: ChannelA-DIMM1 Bank Locator: BANK 1 Type: DDR3 Type Detail: Synchronous Speed: 1333 MHz Manufacturer: 029E Serial Number: 00000000 Asset Tag: 9876543210 Part Number: CMZ8GX3M2A1600C9 Rank: 2 Configured Clock Speed: 1333 MHz
Handle 0x0062, DMI type 17, 34 bytes Memory Device Array Handle: 0x005C Error Information Handle: 0x0063 Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: ChannelB-DIMM0 Bank Locator: BANK 2 Type: DDR3 Type Detail: Synchronous Speed: 1333 MHz Manufacturer: Kingston Serial Number: 1D10C373 Asset Tag: 9876543210 Part Number: 99U5584-018.A00LF Rank: 1 Configured Clock Speed: 1333 MHz
Handle 0x0065, DMI type 17, 34 bytes Memory Device Array Handle: 0x005C Error Information Handle: No Error Total Width: 64 bits Data Width: 64 bits Size: 4096 MB Form Factor: DIMM Set: None Locator: ChannelB-DIMM1 Bank Locator: BANK 3 Type: DDR3 Type Detail: Synchronous Speed: 1333 MHz Manufacturer: 029E Serial Number: 00000000 Asset Tag: 9876543210 Part Number: CMZ8GX3M2A1600C9 Rank: 2 Configured Clock Speed: 1333 MHz
UPD
$ sudo dmidecode --type 18 # dmidecode 2.12 # SMBIOS entry point at 0x000f04c0 SMBIOS 2.7 present.
Handle 0x005D, DMI type 18, 23 bytes 32-bit Memory Error Information Type: OK Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown
Handle 0x0060, DMI type 18, 23 bytes 32-bit Memory Error Information Type: OK Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown
Handle 0x0063, DMI type 18, 23 bytes 32-bit Memory Error Information Type: OK Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown
Handle 0x0066, DMI type 18, 23 bytes 32-bit Memory Error Information Type: OK Granularity: Unknown Operation: Unknown Vendor Syndrome: Unknown Memory Array Address: Unknown Device Address: Unknown Resolution: Unknown

Ответ

Это значит, что информация об ошибках находится в других записях с номерами 0x0060 и 0x0063 соответственно.
Дабы узнать, что за ними скрывается dmidecode следует запустить без параметров и просмотреть вывод. Номера handel'ов указываются в заголовках в выводе следующим образом:
Handle 0x005B, DMI type 17, 34 bytes Memory Device
Вероятно их тип будет 18 (32-bit Memory Error Information) или 33 (64-bit Memory Error Information).
По всей видимости само наличие значения в поле Error Information Handle покуда в структуре на которую он ссылается значение Type: OK. Как именно представляются данные определяется реализацией.

Низкое разрешение экрана

Внезапно компьютер начал загружаться с низким разрешением монитора.
Симптомы: GRUB загружается с низким разрешением. Потом Ubuntu 14.04 загружается с низким разрешением. Параметры системы -> Настройка экранов говорит «Неизвестный монитор» и максимальное разрешение у него 1024 x 768.
xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767 VGA1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x600 60.3 56.2 848x480 60.0 640x480 59.9 VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Windows тоже загружается с низкой резолюцией, но дает поменять на нормальную.
Я подозреваю, что поломалась какая-то компонента оборудования, но если Windows может это исправить, то и в Ubuntu это можно починить?

Ответ

1. Установка разрешения монитора для сессии
(Эта часть решения найдена в здесь. О команде xrandr можно почитать по-русски здесь, а конкретнее по данному вопросу здесь.)
Сначала нужно запустить команду cvt и задать ей нужное разрешение. Я не помнила, какое разрешение было раньше. Для того, чтобы это узнать, я посмотрела размер обоев для рабочего стола.
cvt 1440 900 60 # 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz Modeline "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
Нам нужно то, что написано после слова Modeline. Копируем это в xrandr --newmode (создать новый режим):
xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync
Теперь добавляем новый режим:
xrandr --addmode VGA1 1440x900_60.00
(название монитора "VGA1" берется из вывода xrandr без параметров, как в вопросе)
на этом этапе у меня поменялось разрешение, хотя в документации предлагают запустить еще одну команду.
xrandr --output VGA1 --mode 1440x900_60.00
Последние три команды меняют разрешение экрана в текущей сессии.
2. Постоянное разрешение
Внимание! Если в решении, приведенном ниже, что-то не сработает, то графический интерфейс не загрузится и появится черный экран. Вы можете нажать Ctrl+Alt+Fn, где n от 1 до 6, чтобы вызвать виртуальную консоль, и там откатить или что-то изменить (например, с помощью команды sudo nano).
Итак, лучшее решение, что я нашла: Создаем скрипт с этими тремя командами xrandr
xrandr --newmode "1440x900_60.00" 106.50 1440 1528 1672 1904 900 903 909 934 -hsync +vsync xrandr --addmode VGA1 1440x900_60.00 xrandr --output VGA1 --mode 1440x900_60.00
например, такой командой:
gksudo gedit /usr/bin/lightdmxrandr.sh &
Затем делаем его исполняемым:
sudo chmod +x /usr/bin/lightdmxrandr.sh
Теперь добавляем строку
display-setup-script=/usr/bin/lightdmxrandr.sh
в файл /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf, например, с помощью команды
gksudo gedit /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf
Теперь LightDM будет запускать этот скрипт перед X Windows.
Вторая часть основана на этом вопросе

Программа на Си (32\64 бит)

Привет Всем ! Изучаю "Си", если я пишу программу например в Windows\Linux 32bit то она уже не будет работать в такой среде только 64-х битной и на оборот ? Просто после Java иногда сложно вникнуть ! Ведь int в Си на 32-х битных системах имеет 4 байта а в 64-х битных 8 байт тоесть он платфоромозависим ! Или всё же будет работать ? Спасибо ...

Ответ

Вот для этого используют #defineы, typedefы и оператор sizeof в C/C++ самым лютым образом =) Меняя подстановки на необходимый эквивалент (первые два варианта выше), можно поддерживать переносимость. Например, отрывок из OpenGL: typedef unsigned int GLenum; typedef unsigned char GLboolean; typedef unsigned int GLbitfield; typedef signed char GLbyte; typedef short GLshort; typedef int GLint; typedef int GLsizei; typedef unsigned char GLubyte; typedef unsigned short GLushort; typedef unsigned int GLuint; typedef float GLfloat; typedef float GLclampf; typedef double GLdouble; typedef double GLclampd; typedef void GLvoid; На разных платформах разработчик библиотеки просто меняет typedef на необходимый (совместимый) тип, а клиент обязуется не использовать типы напрямую. Клиентский код получается переносимым между разными версиями библиотеки на уровне исходных кодов. На бинарном уровне, конечно, такой совместимости не будет (если 64бит код на 32бит системе), потребуется перекомпиляция с "местной" версией библиотеки.

Возможно ли использовать вход mic-in, как audio-out в ноутбуке с Ubuntu

На ноутбуке Asus A72D аудио-выход не подлежит восстановлению. Возможно ли программно настроить микрофонный вход для использования наушников?
lspci определяет аудио-устройство как: Azalia (Intel HDA)
Если возможно, то, что для этого нужно?
(после поверхностного поиска, судя по тому, что удалось найти - аппаратно такая возможность существует)

Ответ

Вот, здесь нашлось решение: Using microphone input port as headphone output
Оказывается достаточно установить:
sudo apt-get install alsa-tools-gui
Открыть приложение:
hdajackretask
Выбрать свою аудио-карту, на Pink Mic, Rear side поставить галочку Override и выбрать Headphone. Нажать кнопку Install boot override и перезагрузиться. После этого у меня микрофонный вход заработал как аудио-выход.

вопросы по поводу работы с жесткими дисками в linux

Здравствуйте, читаю "Системное программирование" Роберта Лава, он пишет про fsync(), O_SYNC, но не понятно о назначении этих функций...
Где необходимы вызовы этих функций? Если б это было нужно всегда, то синхронизация бы была по дефолту установлена. Цитата из книжки.
Налицо огромное увеличение издержек, поэтому синхронизированный ввод-вывод следует использовать только при отсутствии альтернатив. Со сколькими параллельными операциями ввода / вывода может работать жесткий диск? Ну т.е. хочу я в 1000 нитях параллельно читать или писать в разные файлы на диске, будет ли толк, или начнет всё тормозить (имеется ввиду не из-за переключения контекста, а из-за каких-то причин с самим диском)?

Ответ

fsync и его подвиды требуются, когда приложение хочет получить гарантию, что данные уже записаны на физический диск, а не будут записаны на диск.
Впрочем, начну лучше со второго вопроса:
со сколькими параллельными операциями ввода/вывода может работать жесткий диск?
С одной. Потому что внутри HDD только один блок головок чтения-записи. И из-за ограничений физических законов нашей вселенной этот блок может одновременно находиться только над одним местом магнитного диска.
И следующее механическое ограничение - магнитные диски вращаются с постоянной скоростью, а читать-писать можно только в одном месте. Значит если мы хотим прочитать сектора в разных местах диска нам требуется:
спозиционировать на эту дорожку блок головок чтения-записи дождаться, пока требуемый сектор не окажется под головкой
Простым математическим подсчётом получаем механический предел в 120 операций в секунду для 7200 rpm дисков (с частотой вращения 7200 оборотов в минуту). Будет меньше операций если надо читать с разных областей диска, т.к. перемещение магнитной головки штука медленная мало того из-за того что механическая операция но должна осуществляться точно (речь о микрометрах), так ещё и в условиях вибрации от собственно самого диска и всех прочих вибраций. Как итог вполне можно попасть не на ту дорожку и придётся перепозиционировать головки ещё раз.
Но зато можно успеть прочитать больше данных, если они идут последовательно в секторах одной дорожки.
В общем, механический диск - штука крайне медлительная и прогресс CPU и оперативной памяти (не имеющих механический частей и потому значительно более быстрых) в прошлом тысячелетии потребовали вводить всевозможные ухищрения. В частности, операционные системы начали кешировать операции чтения и записи данных в неиспользуемых в данный момент выполняющимися программами областях оперативной памяти. И если с чтением всё просто - точно такая же копия лежит в энергонезависимой памяти механических дисков - то с кешированием записи как-то печальнее. Операционная система отвечает приложению "данные записаны", а на самом деле они размещены в оперативной памяти и будут записаны когда-нибудь чуть позже, может через несколько секунд. И это замечательно работает и ускоряет все операции с дисков. Вот только при критическом сбое системы (например по питанию) данные будут потеряны.
И чтобы дать приложениям возможность попросить систему именно записать какие-то данные в энергонезависимую память и добавили вызов fsync, который синхронизирует кэш записи с дисками.

Повторюсь - для механических дисков позиционировать головки операция очень медленная. Поэтому если вы начнёте читать-писать с механическим диском с 1000 потоков - это будет бесконечно долго. При том, ситуацию для вас всеми своими силами постараются сгладить и планировщики ввода-вывода и кэширование файловых операций. Из-за позиционирования головки механические диски могут давать неплохую производительность на последовательных операциях, но производительность случайных операций у механики удручающая.
Но, к счастью, за последние лет 10 сильно подешевела flash-память и появились SSD диски. Дисками их называют только по привычке, на самом деле никакой механики там уже нет. И параллельная обработка запросов (пусть и за счёт обращений к разным кристаллам памяти) и куда более внушительная производительность по метрике количества операций в секунду (iops) - всё возможно. И, вероятно, со временем будут пересмотрены в сторону упрощения и планировщики ввода-вывода (собственно blk_mq в ядре linux уже) и упрощены другие нагромождения этих десятилетий когда для хранения данных использовалась медлительная механика. У flash-памяти своих интересных фокусов тоже хватает (например, есть не 2 операции чтение и запись, а чтение, стирание, запись - запись возможна только в предварительно очищенную страницу. Отсюда выросла необходимость в команде trim) - но это уже тема отдельных изысканий.

Прямой доступ к оборудованию под Linux

Имеется рабочая машинка с ОС Linux. Требуется получить из консольного пользовательского приложения (ring3) доступ к портам ввода-вывода. Под ОС Windows эта проблема решается следующими способами: драйвер типа userport или giveio -> прямо в программе делаем ввод-вывод через команды asm'а in/out собственный драйвер "виртуального у-ва", который в ring0 делает всю черновую работу и предоставляет некий интерфейс с помощью IOCTL прикладным программам. Пользовательское приложение вызывает соответствующие IOCTL'ы. Какие варианты есть под Linux? Прошу снадбить короткими примерами кода. PS: ес-но root'овые привилегии имеют место быть.

Ответ

Ну, основной способ в Linux следовать тем же путём: делаете модуль ядра, который работает с портами ввода-вывода и предоставляет какой-то интерфейс для приложений, например, создаёт tty или какой-то другой файл-устройство и, возможно, предоставляет IOCTL; а из приложения обращаетесь к этому файлу-устройству и работаете с драйвером через него. Пример приведу позже, если другие не приведут. Однако, кое какие примеры можно легко найти в интернете. Например: Character Device Drivers. И вообще, если вы планируете идти по первому пути, то не мешает пролистать этот The Linux Kernel Module Programming Guide, который является классикой жанра из категории MUST READ. Вот ещё то же (или почти то же), на русском: The Linux Kernel Module Programming Guide (RU). Или вот ещё пример: Implementing a Simple Char Device in Linux Ну и конечно многие устройства при подключении определяются как serial port или что-то подобное и тогда соответствующий модуль ядра создаёт этот самый файл-устройство и тогда вам надо просто понять, что с этим файлом-устройством делать. Второй путь - это использовать user space device driver API. Почитайте, например тут: User-space device drivers

Функции железа и ОС

Прошу пояснить некоторые вещи, которые я опишу ниже. Я много читал о том, как загружается система, какие функции выполняет железо, какие - система, но пока что полной картины сложить не могу.
Итак. Как я понимаю, при загрузке системы сначала просыпается bios. Он проверяет все железо, делает диагностику. Когда он решит, что все нормально, он считывает 512 (не уверен) первых байт с диска, проверяет 2 "магических" байта, и если они говорят о том, что этот диск - загрузочный, то bios начинает выполнять код загрузчика, т.е. этих 510 байт. При этом начинает выполнять не сразу, а записав их по некоторому адресу в оперативную память. Здесь вроде все понятно. А еще как процессор адресует память - постранично - вроде тоже понятно.
А теперь то, что мне непонятно: допустим, я загружаю linux. Загрузчик с диска поднял grub, grub загрузил ядро, ядро начало выполняться. Окай. Но как ядро адресует память? Получается напрямую физическую? Ну т.е. без виртуальной. Тогда другой вопрос. Получается весь user-space код, который адресует виртуальную память, выполняется в некой "песочнице" ядра, которая позволяет транслировать адреса виртуальные в физические? Или же есть какие-то именно процессорные механизмы? И как работает uefi?
В общем, меня интересует то, какие возможности предоставляет процессор, да и железо в целом, а что реализовано на системном уровне, и если можно, то почему оно так работает.
И да, еще интересно, как процессор общается с различным железом вроде видеокарт, и какие интерфейсы он предоставляет для управления этим железом программно.

Ответ

Загрузка кажется только простой, правда, это очень сложный и многошаговый процесс, я постараюсь Вам описать его. Хоть это и будет похоже на маленькую книжку, но я надеюсь, что многим будет интересно это почитать
Вы нажали кнопку питания
Линия PS_ON замыкает на "землю" и происходит подача питания на все железо! ОНО ОЖИЛО!. Блок питания включен. Начинается тестирование блока питания на соответствие всех напряжений требованиям. В случае удачного завершения данной операции, спустя 0.1-0.5с, вырабатывается сигнал Power Good, свидетельствующий о том, что загрузку компьютера можно продолжать. Головки жесткого диска выходят из парковочной зоны, остальное оборудование включается...ПОЕХАЛИ!

Блок питания проверился, а что дальше?
Дальше на специальный вход центрального процессора подается сигнал сброса (Reset). Процессор обнуляет содержимое своей памяти и начинает работу.
В чем заключается начало работы процессора?
Системная память сделана так, что первая команда которую будет считывать процессор после сброса находится в BIOS. Это инструкции по проведению самотестирования. Программа POST выполняет тестирование процессора, оперативной памяти, чипсета, видеосистемы, накопителей, системы управления питанием, клавиатуры, портов LPT и COM (а также подключенных к ним устройств), других компонентов компьютера.
POST завершился, что делать дальше системе?
После того как успешно завершилась процедура POST, вызывается программное прерывание BIOS INT 19h и запускается процедура поиска загрузочного сектора порядок поиска которого установлен непосредственно в BIOS.
Теперь будем искать загрузочную запись?
Да, но сначала немного терминологии, без которой дальше делать нечего:
Сектор - минимальный участок хранения информации на жестком диске равный 512 байтам; MBR (Master Boot Record) - Главная загрузочная запись, она находится в нулевом секторе диска и по сути является загрузочным сектором жесткого диска;
Дальше с указанного жесткого диска BIOS`ом считывается главная загрузочная запись MBR и управление дальнейшей загрузкой передается ей. Далее микропрограмма, находящаяся в MBR, сканирует таблицу разделов на наличие активного загрузочного раздела, после того как системный раздел будет найден, MBR загружает в память компьютера его нулевой сектор и выполняет код находящийся в нем. Загрузочный сектор раздела содержит код операционной системы, которую нужно загружать. В случае, когда на жестком диске нет системного раздела, BIOS отобразит сообщение об ошибке. Если системный раздел будет найден, загрузка продолжится. Все вышесказанное относится к запуску абсолютно любой операционной системы.
Хочу загружать Windows!
А теперь, если вы например загружаете WINDOWS, после всего вышесказанного, загрузчик ntldr который находится в системном разделе считывает из загрузочного файла boot.ini информацию о количестве операционных систем и их расположении, и предлагает пользователю выбрать из списка операционную систему.
Система выбрана!
Отлично, загружаем ядро в память, система готова к работе, но как же ядро управляет распределением памяти?
Что представляет собой ОЗУ?
Логически ОЗУ представляет собой упорядоченный (одномерный) массив элементов. Элементы (минимальные адресуемые единицы МАЕ) пронумерованы, причем номер каждой МАЕ фиксирован и определяется схемотехнической реализацией устройства памяти. Номер элемента реально существующего в системе устройства памяти в дальнейшем будем называть адресом (Address) этого элемента. В каждой такой ячейке может храниться двоичное слово фиксированной длины
Распределяем память
И так, адресная шина процессора работает...Нет, это слишком долго.. Будем считать, что процессор работает с диапазоном последовательных адресов от нуля до максимально доступного в системе адреса (в зависимости от количества оперативной памяти) и может при необходимости обратиться к любому байту в этом диапазоне.
Если сгенерировать для программы адреса, как они расположены в физическом виде, без виртуальной, то одновременное выполнение двух программ просто невозможно из-за перекрывания данных одной программы другой. Например, компилятор генерирует адреса для виртуального адресного пространства заданного диапазона, а устройство управления памятью, называемое диспетчером памяти, транслирует виртуальные адреса, сгенерированные компилятором, в адреса ячеек, расположенных в физической памяти. Компилятору нет необходимости знать, в какое место в памяти ядро потом загрузит выполняемую программу.
Конечно же виртуальная память сама по себе ничего не хранит. Виртуальное адресное пространство — это просто абстракция, но оно определенным образом поставлено в соответствие физической памяти. Отображение виртуальной памяти на физическую осуществляется через аппаратно реализованные страничные таблицы. Аппаратная часть непосредственно выполняет отображение, а ядро управляет таблицами и их конфигурацией, алгоритмами замещения и т.д.

Диспетчер памяти, это не какой-то процесс! Это устройство и оно может находиться на микросхеме процессора или на отдельной микросхеме рядом с процессором.
Вы обратились на какой-нибудь 32 битный адрес, то модуль разделяет его на 20 разрядный адрес страницы и 12 разрядное смещение внутри страницы. Все это называется прозрачной работой с памятью, когда программист даже не подозревает о существовании страничной организации памяти. Хотя, есть страничная организация памяти с процессом сегментации, при котором программисту требуется знать о существовании сегментов.
UEFI
Код микропрограммы UEFI написан на C и выполняется в современном 64-битном режиме. По сути это полноценная операционная система, которая работает на неограниченном уровне доступа к ресурсам "ring 0". Выполняется фаза PEI, и DXE перед загрузкой. Я не вижу смысла здесь все это описывать, вот картинка вам:

Источники: IBM.com, Habrahabr.ru, Overclockers.ru, Таненбаум Э. "Архитектура компьютера"
Для более четкого понимания работы компьютера и решения ваших вопросов, присоединюсь к ответу @AlexanderBlinov, прочитайте Архиктуру компьютера, очень полезная книга.