Загадка ноутбука Acer

[@Dark481516]

- Здравствуйте, это канал об аниме? - Да. - Как работает клавиатура без южного моста под FreeBSD?

[@антонантонов-с8з]

Dark481516 XD

[@hey_dont_cry6047]

@@антонантонов-с8з lololol

[@zemlyanin9]

Классика не устареет никогда! :)

[@СергейМахмудов-ч2ф]

BSD не верит BIOS и читает контроллер клавы впрямую (режим прямого доступа к нему - Gate A20 == Normal в BIOS), а остальные верят BIOS - там значение Gate A20 == Fast (доступ к контроллеру через чипсет). Контроллер клавы это вполне себе отдельный чип, не часть моста. У него есть даже своя оперативка, встроенное ПЗУ с прошивкой (иногда обновляемой производителем бука!), и т.п. Подключен он в несколько общих шин данных, и может общаться с CPU как напрямую, так и через чипсет. В данном случае BSD нашла ответ неинициализованного чипа при опросе GPIO, опознала как контроллер клавы и заработала с ним в прямом (медленном) режиме. Чудес не бывает.

[@shynodaa]

+Сергей Махмудов (Wild Creator) это как включить винду в безопасонм режиме, когда все лагает, только это Клавиатура в безопасном режиме

[@ArtomU]

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

[@СергейМахмудов-ч2ф]

+Обзоры гаджетов от ArtomU То что Ethernet работает напрямую с CPU вас тоже смущает? Или почему 8 bit ПЗУ BIOS читается в 128 bit RAM, с более чем 10-кратной разницей тактовых частот? А каким боком тут системная шина? Все шины (а их много и по разрядам, и по частотам, и по типам) контролит север, через него и общаются они. CPU же работает в едином адресном пространстве, куда в разные диапазоны отражаются все устройства платы, в т.ч. и этот контроллер. Что тут удивительного-то?

[@Angellfear]

Юг помер по усб. видел таких кучу. суть вот в чем. Клава подключена не через SUPERIO, а через KBC, а именно ENE KB910Q подключен по LPC к ЮГУ. если был бы мертв KBC, то ноут бы даже не включился. так как он управляет всеми питаниями и транслирует загрузку биоса в ЮГ ,через шину LPC (биос висит на KBC ). так вот когда USB мертв при его инициализации зависает ЧАСТЬ ЮГА, так как не может снять прерывание (в данном случае еще и звук и модем), а с ним и все что на шине LPC. BSD же инициализирует USB по другому, там не линукс драйвер, ВИНДА же вообще не грузанется так как будет фатальная ошибка по прерываниям . ну короче это как то в кратце. есть кста метод отжига усб контроллера. хотя не знаю прокатит или нет на амд, не проверял. google: схема LA-3211P страница 1.

[@gabrielbatory1471]

+Сергей Махмудов (Wild Creator) Спасибо за то что уталил моё любопытство.:))))

[@ClusterMeerkat]

Я всегда говорил, что FreeBSD решает :) Это явно работа чертей.

[@павелграчев-ф6ш]

+Cluster on KZbin кластер привет ты видео собираешся выпускать??? ато заждались

[@ClusterMeerkat]

+павел грачев Привет. Недавно же было :)

[@павелграчев-ф6ш]

малоооооо большееее они у тебя классные!!!! хотя понятно что они очень трудоемкие

[@nukezzzzzz]

Бачило и Кластер кроссовер! Круто!

[@MrZloyPupsik888]

+Cluster on KZbin. мало, давай еще=) и желательно что то по приставкам sega

[@KKKOMODOR]

Сисадминство - очень точная наука, бубен надо держать в правой руке

[@HaroNRIPley1]

+KKKOMODOR Не всегда. Я, например, левша, мне по оф. документации моей модели сисадминского бубна ОБЯЗАТЕЛЬНО положено держать его именно в левой руке

[@KKKOMODOR]

+HaroN R.I.P.ley у меня на работе станок сгорел - ремонтники тоже ссылаются на некую заводскую магию. Давно заметил специфическое мировоззрение околоэлектронщиков всех мастей - оно очень близко мировоззрению средневекового крестьянина: а фиг знает, что за чертовщина творится, молиться надо почаще и задобрить духов.

[@Коба-ю3ь]

Стив, ты живой!!!)))))))))))))))))

[@БачистиллШоу]

какого же было удивление оперативников....

[@BachiloDmitry]

+Бачистилл Шоу их как душем окатило

[@KOT040188]

+Бачистилл Шоу Когда они узнали, что Брюссэль столица Бельгии…

[@render2004]

+KOT040188 коя и является столицей бельгии

[@KOT040188]

Андрей Горленко КО, ты озверел! ヅ

[@strelok193193]

Предлагаю вбить в ноутбук десять железнодорожных гвоздей и посмотреть сможет ли FreeBSD запуститься!

[@BachiloDmitry]

+Yauheni Novikau На данном этапе я уже боюсь проверять. Вдруг запустится. Я тогда закричу и убегу.

[@МастерХ]

+Дмитрий Бачило Надо вбить в ноутбук осиный кол! И побрызгать священной водой…

[@peace__duke]

+Unfert Hartemann а причём тут HDD? Речь то о сгоревшем южном мосте.

[@kigastu]

+Unfert Hartemann got 2 usb sticks, windows can't see it, but in os x it works perfectly

[@Коба-ю3ь]

А ты представляешь масштабы массового психоза, если запустится?)

[@МихаилЕрмолин-х5у]

Фряха просто подглядывает через вебку)

[@KOT040188]

+Михаил Ермолин Вариант!

[@begemotich]

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

[@quadrathell]

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

[@sadjacgues7723]

ты прав. задержка как раз из-за того что при нажатии идёт запрос в полное оброшение ко всему чипу моста а в ответку илут ошибки которая фря проглатывает и частично принимает рабочие команды например по клавиатуре которая в итоге всё ж не сгорела в чипе.

[@dr.cheater8927]

+Sad Jacgues Надо бы dmesg посмотреть :)

[@NesterWillow]

Предположил что фряха по другому инициализирует или опрашивает устройства, а вы уже всё объяснили.

[@Werwolf2517]

+Quadrat Tardauq > В винде и убунту а какие нибудь другие дистры на базе linux ядра мэйби тоже смогут работать

[@quadrathell]

Просто фря не заморачивается обработками ошибок, она тупо на низком уровне обращается к порту клавиатуры и та отвечает. А вот винда и убунту всё делает через подключаемые драйверы для расширения возможностей, на каком-то из уровней напаривается на ошибку и просто отваливается.

[@RavenBlack849]

Там на самом деле все просто! В ноуте этом опрос устройств и переброс инициализации ходят по младшим 4 битам системной шины. Винда и *.nixы опрашивают устройства один раз при запуске обвязки ядра, то есть на южаке успевает запуститься кварц тактового генератора и он при опросе совершенно спокойно для своего окружения отвечает "Все готово, типа давай работать!" А вот мультик тактуется по внешней шине, и пока опрос идет тактовых импульсов нет. Но вот ядро поднялось. У BSD есть циклический опрос внешних устройств и мультик с контроллером клавиатуры от этих тактов спокойно заводятся на скорости соизмеримой со скоростью 300бод/сек. То есть для системы становятся своеобразным удаленным терминалом со сверхнизкой скоростью! Фряха серверная ось! Ей постоянно надо знать что у нее ест в окружении а что отвалилось!

[@begemotich]

Откуда величина "300 бод/с"? Может все-таки 280 бод/с, потом уже идет 1400...

[@TheSnos15]

откуда величина 280 бод/с? может всё-таки 280 бод? :)

[@JohnnyBGoode-fc8gw]

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

[@kardanium]

Ну, перегрев чипа не означает полный выход его из строя. Есть предположение, что он частично деградировал. Например, он не может генерировать прерывания, но какая-то его часть продолжает работать. Может во фряхе реализовали тест железа при загрузке драйвера и если некоторое железо не генерирует прерывание, то оно начинает опрашиваться программно? Это надо копаться в исходниках или документации FreBSD. UPD: Вспомнил. У Фряхи есть такая фишка как Device Polling. Это как раз связано с решением проблем с прерываниями. Тут скорее всего та часть чипа, которая отвечает за выдачу прерываний процессору просто не работает из-за деградации.

[@MrGvinblayd]

+Андрей Батищев Поддерживаю, если б южник умер то ни винт ни ПСМСИ карта не работали б. Да и биос не смог бы считаться...

[@vladimirivanov7724]

Возможно, винда и линух работают с Extended IO через DMA (который мертв), а фря - в режиме прямого доступа к регистрам управления (PIO). Который по каким-то причинам остался жив.

[@narodnyservis]

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

[@Bi4Paket]

Я конечно не на что не намекаю...но я считаю что причиной данного поведения твоего ноутбука являются...Фиксики. А кто такие фиксики - большой-большой секрет! На этом объявляю съезд в Уветичах закрытым! Всем спасибо, все свободны.

[@Evgeniy.Pechorskiy]

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

[@СутенерВашихЖен]

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

[@olegparhimchik]

как же я рад видеть новые видео от Дмитрия

[@mksav1n]

Такой эффект обусловлен теми "остатками" ю.моста, которые еще могут функционировать. FreeBSD обращается к ю.мосту по старой технологии, которой современные ОСи не пользуются. (Ну, или частично) Если разбираться по подробнее, то этот эффект можно понять, представив такую картину: У вас есть губка (играет в роли сгоревшего моста) и вода (сигналы). Если подавать сигналы помаленьку (старая мало-битная технология IO), то губка спокойно их пропускает, но если залить сразу пол ведра (типа новая технология), то она часть пропустит, часть впитает (задержка сигналов), из-за этого новые ОС будут приравнивать такие сигналы, к тем сигналам, которые ОС получает от погодных условий или от не совершенства оборудования, в следствии этого она просто "забивает" на них. Ну, простите за орфографию, пишу с телефона, ну и в прочем, думаю, вы уловили мою мысль.

[@djdocent]

FreeBSD он такой) Не удивлюсь, если экран ноута разбить молотком, то во FreeBSD можно будет поиграть на этом экране в Doom 2, в то время как в выключенном состоянии там будут ошмётки от экрана.

[@senseyZ]

Приветствую, в твоем буке, клава , тачпад и микросхема BIOS подключены к микросхеме мультиконтроллера, именно для них, который по 4х битной шине, общается с югом. Так как южный мост частично вышел из строя, то могу предположить, что FreeBSD на уровне драйверов, может обращается на прямую к мултиконтроллеру , не обращая внимание на ошибки южного моста, так как шина до мульта исправна (бук загружается, BIOS считывается правильно). Именно поэтому у тебя на панели задач показывает, что звук исправен, а именно звук, usb и BT у тебя в неисправной части юга и не работают. Ну как-то так , в двух словах. Чтобы стул наладился. :) Здоровья и удачи.

[@BachiloDmitry]

+SenSey Z Да, похоже на правду, хотя с моей точки зрения это, в общем, и так очевидно было. Вопрос больше в том, где в коде FreeBSD прописано обращение в клаве, которое работает, и (риторический вопрос), почему этого кода нет больше нигде. LPC-контроллер виден во всех системах и числится исправным, не понятно, почему они им не пользуются, ведь вроде бы именно через него на этой мамке завязан ввод-вывод.

[@senseyZ]

+Дмитрий Бачило Приветствую, я в программировании дров не силен, но могу предположить, что оно, прямое обращение, было на ранних версиях не только в FreeBSD, а затем в процессе оптимизации кода, могло быть убрано за ненадобностью в современных системах, а в FreeBSD трогать не стали ввиду ее ориентации или lid у прогеров был умнее. Можно попробовать поставить старые дистрибутивы Linux, а в друг? :)

[@visualyt]

Дима отнеси комп в церковь, там клавиатура должна отказать

[@FooFighter477]

Вселенная говорит тебе, что твоё предназначение - пропатчить KDE2 под FreeBSD на этом ноуте!

[@Aizek1428]

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

[@BachiloDmitry]

+Алексей Петрухнов обязательно

[@qwertyklaviatyra]

+Дмитрий Бачило Дмитрий уж не знаю где ещё к вам обратиться.Имею ноутбук MSI GE 70 0ND.В нем 2 видеокарты: Intel hd и GeForce m660. Так вот,в Ubuntu Dota 2 выдаёт ~ 30 fps, а в Linux mint ~60 fps.Можно ли что-то сделать с Ubuntu?

[@qwer2812]

+nosmiles77 Можно что-то сделать с Убунту

[@bombawotchannel6930]

+Дмитрий Бачило Робота ДЛя агентов Малдера и Скалли! Интригу видержал, спс! смотрел как блокбастер)

[@bfalmer]

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

[@krmaster4610]

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

[@1910zaki]

+Master Kr или же система одержима дьяволом...

[@miroyasen]

+Master Kr Прям терминатор 2, когда у него ноги и руку оторвало, но он всё ползёт упорно))

[@muztiktok7437]

+Master Kr правильно говоришь у меня южный мост поврежден был, и она жёсткий диска не видел настольный пк!!1!

[@duhinthesky]

Все-таки нужно разбирать и смотреть мат. плату. По другому в этой чертовщине не разобраться. Я чуть не перекрестился, когда во free BSD клава заработала : )

[@HuntressHusbad]

куплю икону с FreeBsd и приклею к южному мосту :D

[@Creepyhauz]

получишь плохой охлад и как следствие дохлый мост )

[@zl0y]

мне нужна такая наклейка на мою девятку!

[@elenvernieded4979]

@@zl0y , твоей девятке понадобится не одна маленькая, а несколько больших наклеек.

[@ZCris04]

@@Creepyhauz ну дык клава будет работатьж так что начхать)

[@MrMistyGear]

Вот это огонь! Обязательно запили видос, если найдешь ответ.

[@JohnRiZZZ]

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

[@TheWertuoz]

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

[@lionlinux]

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

[@olegorlov7945]

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

[@Zi0niC]

+Oleg Orlov, согласен. Я тоже сразу об этом подумал.

[@zlyjbober]

+Oleg Orlov Клавой рулит не южный мост, а мультиконтроллер он же kbc контроллер

[@olegorlov7945]

zlyjbober сори оговорился, .. *Та часть южника которая отвечает за связь между клавой и мультиком...

[@vladimir7573]

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

[@XAMELIONFILM]

Димас насмешил от души!!!! Респект!!!!!!))))))) Под столом валялся!!!!!!!))))

[@1Neep]

Может он не сгорел вовсе? Подпалился, перегрелся, испортился, но остался в рабочем состоянии на столько, что FreeBSD его каким то образом читает, а остальным системам такие повреждения не нравятся, ибо они более привередливы. Есть один супер способ проверить, южный мост один фиг испорчен, надо выпаять его и посмотреть, что будет вообще без южного моста в FreeBSD.

[@Valentin_I]

Мне нравится этот теплый ламповый звук от камеры ^-^

[@АлексНиколсон-ш3л]

Нехера не понял но смотрел с удовольствием!)

[@tvoy]

+Паноний Клейкие Эй! Это мой коммент в каком-то прошлом видео:D

[@АлексНиколсон-ш3л]

Твой Игровой - канал о настольных играх ты думал ты оригинал!?

[@WAXT3R]

истина

[@AWE_ZIOLIO]

что если задержка ввода связана например с повреждением контроллера прерываний и\или генератора тактовой частоты? тайминги обращений устройств в винде и линуксе могут отличаться от FreeBSD ?

[@IAlexey84]

Обычно, у южного моста везде понатыканы TVS диоды и самовосстанавливающиеся предохранители (например на USB), которые со временем дохнут, и КЗ пробивает часть микросхемы южного моста. Наиболее часто такая проблема случается с питающимися от USB устройствами и теми разъемами которые подключаются и отключаются постоянно и на которых возникают статические разряды... А конфуз скорее всего связан с тем, что у каждой нормальной микросхемы есть флаги готовности и управления потоком, на отдельных функциональных блоках, причем эти блоки могут быть довольно крупными и включать различный функционал. Поскольку микросхема сгорела, то ни BIOS, ни дровишки стандартные так и не получают ответа готовности и/или управления потоком и просто ожидают их бесконечно (от сгоревшего функционального блока микросхемы), а FB скорее всего просто плюет на флаги и читает и посылает данные микросхеме, функционал которой (куска блока) явно недобит :)))

[@pixelfullhd]

Такого финала видео не ожидал, теперь тоже не буду спать

[@FIRSTQWERT]

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

[@pcaptanovsky]

[15:57] "...либо система одержима дьяволом..." конечно, одержима дьяволом, а точнее BSD демоном, Beastie который

[@yevgenylebedev9927]

В давние года мы баловались с MS DOS, отрабатывая аппаратные прерывания. Клава могла работать как с прерываниями так и без оных (я уже не помню какое резервировалось на клаву, я и CONFIG то уже не напишу) и выглядело это точно так же - с аппаратными прерываниями быстро, с программными - медленно. Возможно в этом дело. Южник сгорел не весь (там куча независимых контроллеров): аппаратные прерывания, на которые расчитывает видна и линух, не отрарабатываются (ноутбучная клава - это контактное поле с собственным контроллером и связана c южником по шине PS/2 которой снаружи нет, а так бы PS/2-клава тоже работала бы), а фришка в них не нуждается. Если флаг прерывания клавы не выставлен - она опрашивает PS/2 в цикле... По-моему так...

[@MRooodddvvv]

Плюсую. Там похоже умерли прерывания. Можно попробовать поставить DOS и поработать с контроллером клавы напрямую.

[@Bublerkin]

+Yevgeny Lebedev Верно. К клаву можно читать двумя способами: через аппаратное прерывание IRQ 1, и через порты 0x60, 0x64. Конечно, поллинг портов клавы это архаизм, поэтому линукс и винда (тем более, десктопные) даже не допускают вероятности отсутствия прерывания. А серверная фряха должна поддерживать всё железо от рождества христова))

[@MRooodddvvv]

Le Bublerkin это такой архаизм, что даже в DOS-е читали по прерываниям. точнее вообще-то обработчик был в BIOS а DOS только читал из программного FIFO через int 16. но это в теории а на практике все кому не лень перехватывали прерывание клавиатуры ! одни только РУСИФИКАТОРЫ чего стоили !

[@yevgenylebedev9927]

MRooodddvvv У меня есть две рабочие мамки на 286 AT (там, конечно, архитектура попроще: никаких южников и Super I/O, все висит на системной ISA 16) и BIOS на них опрашивает порт KBD (тоже, кстати, системный, а не шина PS/2) в цикле ожидания ввода, и можно без клавы (DIN5), потыкать по контакту DATA и получить случайный символ. Я это к чему? - а какого хрена современные BIOS не делают то же самое. Раздули UEFI до 8 mb, BIOS превратили в Life OS... Нет, все понятно, сломанный комп надо выбросить и купить новый - все по законам капитализма...

[@MRooodddvvv]

Yevgeny Lebedev минуттточку! а разве на современной если потыкать проводком не будет случайных символов?

[@sshh88]

Спасибо за подобные видео. Интересно послушать

[@1234mifa]

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

[@frolaleksan]

+Михаил Климчук вспоминаются ICH5, которые шли на серии P4 с 800 шиной. По их поводу на всех железячных форумах были целые простыни на тему: повально горят мосты ICH5/ICH5R (пример такой простыни: forum.ixbt.com/topic.cgi?id=9:53483). Был какой-то косяк по USB-шине, который приводил к ее сгоранию в произвольный момент времени, причем сами мосты сгорали в прямом смысле со светошумовыми эффектами. "Лечили" их шокотерапией - специально добивали дохлые USB-порты и продолжали пользоваться, поскольку остальное в этих южниках оставалось целым.

[@bich_vasia]

Где-то читал, что причина не в мосте, а в его питании. У меня есть старый комп - пень 4 с ich5, мост достаточно холодный, хотя на нем нет радиатора. А на современной плате с p67 южник в кипяток, если не хорошая вентиляция корпуса, может сгореть вполне себе. Такая температура вряд-ли является причиной зверской передачи данных

[@ИльяНаумов-т3ч]

+Михаил Климчук, сгорела одна из шин по которым работает юг (USB, PCI) но не LPC по которой общается юг с мультом (i/o , рабочим), по которой опрашивается биос, и по которой клавиатура даёт о себе знать. во freeBSD вероятно сгоревшая шина еще не задействована в Юге - вот он и не пытается полностью ограничить свой функционал. это как если у тебя пожар в двухкомнатной квартире, и пока ты не увидел дым и не открыл дверь во вторую комнатку - где у тебя уже всё сгорело к чертям, ты можешь в другой комнате сидеть и постить коменты к видео на ютубе

[@TheTalants]

А не может быть так, что по питанию одна фаза давала завышенное напряжение, из за чего южный мост сильно грелся, и от перегрева, часть контактов от BGA микросхемы отпаялись. При загрузке Windows и Lubuntu, система пытается провести тест оборудования, видит что Южный мост "повело", и он его просто исключает из работы (например издохло там DMA в виду не контакта), а FreeBSD работает на прямую с устройствами миную тот же DMA... В общем фиг знает. Колдунство.

[@Metamorf2011]

Есть определенный промежуток времени, в который устройство должно ответить при опросе устройств. На данном примере клава не отвечает и не инициализируется. А "фри бсд" видимо пофиг на опрос устройств. ОС просто принимает сигнал с клавы.

[@AlexanderEmashev]

Любопытная ситуация. А звук камеры, довольно прикольный, ламповости добавляет в ролик =)

[@DenShaver]

+Alexander Emashev Я вообще думал, нахрена Дмитрий заморочился этот звук в ролик добавить? А оно вон оно что! А насчет ламповости согласен.

[@evgeniy4775]

А как тогда работает HDD, он же тоже подключен к южному мосту?

[@Crintew]

возможно на данной материнки/мосте есть еще один канал ввода вывода, раз бсд считывает ее довольно медленно, или какой нибудь стек для ввода или событий

[@sabir20002000]

клава в 90% ноутах подключена к мультику, а не к южному мосту, после мультика сигналы хитро переходит к северному мосту. Ктомуже если не выпаян южный мост- он может продолжать общаться с северным мостом на кастылях. Лучше выпаять южный мост. зы: южные мосты могут так выгорать если замыкается на шину данных по юсб +5в, или флэшку сгоревшую сунули или мышку и т.п.

[@mmmonster6891]

+sabir автор видео явно не бывает в хороших сервисных центрах и подобных чудес там случается настолько дофига, и разными волшебными способами всё иногда работает, а иногда например у вас при искажении изображения по LVDS запросто может стать именно "сгоревший"(лол) южный мост, при том, что всё остальное работает идеально. Бред полный насчет оплавленности микросхем южного моста, за более 5 лет видел больше 50 таких ноутбуков, нигде ничего не плавилось, максимум что бывает это дырка в кристалле, и то для этого надо непонятно каким образом его закоротить. Ёпт, посмотрел дальше, этот 5100 как раз имеет знаменитый мост SB460, чуть ли не единственный в семействе ATI с "детской болячкой", в отличии от интеловых южников, которые дохнут обычно сразу с отсутствием инициализации. Насчет мульта всё верно, видимо догадаться хотя бы разобрать осмотреть материнку для начала и сделать замеры относительно рабочей платы(пойди найди её, хаха) удалось во второй части.

[@ice2heart]

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

[@kosmich411]

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

[@skobkinru]

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

[@zazclub36rus]

Сталкивался с таким на нетбуке Toshiba. Но, ставил я вместо винды ALTLinux. Тоже всё работало не спеша.

[@matrix-brz]

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

[@bagor007]

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

[@crapasanya]

хард можно было вставить в другой комп, загрузиться с него, поставить туда, например, team viewer, поставить все на место и через удаленное управление поставить дрова, все! В топ!!!

[@sergeygedzenko4192]

очень итересный обзор ждем продолжений)))

[@oldgoodrandomroutine]

C 50000 подписчиками!

[@PATFIZO]

более миллиона просмотров на канале! поздравляю!!!

[@YanPashkovsky]

Может у вас чип сгорел не до конца. Линукс / NT проверяет чип на оишбки, в то время как бсд проверки не делает и работает на авось. Интересно как там NetBSD бы повела

[@denismorgun82]

Так и есть, чип повреждён частично. Если его не проверять и работать на абум, то есть вероятность что что то из этого получится. Что и наблюдается :)

[@supaplexy]

+Yan Pashkovsky у меня так виндовс отказывался загружается, уходил в синий экран. потом поставил линух все пошло. Видимо винда и убунту делают проверки, т,е прогоняют мини тест. А бсд тупо запускает без проверки

[@Red58rus]

Когда клава во FreeBSD заработала, у меня в голове начала звучать тема Воланда. Да и логотип у неё соответствующий.

[@bayan1059]

Посмотрел этот видос, а потом думаю-зачем?)))

[@brianshoubert7803]

У меня на вскидку два объяснения: 1. Фря умеет создавать "кротовую нору" в ткани пространства-времени и обращаться в прошлое. Таким образом она может работать с системой до того момента, как сгорел южный. 2. На материнке есть потайной, секретный мост, который, при сгорании северного или южного мостов, берёт на себя часть их функционала. Впрочем, это только догадки... =)

[@vladgeo4888]

Хорошо вам, у вас все просто. Я свою историю уже рассказывал, на ру-борде, никто мне там помочь не смог. В 2014 году, сижу я с ноутбуком на кухне, в сети серфю. Попадаю на страничку, где рассказывается о том, что такое ФИДО, что такое бибиэс, что такое USR 14400... Обуревает меня ностальгия, а тут еще на страничке выложены звуки коннекта разных модемов. Натурально, те самые трели, которые модемы пищали друг дружке в начале девяностых, чтобы потом вы, с дружбаном из соседнего дома, могли вместе провести вечер в подземельях DOOM II. В общем, включаю я воспроизведение этих самых звуков коннекта, не помню, какого модема, Courier или Motorola, не помню ни скорость соединения, ничего, что говорилось в описании к той mp3-шке. Слушаю трели, и тут... у меня за спиной.. мой холодильник Стинол... отвечает на этот запрос коннекта... По-своему, по-холодильничьи, у него это ниже звучит, глуше - но я не могу ошибиться, он реально отвечал на звук запроса соединения, тарахтел и пыжился во всю! И, когда я, в шоке, включил наобум следующий файл из ностальгического списка - его тарахтенье немедленно умолкло! Холодильник опять слушал. Но на этот раз уже ничего отвечать не стал, как будто вторая трель не являлась условным сигналом, на который надо было отвечать! Каюсь, после этого я выключил нахрен ноут, сбежал на балкон и тихо сидел там, пытаясь понять, зачем оно так все. Так же, надо сказать, что с 2006 по 2010 годы я так часто летал в служебные командировки в страны вроде Турции, Эмиратов, Кипра, Греции, что мне пришлось даже менять загранпаспорт из-за того, что там не осталось свободных страниц для виз. Хотя никакой секретности в моей работе не было, она была связана с туризмом. Тем не менее, в том же 2014 году на своих компьютерах я столкнулся с тем, что впоследствии было описано как badBIOS. Это не относится к данному случаю напрямую, но косвенно указывает, что несанкционированное проникновение в мои цифровые устройства скорее всего имело место. P.S. От того холодильника я впоследствии избавился, но попасть к нему все же могу, он в другой квартире, у другого человека.

[@NorthernRAY1]

+Vlad Geo ...)))

[@shevitracktor5425]

+Vlad Geo у меня стиралка может общаться с сервисом по телефону с помощью спецсигналов, но такую передачу (видимо кодов неисправности) нужно ручками включить, поднести телефон к машинке и на том конце расшифруют писк. Может тут похожий принцип. Может в сервисе есть спецсигнал, на который возбуждается ваш холодильник и передаёт служебную информацию..

[@vladgeo4888]

Евгений Л О-о-о!!! Спасибо тебе, добрый человек, ты первый, кто не крутит пальцем у виска, а дает технически обоснованное объяснение!

[@HAPKAH]

+Vlad Geo Рассказы писать все могут, а вы снимите на видео. ЗЫ. Спасибо за ностальгическое вступление) .

[@vladgeo4888]

HAPKAH Я уже локти откусал за то, что сразу не снял. Если получится при случае, когда с аппаратом снова увижусь - сниму.

[@Dimoven]

Это если не сказать, находка века!)) То что большой брат привёз нам эти приставки, уже контроллируя ввод, то антивирусы и прочую байду для шифрования, нам придумали, чтоб крепче не верили в это))) И то как ребята глубоко знают архитектуру обхода, то это скорее намекает, что оно изначально не очень из Free BSD, то есть ему помогли обрести форму)))

[@vladkalmar]

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

[@sfsdgdrfgdf]

+BorisTheBlade Вот только винды и лини вполне себе работают на железе середины 90х, пусть и со скрипом. XP запускается на первопне, семерка на второпне. Но тут может еще глубже копать надо. Правда надо понимать, что работа в реальном и защищенном режиме и их комбинация - это разные вещи.

[@АлексейВасин-м2п]

Я требую его разобрать, почистить и прогреть. Будь мужиком! Вероятнее всего где-то отошли контакты и что-то замкнуло от этого и перегрев и заплавление пластика. При этом он частично работает под фряхой.

[@HCHittCliff]

+Алексей Васин ЮМ в компьютерах часто выходит из строя, а особенно в ноутбуках так как охлаждение в них хуже чем на стационарных компьютерах. Так что факт того что сгорел именно от пыли может быть ложной, так как при большом подключений USB устройств к компьютеру нагружает этот бедный чип.

[@vetalos]

Супер IO скорее всего жив, и он общается с клавой, а так же заведует дежурным питанием. Юг может выгореть по разному и после такого выгорания черт знает что потом происходит с его кристалом. Возможно какие-то прерывания, с зависанием, с горем пополам таки долетают от клавы (мультика) до места назначения, а драйвера win и linux просто не могут корректно их обрабатывать. А производительность Фряхи при этом не страдает? PS Интрига держалась до последнего, я все думал, не может же Бачило какую-то банальщину запилить )))) В конце очень удивился.

[@ValentinSevostjanov]

+Vitaly Titarenko поддерживаю и развиваю мост состоит из блоков с разаличными каналами питания и мультик может работать в обход моста или вернее отключив питание с проблемной области но оставив живые. Воможно БСД на уровне железа заставляет мультик обходить ЮСБ ну дальше работать а остальные системы работают по стандарту есть проблема нет питания.

[@vitiok78]

Наверняка южный мост сгорел не полностью. Линукс, винда, биос и прочее делают запрос, устройство выдает ошибку, и система просто игнорирует его. А фря, видимо, игнорирует эту ошибу и упорно продолжает общаться с нерабочим устройством. Вот это нерабочее устройство и выдает то, что может. Фря это подхватывает и создается видимость нормальной работы. Это скорее плохо, чем хорошо, ведь система фактически сбоит, вместо того, чтобы защититься от нерабочего устройства.

[@aquavisunixnik]

У меня как то давно история случилась. От скачка напряжения вырубился ПК, и так больше и не включался до определенного времени, заниматься мне с ним было лень и я его забросил примерно на год. Потом как то было скучно и я его включил и он заработал, но система Windows XP отказалась запускаться, пробовал установить с разных носителей, и даже разные системы Windows начиная с 98 и заканчивая XP, всё вешалось намертво на определенном моменте. Но абсолютно любой Linux и *BSD нормально устанавливался и работал. Шайтан коробка.

[@DrLithium]

Может фря нащупала какой-нить резервный ЮАРТ и зацепила по нему клаву?А в самой фрюхе можно ж выцарапать, что и как с клавой как с девайсом?

[@kail815]

Этот вопрос нужно отправить на передачу "Что? Где? Когда?" :D

[@НикДёмин-б3ф]

FreeBSD видимо умеет работать с клавиатурой через шину lpc. На шине lpc висит микросхема flash bios. Делаем выводы что южный мост отчасти работает(возможно он не сгорел вовсе а перегрелся и отпаялся). Также на lpc все gpio, контроль вентиляторов, контроль температуры. В операционной системе определяется как некий "ISA bridge"

[@vhemasterelectronics125]

Не зря логотип FreeBSD - дьявол. :D Нужно подробнее изучить архитектуру ПК... Как писали ниже, возможно есть какой-то вариант для связи с SuperIO. Дима, попробуй выпаять юг. Если клава останется рабочей во фришке, то есть левый вариант опроса клавы, который в винде и линуксе не задействован. Если нет, то тут уже особенности южного моста и данного случая. И было бы интересно проверить на другом железе с этой проблемой

[@narodnyservis]

+VHEMaster - Блог Электроники не останется она там рабочей :( Смотрю вот в схему, и вижу что без моста никак

[@vhemasterelectronics125]

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

[@narodnyservis]

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

[@vhemasterelectronics125]

Народний сервіс Я это же и имел ввиду :)

[@MaelsPrower]

Есть теория. Архитектуру ЭВМ проходил довольно давно, потому могу что-то напутать\наврать. Все этот проц, и любой другой IBM-совместимый обратно совместим с 8086. Насколько я помню, 8086 умеет обрабатывать информацию клавиатуры по средствам своих инструкций (отправка кода символа, если память мне не изменяет). А так, как в те времена южным мостом даже и не пахло, эта функция жила и здравствовала, с появлением онного, про неё и забыли. А она есть. Не исключаю правда и обратного, что со временем за не надобностью она подверглась выпиливанию, как тот же 3DNow от всё того же AMD, но думаю, что во времена того проца, об этой функции даже не думали. А "чертяка" просто не обнаружил контроллера клавиатуры, и стал использовать встроенные инструкции процессора, о чём и было сказано автором. Это и объясняет задержку при вводе.

[@BachiloDmitry]

+Маелс Провер Ну да, версия вполне состоятельная, я и ожидаю её подтверждение, видео уже передано куда надо.

[@narodnyservis]

+Маелс Провер Кстати да. Вполне.

[@sfsdgdrfgdf]

+Маелс Провер Уж не инструкции точно. Но PC XT имеет несколько другую реализацию клавы, нежели AT. Вот порты ввода-вывода можно копать. Тут надо смотреть референс мануал на XT/AT.

[@VladimirZhurkin]

+Дмитрий Бачило фраза сгорел, не совсем верна. У нас чип bga, явно был его перегрев и вот тут самое интересное. Чип от сильного нагрева отпаялся. Тогда достаточно его отпаять и припаять обратно, восстановив все шарики на bga чипе. Придется искать трафарет, но в мастерских обычно есть. Заодно можно примерно на глаз увидетб состояние чипа. Попутно от нагрева могли выйти из строя конденсаторы, сопротивление итд. Надо визуально просмотреть все по пути к чипсету, ну и доставать как минимум хороший тестер , как максимум осциллограф для проверки. Все эти Феди могут привести к частичной работоспособности машины. Ну и вообще почитать даташит на чипсет для большего понимания, что конкретно он делает .

[@Ha36ykBbI]

я как нуб склоняюсь к версии про беса

[@PolzyusSam]

значит надо просто сходить в церковь и все заработает

[@glebas999]

+сергей я Точнее, перестанет работать.

[@Ha36ykBbI]

сергей я Вместе с буком

[@PolzyusSam]

Петя Петров и в святую воду его окунуть )

[@HAPKAH]

Серверу не нужена работа с носителями? И что вы подразумеваете под "сгорает"? Перегревается? Отпаивается нога (ноги) чипа в следствие нагрева? Или теряют проводимость несколько дорожек внутрик кристалла? Линукс чуда не сотворил, аналогично работала-бы и винда... с таймерами в меню.

[@kanal_InDo]

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

[@ТимакМакти]

Поздравляю с 50к подписчиков)

[@sergeykh9544]

Иногда в линуксах, обращение к железу видимо сделано через жопу, а жопа похоже у чипа не сгорела =) У меня на старом ноутбуке Lubuntu умудряется во время запуска два раза ноутбук отправить в режим sleep mode и нормально загрузится. Но после работы в лубунте CMOS сбрасывается... Поэтому не удивительно. А эти ноутбуки слаивились сгоранием данного моста. Скорее всего выбило статикой через USB порт.

[@McRoma1983]

Возможно разработчики ноутбука вложили в него для отладки такую возможность хоть как-то общаться с железом. Либо же действительно FreeBSD использует какой-то способ напрямую связываться с клавиатурой минуя мост. Удивил конечно, хорошее видео получилось!

[@shizzzo2010]

Есть предположение. Правда полностью описать с чего такие выводы сделаны я тут не смогу. Суть: на самом деле южник жив, выгорела только часть, отвечающая за USB. Во-первых: (смотрим схему ноута) BIOS подключен к MIO, MIO к южнику, потом через PCI-E к севернику. И больше никак!!! То есть, если южник полностью неисправен, то ноут просто не сможет прочитать BIOS и загрузиться. Плюс IDE тоже подключена только к южнику, так что винт тоже не будет работать. Значит с полностью мертвым южником получим ноут, который при нажатии кнопки "вкл" будет только жужжать куллером и все. Но ноут-то грузится! Почему такая мистика? А тут уже только предположения основанные на общем опыте и схеме(к сожалению не могу найти datasheet'а на этот южник). Некоторые лапы этого южника могут быть запрограммированы на разные функции. В частности одна из лап может быть каким-то спец сигналом USB или генерировать аппаратное прерывание по сбросу аудио кодека. Понятно к чему я? Поясню: если сейчас выгорел модуль USB, то эта лапа не работает, а значит и прерывание по сбросу аудио кодека не генерируется! Абсолютно та же история и с клавой. На самом деле данные о скан-коде клавиш доступны процу всегда, да во только прерывание по нажатию клавиши не генерится, а значит любой драйвер клавиатуры, если он основывается на прерываниях работать не будет! Но ничего ж не мешает написать драйвер, который не будет ждать прерывания, а будет просто постоянно сканить порт клавы на предмет скан-кода. И такой драйвер на этой системе будет работать, как будто все исправно! Видимо драйвер клавы FreeBSD именно так и делает. Кстати, на вскидку я нашел только пару линий аппаратных прерываний, которые могут быть использованы как доп.выводы USB контроллера. Одно с аудио кодека, второе с MIO(видимо клава и мышь). Есть даже мысли как это проверить на практике, но тут описывать не буду, и так что-то длинно получилось. А может и правда под фрёй система одержима дьяволом! Не просто ж так у фри такой логотипчик... ;)

[@anatoliysukhov]

+Александр Шевцов : Не так углубленно.. но сталкивался с контролерами на жестких дисках. Из под линукс можно было считать данные (не писать а именно считать) в Windows никакое шаманство не помогало. Показывало что контролёр мертвый.

[@aldebaranMCMLXXXIII]

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

[@eugenesuvori8352]

по схеме к sb460 подключена по шине lpc к ENE KB910, к которому цепляются клава, тачпад и биос. так что мост таки сдох не до конца, иначе как ноут бы вообще загрузился без возможности считать биос?

[@TheCureDMan]

Удивительно для меня вот ещё что: чип южного моста помимо USB-контроллера содержит в себе также и контроллер накопителей (PATA/SATA), так если южный мост сгорел (о чём говорят внешние признаки и нерабочие usb-порты), то каким же образом BIOS компьютера видит подключенный жёсткий диск и грузится с него? Работу порта LAN я могу объяснить тем, что сетевой контроллер подключен к шине PCI-Express, за работу которой отвечает северный мост.

[@mt_chopper]

+TheCureDMan что говорит о том, что южник выгорел не полностью. )

[@Mukaltinify]

Это магия! Нужно спалить южный мост еще на парочке машин и повторить эксперимент!

[@BachiloDmitry]

+Илья Новиков Это я уже делал, не специально конечно. Всё, что отваливается - во всех системах отваливается одинаково. Но только не тут.

[@Komat0zz]

Это не загадка ноутбука или фряхи, это скорее всего конфиг ядра, конкретно - копай в сторону atkbd и связанном с ним atkbdc (в случае с пингвинчиком atkbd.c, причем и тот и другой писали абсолютно разные люди) который в большинстве linux-дистрибутивов попросту не используется и зачастую отключен, в то время как во фряхе - нет. Так же мне подсказали, что и во freebsd и в linux-based дистрибутивах где-то в файлах ядра спрятан написанный кем-то софтварный контроллер ps/2 (даже не знаю, верить этому или нет, но вполне вероятно что так оно и есть). Надеюсь о результатах дальнейшего "исследования" этой странной ситуации сообщишь.

[@viktorh71]

А что - Super I/O таки всегда работает/работал через южный мост? КМК таки нет.

[@ruslanflex]

все мосты сожжены и дороги назад нет... как пелось в песне

[@Простойкакбумага]

Я раньше с FreeBSD не сталкивался, но теперь я хочу попробовать данную систему. Чудеса

[@majmaster1]

Выпаять чип и убедиться что ФриБСД не может работать без южного моста.

[@Neotiran]

Через контролер прерываний, скорей всего расширенный (APIC), как раз то клавиатура и может работать через него: Бит IRQ Устройство 0 0 Таймер 1 1 Клавиатура 2 2 Каскад (подключён ко второму контроллеру) 3 3 COM 2/4 4 4 COM 1/3 5 5 LPT 2 6 6 Контроллер дисковода FDC (Floppy Drive Controller) 7 7 LPT 1

[@Krutilator]

А может южник не полностью сгорел? Хотя скорее бук одержим демонами.

[@Krutilator]

+Krutilator, ведя фряха демоническая же :)

[@fsmos4448]

Внутрипроцессорный южный мост соединился через шину ISA c Super IO Так называемые неубиваемый tty На Xubuntu это тоже будет работать В режиме Tty А XServer не подхватит

[@diamondblackford5048]

У меня диплом программиста, но я всё равно считаю, что там шайтан в проводах.

[@gsmnexus7610]

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

[@digibear_]

Типовушка у этой модели.. Платформа Compal LA-3121. Да и эти IXP460 сами по себе довольно мрущие. А почему работает.... шина LPC жива. В противном случае дальше запуска питания дело бы не пошло. Мультик тоже жив. Не мрут они тут. ИМХО побитая переферия гадит контроллеру LPC, либо сам контроллер работает некорректно. Буфер контроллера LPC забивается спамом(отсюда собственно тормоза при вводе). Опять же до отработки BIOS периферия не проинициализирована и, возможно, не запитана и не затактована, поэтому нормальной работе контроллера LPC не мешает. А дальше это все разруливают драйверы. Видимо во фре это баг/фича.

[@doncarlione4010]

Южак надо полностью содрать, а потом выпить и поразмышлять если же всётки клава будет работать.

[@morgunovbooch]

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

[@АРТЁММИЛЮТИН-ж8ф]

Может быть проблема в линиях прерывания (IRQ вроде), может повреждена часть линий, которые осью (виндой и юниксом) выводятся под устройства ввода/вывода типа клава/мышь ЮСБиш (а неповреждённые отводятся под Ethernet и прочее по умолчанию), а в FreeBSD они находятся на другой линии прерывания, но это не объясняет лагов, либо она сама выдаёт приоритет на прерывание, и/или мониторит все линии и динамически распределяет по ним периферию, это объясняет всё, но ХЗ как всё устроено на самом деле. Благодарю за то, что прочитали.

[@andreimiroshnichenko7573]

Интересное видео, спасибо.

[@hackprime]

А есть проскролить вверх и почитать что система выводила на экран от окна загрузчика до логина? Было что-нибудь странное?