BSD не верит BIOS и читает контроллер клавы впрямую (режим прямого доступа к нему - Gate A20 == Normal в BIOS), а остальные верят BIOS - там значение Gate A20 == Fast (доступ к контроллеру через чипсет). Контроллер клавы это вполне себе отдельный чип, не часть моста. У него есть даже своя оперативка, встроенное ПЗУ с прошивкой (иногда обновляемой производителем бука!), и т.п. Подключен он в несколько общих шин данных, и может общаться с CPU как напрямую, так и через чипсет. В данном случае BSD нашла ответ неинициализованного чипа при опросе GPIO, опознала как контроллер клавы и заработала с ним в прямом (медленном) режиме. Чудес не бывает.
Каким образом медленный контроллер имеет прямой доступ с CPU, это по логике невозможно. Что согласуют их работу? Опорная частота системной шины явно на это не способна, потому как мягко сказать быстровата.
+Обзоры гаджетов от ArtomU То что Ethernet работает напрямую с CPU вас тоже смущает? Или почему 8 bit ПЗУ BIOS читается в 128 bit RAM, с более чем 10-кратной разницей тактовых частот? А каким боком тут системная шина? Все шины (а их много и по разрядам, и по частотам, и по типам) контролит север, через него и общаются они. CPU же работает в едином адресном пространстве, куда в разные диапазоны отражаются все устройства платы, в т.ч. и этот контроллер. Что тут удивительного-то?
Юг помер по усб. видел таких кучу. суть вот в чем. Клава подключена не через SUPERIO, а через KBC, а именно ENE KB910Q подключен по LPC к ЮГУ. если был бы мертв KBC, то ноут бы даже не включился. так как он управляет всеми питаниями и транслирует загрузку биоса в ЮГ ,через шину LPC (биос висит на KBC ). так вот когда USB мертв при его инициализации зависает ЧАСТЬ ЮГА, так как не может снять прерывание (в данном случае еще и звук и модем), а с ним и все что на шине LPC. BSD же инициализирует USB по другому, там не линукс драйвер, ВИНДА же вообще не грузанется так как будет фатальная ошибка по прерываниям . ну короче это как то в кратце. есть кста метод отжига усб контроллера. хотя не знаю прокатит или нет на амд, не проверял. google: схема LA-3211P страница 1.
+HaroN R.I.P.ley у меня на работе станок сгорел - ремонтники тоже ссылаются на некую заводскую магию. Давно заметил специфическое мировоззрение околоэлектронщиков всех мастей - оно очень близко мировоззрению средневекового крестьянина: а фиг знает, что за чертовщина творится, молиться надо почаще и задобрить духов.
Еще вариант, что от ударения по клавиатуре возбуждаются гравитационные поля, и через черную дыру в центре Галактики передают взаимодействие на кристалл процессора.
Дмитрий, это фишка операционных систем, в винде и убунту, при обнаружении ошибки на первом этапе, система получает код ошибки и запрещает использование всего устройства. На фрибизди, код ошибки игнорируется и переходит к следующему этапу и оказывается что не весь чип сгорел, какую-то часть он может свободно использовать.... А тормозит потому что ему приходится постоянно проходить этапы нерабочей части чипа.
ты прав. задержка как раз из-за того что при нажатии идёт запрос в полное оброшение ко всему чипу моста а в ответку илут ошибки которая фря проглатывает и частично принимает рабочие команды например по клавиатуре которая в итоге всё ж не сгорела в чипе.
Просто фря не заморачивается обработками ошибок, она тупо на низком уровне обращается к порту клавиатуры и та отвечает. А вот винда и убунту всё делает через подключаемые драйверы для расширения возможностей, на каком-то из уровней напаривается на ошибку и просто отваливается.
Ну, перегрев чипа не означает полный выход его из строя. Есть предположение, что он частично деградировал. Например, он не может генерировать прерывания, но какая-то его часть продолжает работать. Может во фряхе реализовали тест железа при загрузке драйвера и если некоторое железо не генерирует прерывание, то оно начинает опрашиваться программно? Это надо копаться в исходниках или документации FreBSD. UPD: Вспомнил. У Фряхи есть такая фишка как Device Polling. Это как раз связано с решением проблем с прерываниями. Тут скорее всего та часть чипа, которая отвечает за выдачу прерываний процессору просто не работает из-за деградации.
Просто это интерфейс PS\2 (тут клава, как и во всех ноутах, по PS\2 подключается). Фри обращается к нему по стандартному порту, минуя то что при диагностике сказал биос. А поскольку есть поломка, и мост выдает на запросы ошибки и каждый раз проводит самодиагностику - вот и есть задержка. Со звуком уже другая история - тут стандартного порта нет, нужно определение его биосом. Потому мультиконтроллер KB910 тут скорее всего в полном порядке, ведь отвечает на запросы, просто юг их через себя пропускает с трудом. Если еще вспомнить, что BSD вообще такая система что ей на биос то в принципе начхать, то еще более становиться понятно почему тут работает клава.
Там на самом деле все просто! В ноуте этом опрос устройств и переброс инициализации ходят по младшим 4 битам системной шины. Винда и *.nixы опрашивают устройства один раз при запуске обвязки ядра, то есть на южаке успевает запуститься кварц тактового генератора и он при опросе совершенно спокойно для своего окружения отвечает "Все готово, типа давай работать!" А вот мультик тактуется по внешней шине, и пока опрос идет тактовых импульсов нет. Но вот ядро поднялось. У BSD есть циклический опрос внешних устройств и мультик с контроллером клавиатуры от этих тактов спокойно заводятся на скорости соизмеримой со скоростью 300бод/сек. То есть для системы становятся своеобразным удаленным терминалом со сверхнизкой скоростью! Фряха серверная ось! Ей постоянно надо знать что у нее ест в окружении а что отвалилось!
Возможно, винда и линух работают с Extended IO через DMA (который мертв), а фря - в режиме прямого доступа к регистрам управления (PIO). Который по каким-то причинам остался жив.
Дмитрий люблю смотреть ваши видео когда наступает монотонность и хочется спать, после просмотра приходит бодрость и интерес к работе... :) Спасибо за труды как всегда продуктивно и на высоте !
Я конечно не на что не намекаю...но я считаю что причиной данного поведения твоего ноутбука являются...Фиксики. А кто такие фиксики - большой-большой секрет! На этом объявляю съезд в Уветичах закрытым! Всем спасибо, все свободны.
FreeBSD он такой) Не удивлюсь, если экран ноута разбить молотком, то во FreeBSD можно будет поиграть на этом экране в Doom 2, в то время как в выключенном состоянии там будут ошмётки от экрана.
Такой эффект обусловлен теми "остатками" ю.моста, которые еще могут функционировать. FreeBSD обращается к ю.мосту по старой технологии, которой современные ОСи не пользуются. (Ну, или частично) Если разбираться по подробнее, то этот эффект можно понять, представив такую картину: У вас есть губка (играет в роли сгоревшего моста) и вода (сигналы). Если подавать сигналы помаленьку (старая мало-битная технология IO), то губка спокойно их пропускает, но если залить сразу пол ведра (типа новая технология), то она часть пропустит, часть впитает (задержка сигналов), из-за этого новые ОС будут приравнивать такие сигналы, к тем сигналам, которые ОС получает от погодных условий или от не совершенства оборудования, в следствии этого она просто "забивает" на них. Ну, простите за орфографию, пишу с телефона, ну и в прочем, думаю, вы уловили мою мысль.
Все-таки нужно разбирать и смотреть мат. плату. По другому в этой чертовщине не разобраться. Я чуть не перекрестился, когда во free BSD клава заработала : )
Значит не сгорел полностью южный мост, а система каким-то образом игнорирует блокировку использования клавиатуры, потому и задержка: она пытается проверить весь чип, и спотыкается там, где он дееспособен. FreeBSD - лучшее решение для серверов, не зря на логотипе красуется демон)
Да сгорел южник не до конца. Там же не 2 транзистора. Что-то сгорело что-то нет. То что сгорело хавает большой ток, на контроллер клавы не хватает напряжения, ФриБСД какую-то часть южника не опрашивает, или опрашивает не так часто, или постоянно. А винда или убунту видлит что все плохо и забивает болт.
Согласен, был один ноут такой, серединка на половинку, юсб отваливались по одному, потом камера, потом звук. Все это на протяжении полу года. Тач, клава и сеть работали. После последнего юсб - ушел на другой ноут
Блин, классная заметка на салфетке получилась, забавная) Спасибо, Дмитрий. И, если вас не затруднит, то, когда всё выяснится, снимите пожалуйста продолжение, либо с рассказом что и как, либо с обрядом экзорцизма.
+Дмитрий Бачило Дмитрий уж не знаю где ещё к вам обратиться.Имею ноутбук MSI GE 70 0ND.В нем 2 видеокарты: Intel hd и GeForce m660. Так вот,в Ubuntu Dota 2 выдаёт ~ 30 fps, а в Linux mint ~60 fps.Можно ли что-то сделать с Ubuntu?
+Дмитрий Бачило мне эта ситуация видится просто, мост не сгорел совсем, а частично повредился, некоторые блоки сохранили работоспособность, ядро фряхи обращается к этим блокам напрямую в отличии от венды и линуха.. А почему не взять и заменить мост? если ноут жалко это выход..
клава в 90% ноутах подключена к мультику, а не к южному мосту, после мультика сигналы хитро переходит к северному мосту. Ктомуже если не выпаян южный мост- он может продолжать общаться с северным мостом на кастылях. Лучше выпаять южный мост. зы: южные мосты могут так выгорать если замыкается на шину данных по юсб +5в, или флэшку сгоревшую сунули или мышку и т.п.
+sabir автор видео явно не бывает в хороших сервисных центрах и подобных чудес там случается настолько дофига, и разными волшебными способами всё иногда работает, а иногда например у вас при искажении изображения по LVDS запросто может стать именно "сгоревший"(лол) южный мост, при том, что всё остальное работает идеально. Бред полный насчет оплавленности микросхем южного моста, за более 5 лет видел больше 50 таких ноутбуков, нигде ничего не плавилось, максимум что бывает это дырка в кристалле, и то для этого надо непонятно каким образом его закоротить. Ёпт, посмотрел дальше, этот 5100 как раз имеет знаменитый мост SB460, чуть ли не единственный в семействе ATI с "детской болячкой", в отличии от интеловых южников, которые дохнут обычно сразу с отсутствием инициализации. Насчет мульта всё верно, видимо догадаться хотя бы разобрать осмотреть материнку для начала и сделать замеры относительно рабочей платы(пойди найди её, хаха) удалось во второй части.
южный мост также отвечает за работу ide. ide работает так как жёсткий диск у вас определяется. микросхема биоса также подключается к южному мосту и без него загрузка в принцыпе невозможна. а значит скорее всего у вас не полностью сгорел тот самый мост и частично функционирует, а следовательно вполне может быть что существует обходной путь общения клавиатуры с системой, хотя скорость уже не та. У системы больше нет нормального сообщения через юг. игнорировать такое нарушение видимо под силу фре.
если мост сгорел это не значит что он станет карпичом, это значит он потеряет функционал. ну вот наверное когда ОС грузятся они проверяют на работоспособность переферию и если она дает сбои(хрен знает из за чгео, там и кварц может полететь и линия задержки другой стать) то считает что устройство сломано и не разговаривает с ним. а вот FreeBSD возможно не проверяет, либо у нее проверка крайне минимальная которая просто проверяет наличие устройства. я считаю что более сложные ОС требуют коректной работы переферии а такие как FreeBSD им достаточно и просто самого существования.
+Михаил Климчук вспоминаются ICH5, которые шли на серии P4 с 800 шиной. По их поводу на всех железячных форумах были целые простыни на тему: повально горят мосты ICH5/ICH5R (пример такой простыни: forum.ixbt.com/topic.cgi?id=9:53483). Был какой-то косяк по USB-шине, который приводил к ее сгоранию в произвольный момент времени, причем сами мосты сгорали в прямом смысле со светошумовыми эффектами. "Лечили" их шокотерапией - специально добивали дохлые USB-порты и продолжали пользоваться, поскольку остальное в этих южниках оставалось целым.
Где-то читал, что причина не в мосте, а в его питании. У меня есть старый комп - пень 4 с ich5, мост достаточно холодный, хотя на нем нет радиатора. А на современной плате с p67 южник в кипяток, если не хорошая вентиляция корпуса, может сгореть вполне себе. Такая температура вряд-ли является причиной зверской передачи данных
+Михаил Климчук, сгорела одна из шин по которым работает юг (USB, PCI) но не LPC по которой общается юг с мультом (i/o , рабочим), по которой опрашивается биос, и по которой клавиатура даёт о себе знать. во freeBSD вероятно сгоревшая шина еще не задействована в Юге - вот он и не пытается полностью ограничить свой функционал. это как если у тебя пожар в двухкомнатной квартире, и пока ты не увидел дым и не открыл дверь во вторую комнатку - где у тебя уже всё сгорело к чертям, ты можешь в другой комнате сидеть и постить коменты к видео на ютубе
В давние года мы баловались с MS DOS, отрабатывая аппаратные прерывания. Клава могла работать как с прерываниями так и без оных (я уже не помню какое резервировалось на клаву, я и CONFIG то уже не напишу) и выглядело это точно так же - с аппаратными прерываниями быстро, с программными - медленно. Возможно в этом дело. Южник сгорел не весь (там куча независимых контроллеров): аппаратные прерывания, на которые расчитывает видна и линух, не отрарабатываются (ноутбучная клава - это контактное поле с собственным контроллером и связана c южником по шине PS/2 которой снаружи нет, а так бы PS/2-клава тоже работала бы), а фришка в них не нуждается. Если флаг прерывания клавы не выставлен - она опрашивает PS/2 в цикле... По-моему так...
+Yevgeny Lebedev Верно. К клаву можно читать двумя способами: через аппаратное прерывание IRQ 1, и через порты 0x60, 0x64. Конечно, поллинг портов клавы это архаизм, поэтому линукс и винда (тем более, десктопные) даже не допускают вероятности отсутствия прерывания. А серверная фряха должна поддерживать всё железо от рождества христова))
Le Bublerkin это такой архаизм, что даже в DOS-е читали по прерываниям. точнее вообще-то обработчик был в BIOS а DOS только читал из программного FIFO через int 16. но это в теории а на практике все кому не лень перехватывали прерывание клавиатуры ! одни только РУСИФИКАТОРЫ чего стоили !
MRooodddvvv У меня есть две рабочие мамки на 286 AT (там, конечно, архитектура попроще: никаких южников и Super I/O, все висит на системной ISA 16) и BIOS на них опрашивает порт KBD (тоже, кстати, системный, а не шина PS/2) в цикле ожидания ввода, и можно без клавы (DIN5), потыкать по контакту DATA и получить случайный символ. Я это к чему? - а какого хрена современные BIOS не делают то же самое. Раздули UEFI до 8 mb, BIOS превратили в Life OS... Нет, все понятно, сломанный комп надо выбросить и купить новый - все по законам капитализма...
Приветствую, в твоем буке, клава , тачпад и микросхема BIOS подключены к микросхеме мультиконтроллера, именно для них, который по 4х битной шине, общается с югом. Так как южный мост частично вышел из строя, то могу предположить, что FreeBSD на уровне драйверов, может обращается на прямую к мултиконтроллеру , не обращая внимание на ошибки южного моста, так как шина до мульта исправна (бук загружается, BIOS считывается правильно). Именно поэтому у тебя на панели задач показывает, что звук исправен, а именно звук, usb и BT у тебя в неисправной части юга и не работают. Ну как-то так , в двух словах. Чтобы стул наладился. :) Здоровья и удачи.
+SenSey Z Да, похоже на правду, хотя с моей точки зрения это, в общем, и так очевидно было. Вопрос больше в том, где в коде FreeBSD прописано обращение в клаве, которое работает, и (риторический вопрос), почему этого кода нет больше нигде. LPC-контроллер виден во всех системах и числится исправным, не понятно, почему они им не пользуются, ведь вроде бы именно через него на этой мамке завязан ввод-вывод.
+Дмитрий Бачило Приветствую, я в программировании дров не силен, но могу предположить, что оно, прямое обращение, было на ранних версиях не только в FreeBSD, а затем в процессе оптимизации кода, могло быть убрано за ненадобностью в современных системах, а в FreeBSD трогать не стали ввиду ее ориентации или lid у прогеров был умнее. Можно попробовать поставить старые дистрибутивы Linux, а в друг? :)
Может он не сгорел вовсе? Подпалился, перегрелся, испортился, но остался в рабочем состоянии на столько, что FreeBSD его каким то образом читает, а остальным системам такие повреждения не нравятся, ибо они более привередливы. Есть один супер способ проверить, южный мост один фиг испорчен, надо выпаять его и посмотреть, что будет вообще без южного моста в FreeBSD.
Обычно, у южного моста везде понатыканы TVS диоды и самовосстанавливающиеся предохранители (например на USB), которые со временем дохнут, и КЗ пробивает часть микросхемы южного моста. Наиболее часто такая проблема случается с питающимися от USB устройствами и теми разъемами которые подключаются и отключаются постоянно и на которых возникают статические разряды... А конфуз скорее всего связан с тем, что у каждой нормальной микросхемы есть флаги готовности и управления потоком, на отдельных функциональных блоках, причем эти блоки могут быть довольно крупными и включать различный функционал. Поскольку микросхема сгорела, то ни BIOS, ни дровишки стандартные так и не получают ответа готовности и/или управления потоком и просто ожидают их бесконечно (от сгоревшего функционального блока микросхемы), а FB скорее всего просто плюет на флаги и читает и посылает данные микросхеме, функционал которой (куска блока) явно недобит :)))
Есть теория. Архитектуру ЭВМ проходил довольно давно, потому могу что-то напутать\наврать. Все этот проц, и любой другой IBM-совместимый обратно совместим с 8086. Насколько я помню, 8086 умеет обрабатывать информацию клавиатуры по средствам своих инструкций (отправка кода символа, если память мне не изменяет). А так, как в те времена южным мостом даже и не пахло, эта функция жила и здравствовала, с появлением онного, про неё и забыли. А она есть. Не исключаю правда и обратного, что со временем за не надобностью она подверглась выпиливанию, как тот же 3DNow от всё того же AMD, но думаю, что во времена того проца, об этой функции даже не думали. А "чертяка" просто не обнаружил контроллера клавиатуры, и стал использовать встроенные инструкции процессора, о чём и было сказано автором. Это и объясняет задержку при вводе.
+Маелс Провер Уж не инструкции точно. Но PC XT имеет несколько другую реализацию клавы, нежели AT. Вот порты ввода-вывода можно копать. Тут надо смотреть референс мануал на XT/AT.
+Дмитрий Бачило фраза сгорел, не совсем верна. У нас чип bga, явно был его перегрев и вот тут самое интересное. Чип от сильного нагрева отпаялся. Тогда достаточно его отпаять и припаять обратно, восстановив все шарики на bga чипе. Придется искать трафарет, но в мастерских обычно есть. Заодно можно примерно на глаз увидетб состояние чипа. Попутно от нагрева могли выйти из строя конденсаторы, сопротивление итд. Надо визуально просмотреть все по пути к чипсету, ну и доставать как минимум хороший тестер , как максимум осциллограф для проверки. Все эти Феди могут привести к частичной работоспособности машины. Ну и вообще почитать даташит на чипсет для большего понимания, что конкретно он делает .
Когда занимался ремонтом компов, при сгорании южного моста не включалось ничего. Крутился кулер проца и все. ничего не грузилось . жесткий крутился,но чтения небыло. Для меня удивительно, что вообще грузит что то.
+Иван Иванов потому что винт грузится через южный мост. если он умер то загрузки не будет. я думаю тут погорело что то другое и пробивает на ноги южного моста, он по видимому тупо подвисает, поэтому и греется.
Наверняка южный мост сгорел не полностью. Линукс, винда, биос и прочее делают запрос, устройство выдает ошибку, и система просто игнорирует его. А фря, видимо, игнорирует эту ошибу и упорно продолжает общаться с нерабочим устройством. Вот это нерабочее устройство и выдает то, что может. Фря это подхватывает и создается видимость нормальной работы. Это скорее плохо, чем хорошо, ведь система фактически сбоит, вместо того, чтобы защититься от нерабочего устройства.
Есть предположение. Правда полностью описать с чего такие выводы сделаны я тут не смогу. Суть: на самом деле южник жив, выгорела только часть, отвечающая за USB. Во-первых: (смотрим схему ноута) BIOS подключен к MIO, MIO к южнику, потом через PCI-E к севернику. И больше никак!!! То есть, если южник полностью неисправен, то ноут просто не сможет прочитать BIOS и загрузиться. Плюс IDE тоже подключена только к южнику, так что винт тоже не будет работать. Значит с полностью мертвым южником получим ноут, который при нажатии кнопки "вкл" будет только жужжать куллером и все. Но ноут-то грузится! Почему такая мистика? А тут уже только предположения основанные на общем опыте и схеме(к сожалению не могу найти datasheet'а на этот южник). Некоторые лапы этого южника могут быть запрограммированы на разные функции. В частности одна из лап может быть каким-то спец сигналом USB или генерировать аппаратное прерывание по сбросу аудио кодека. Понятно к чему я? Поясню: если сейчас выгорел модуль USB, то эта лапа не работает, а значит и прерывание по сбросу аудио кодека не генерируется! Абсолютно та же история и с клавой. На самом деле данные о скан-коде клавиш доступны процу всегда, да во только прерывание по нажатию клавиши не генерится, а значит любой драйвер клавиатуры, если он основывается на прерываниях работать не будет! Но ничего ж не мешает написать драйвер, который не будет ждать прерывания, а будет просто постоянно сканить порт клавы на предмет скан-кода. И такой драйвер на этой системе будет работать, как будто все исправно! Видимо драйвер клавы FreeBSD именно так и делает. Кстати, на вскидку я нашел только пару линий аппаратных прерываний, которые могут быть использованы как доп.выводы USB контроллера. Одно с аудио кодека, второе с MIO(видимо клава и мышь). Есть даже мысли как это проверить на практике, но тут описывать не буду, и так что-то длинно получилось. А может и правда под фрёй система одержима дьяволом! Не просто ж так у фри такой логотипчик... ;)
+Александр Шевцов : Не так углубленно.. но сталкивался с контролерами на жестких дисках. Из под линукс можно было считать данные (не писать а именно считать) в Windows никакое шаманство не помогало. Показывало что контролёр мертвый.
+Александр Шевцов, кстати да. Сколько раз попадали в ремонт вот эти серии асеров с дохлым южником, ни один не грузился. Только кулеры шуршали да слегка подсвечивалась матрица, всё
Поддерживаю предыдущих комментаторов. Однозначно понять ситуацию можно только, если попробовать проделать этот фокус, сняв чип с платы. Хотя, вот как раз после этого ноут, возможно, вообще не стартанёт.
Всё очень просто, объясняю. Общеизвестно, что вся электроника работает на волшебном синем дыме, который находится внутри каждой микросхемы (наверняка все, кто знаком с паяльником видели как этот волшебный дым может внезапно покинуть микросхему, например при превышении напряжения питания). В данном случае скорее всего имеется следующее - в мосте прожгло небольшое отверстие, через которое волшебный синий дым попытался покинуть микросхему, но не смог этого полностью сделать из-за того, что отверстие запаялось обратно. Всё очевидно.
хард можно было вставить в другой комп, загрузиться с него, поставить туда, например, team viewer, поставить все на место и через удаленное управление поставить дрова, все! В топ!!!
Хорошо вам, у вас все просто. Я свою историю уже рассказывал, на ру-борде, никто мне там помочь не смог. В 2014 году, сижу я с ноутбуком на кухне, в сети серфю. Попадаю на страничку, где рассказывается о том, что такое ФИДО, что такое бибиэс, что такое USR 14400... Обуревает меня ностальгия, а тут еще на страничке выложены звуки коннекта разных модемов. Натурально, те самые трели, которые модемы пищали друг дружке в начале девяностых, чтобы потом вы, с дружбаном из соседнего дома, могли вместе провести вечер в подземельях DOOM II. В общем, включаю я воспроизведение этих самых звуков коннекта, не помню, какого модема, Courier или Motorola, не помню ни скорость соединения, ничего, что говорилось в описании к той mp3-шке. Слушаю трели, и тут... у меня за спиной.. мой холодильник Стинол... отвечает на этот запрос коннекта... По-своему, по-холодильничьи, у него это ниже звучит, глуше - но я не могу ошибиться, он реально отвечал на звук запроса соединения, тарахтел и пыжился во всю! И, когда я, в шоке, включил наобум следующий файл из ностальгического списка - его тарахтенье немедленно умолкло! Холодильник опять слушал. Но на этот раз уже ничего отвечать не стал, как будто вторая трель не являлась условным сигналом, на который надо было отвечать! Каюсь, после этого я выключил нахрен ноут, сбежал на балкон и тихо сидел там, пытаясь понять, зачем оно так все. Так же, надо сказать, что с 2006 по 2010 годы я так часто летал в служебные командировки в страны вроде Турции, Эмиратов, Кипра, Греции, что мне пришлось даже менять загранпаспорт из-за того, что там не осталось свободных страниц для виз. Хотя никакой секретности в моей работе не было, она была связана с туризмом. Тем не менее, в том же 2014 году на своих компьютерах я столкнулся с тем, что впоследствии было описано как badBIOS. Это не относится к данному случаю напрямую, но косвенно указывает, что несанкционированное проникновение в мои цифровые устройства скорее всего имело место. P.S. От того холодильника я впоследствии избавился, но попасть к нему все же могу, он в другой квартире, у другого человека.
+Vlad Geo у меня стиралка может общаться с сервисом по телефону с помощью спецсигналов, но такую передачу (видимо кодов неисправности) нужно ручками включить, поднести телефон к машинке и на том конце расшифруют писк. Может тут похожий принцип. Может в сервисе есть спецсигнал, на который возбуждается ваш холодильник и передаёт служебную информацию..
Это не загадка ноутбука или фряхи, это скорее всего конфиг ядра, конкретно - копай в сторону atkbd и связанном с ним atkbdc (в случае с пингвинчиком atkbd.c, причем и тот и другой писали абсолютно разные люди) который в большинстве linux-дистрибутивов попросту не используется и зачастую отключен, в то время как во фряхе - нет. Так же мне подсказали, что и во freebsd и в linux-based дистрибутивах где-то в файлах ядра спрятан написанный кем-то софтварный контроллер ps/2 (даже не знаю, верить этому или нет, но вполне вероятно что так оно и есть). Надеюсь о результатах дальнейшего "исследования" этой странной ситуации сообщишь.
Супер IO скорее всего жив, и он общается с клавой, а так же заведует дежурным питанием. Юг может выгореть по разному и после такого выгорания черт знает что потом происходит с его кристалом. Возможно какие-то прерывания, с зависанием, с горем пополам таки долетают от клавы (мультика) до места назначения, а драйвера win и linux просто не могут корректно их обрабатывать. А производительность Фряхи при этом не страдает? PS Интрига держалась до последнего, я все думал, не может же Бачило какую-то банальщину запилить )))) В конце очень удивился.
+Vitaly Titarenko поддерживаю и развиваю мост состоит из блоков с разаличными каналами питания и мультик может работать в обход моста или вернее отключив питание с проблемной области но оставив живые. Воможно БСД на уровне железа заставляет мультик обходить ЮСБ ну дальше работать а остальные системы работают по стандарту есть проблема нет питания.
Дима, а может найти не нужную PC материнку, умышленно повредить в ней мост, и повторить эксперимент на этом стенде. Тогда будет ясно, за одно и видио снимешь. Тема то действительно интересная.
Это если не сказать, находка века!)) То что большой брат привёз нам эти приставки, уже контроллируя ввод, то антивирусы и прочую байду для шифрования, нам придумали, чтоб крепче не верили в это))) И то как ребята глубоко знают архитектуру обхода, то это скорее намекает, что оно изначально не очень из Free BSD, то есть ему помогли обрести форму)))
FreeBSD видимо умеет работать с клавиатурой через шину lpc. На шине lpc висит микросхема flash bios. Делаем выводы что южный мост отчасти работает(возможно он не сгорел вовсе а перегрелся и отпаялся). Также на lpc все gpio, контроль вентиляторов, контроль температуры. В операционной системе определяется как некий "ISA bridge"
Я требую его разобрать, почистить и прогреть. Будь мужиком! Вероятнее всего где-то отошли контакты и что-то замкнуло от этого и перегрев и заплавление пластика. При этом он частично работает под фряхой.
+Алексей Васин ЮМ в компьютерах часто выходит из строя, а особенно в ноутбуках так как охлаждение в них хуже чем на стационарных компьютерах. Так что факт того что сгорел именно от пыли может быть ложной, так как при большом подключений USB устройств к компьютеру нагружает этот бедный чип.
У меня как то давно история случилась. От скачка напряжения вырубился ПК, и так больше и не включался до определенного времени, заниматься мне с ним было лень и я его забросил примерно на год. Потом как то было скучно и я его включил и он заработал, но система Windows XP отказалась запускаться, пробовал установить с разных носителей, и даже разные системы Windows начиная с 98 и заканчивая XP, всё вешалось намертво на определенном моменте. Но абсолютно любой Linux и *BSD нормально устанавливался и работал. Шайтан коробка.
Удивительно для меня вот ещё что: чип южного моста помимо USB-контроллера содержит в себе также и контроллер накопителей (PATA/SATA), так если южный мост сгорел (о чём говорят внешние признаки и нерабочие usb-порты), то каким же образом BIOS компьютера видит подключенный жёсткий диск и грузится с него? Работу порта LAN я могу объяснить тем, что сетевой контроллер подключен к шине PCI-Express, за работу которой отвечает северный мост.
У меня на вскидку два объяснения: 1. Фря умеет создавать "кротовую нору" в ткани пространства-времени и обращаться в прошлое. Таким образом она может работать с системой до того момента, как сгорел южный. 2. На материнке есть потайной, секретный мост, который, при сгорании северного или южного мостов, берёт на себя часть их функционала. Впрочем, это только догадки... =)
Типовушка у этой модели.. Платформа Compal LA-3121. Да и эти IXP460 сами по себе довольно мрущие. А почему работает.... шина LPC жива. В противном случае дальше запуска питания дело бы не пошло. Мультик тоже жив. Не мрут они тут. ИМХО побитая переферия гадит контроллеру LPC, либо сам контроллер работает некорректно. Буфер контроллера LPC забивается спамом(отсюда собственно тормоза при вводе). Опять же до отработки BIOS периферия не проинициализирована и, возможно, не запитана и не затактована, поэтому нормальной работе контроллера LPC не мешает. А дальше это все разруливают драйверы. Видимо во фре это баг/фича.
если линукс постоянно ругается на звуковуху, значит он не получает ответы на запросы, а значит сгорело то, что должно отвечать на запросы, (изменилась тактовая частота генератора например) а опрос сетки клавы всё ещё работает.
Не зря логотип FreeBSD - дьявол. :D Нужно подробнее изучить архитектуру ПК... Как писали ниже, возможно есть какой-то вариант для связи с SuperIO. Дима, попробуй выпаять юг. Если клава останется рабочей во фришке, то есть левый вариант опроса клавы, который в винде и линуксе не задействован. Если нет, то тут уже особенности южного моста и данного случая. И было бы интересно проверить на другом железе с этой проблемой
Тогда можно предположить, что существуют какие-то статус-биты, которые определяют, есть ли девайс на месте или нет. Т.к. мост сгорел то они не установлены, но фришка это игнорирует. Это всего-лишь предположение..
Все просто - юг умер "не полностью". Во первых, судя по тому что работает сеть, а значит ethernet контроллер - а он таки подключен по шине PCI через южный мост) Схема этого ноутбука кстати давно есть в сети - можешь проверить, вообще нужно с этого и начать разбирательство а не выдумывать и ныть, чем ты занимаешься почти все время этого видео. Итак, уже можно на 100% сказать что юг умер не полностью, ибо интернет работает, PCI шевелится. Идем дальше - клавиатурой управляет kbc (keyboard controller) или EC (embedded controller) контроллер (еще чаще мульт), хоть он и обзывается так, на самом деле ( может и выполняет ) кучу других вещей и по сути является главным микроконтроллером платы,(смотрим схему опять же) отвечает за старт ноутбука, контролирует температуру процессора (управляет куллером), отвечает за инвертор подсветки и питание батареи, обеспечивает поддержку для тачпада и встроенной клавиатуры, наконец СВЯЗЫВАЕТ СЕВЕР И BIOS. Является сердцем платы, ВЫПОЛНЯЕТ ПРОЦЕДУРЫ ХРАНЯЩИЕСЯ В BIOS. Кстати вот тебе и во вторых - тоже подтверждение что юг частично жив, ноутбук же стартанул каким-то образом, биос через кбцху(мульт) запустил же его как-то. А с севером кбц в этом ноутбуке связывается по шине LPC bus у которой МОЖЕТ менятся пропускная способноть в зависимости от режима обмена; ЕСТЬ отдельные режимы обмена для работы с устройствами ввода-вывода (на разной скорости соответственно). Собственно говоря в медленном режиме lpc линия отвечающая за клаву как-то работает, а так сказать на полную нет. Отсюда и работают частично только медленные нажатия на клавиатуре! Подобная ерунда часто происходит например с видеокартами - в 2D режиме работает прекрасно, все кажет) в 3d неможет, драйвер отваливается, зависает. Потому что разные участки чипа за это отвечают, 2d жив полностью а проблема где-то в куске отвечающем за 3d. Кстати если кто видел "горелые" (пробитые) микросхемы, они не сгорают полностью а выгорает какой-то кусочек, чаще точка, которую отчетливо можно увидеть глазами от силы пара % от всей микросхемы. А почему FreeBSD умеет в медленном режиме lpc работать а винда , хубунты и собственно DOS нет))), это особенности строения ядра системы. Конкретнее уже к разработчикам бсд, при желании можно и самому разобраться только времени много надо потратить на копание в коде. Ну и добить, жесткий диск тоже через южный мост подключен, работает же, системки грузяцо)) Туда же, в копилку доказательств частичной дееспособности юга...у тебя только юсб контроллер и аудио контроллер полностью отвалились видимо. P.S превед всем мастерам с которыми ты по этому поводу общался, пускай свои сервисы позакрывают, а дипломы об образовании ( если у них есть) свои выкинут. Ты кстати если являешься каким-либо инженером тоже выкинь))
Согласен. Такая же ситуация есть при сгоревшем видеочипе. На родном мониторе бука полосы и жесткие артефакты с любыми драйверами и режимами ОС, а на внешнем мониторе отличная картинка. Получается чип погорел частично, и за вывод картинки отвечают разные участки чипа. Знаю несколько таких случаев!
Иногда в линуксах, обращение к железу видимо сделано через жопу, а жопа похоже у чипа не сгорела =) У меня на старом ноутбуке Lubuntu умудряется во время запуска два раза ноутбук отправить в режим sleep mode и нормально загрузится. Но после работы в лубунте CMOS сбрасывается... Поэтому не удивительно. А эти ноутбуки слаивились сгоранием данного моста. Скорее всего выбило статикой через USB порт.
Я думаю,и не для кого не секрет что производители электроники используют целенаправленные закладки. Эти закладки нацелены на сокращение службы работы компонентов. Так называемое запланированное устаревание. Исходной конструкторской документации думаю не найти на чип,и это понятно. Иногда даже просто документации какой либо не найдешь на чипы.И конечно даже в подробной документации врятли они напишут или нарисуют секретные счетчики самоуничтожения. А тем временем в миллиардах ноутбуков тихо щелкает счетчик заложенный "добрыми,честными производителями.
+Павел Ключников Всё делается проще - самые дешёвые электролитические конденсаторы, по всей материнской плате, и да - побольше, побольше!!11 3-5 лет,и половина из них будут "пузатыми", особенно в ноуте с его температурным режимом. А у автора явно перегрелся чипсет. Если разобрать, то увидели-бы или окаменевшую термопасту, или отошедший теплоотвод, или распаявшуюся теплоотводную трубку.
Да я в курсе сам занимаюсь ремонтом. Но встречал пару случаев когда нечто не поддается логике и здравому смыслу. Про закладки знаю точно. используют везде начиная с принтеров и батарей питания заканчивая контактами на хардах которые через 1-1,5 года становятся черными. Хотя харды которым 20 лет лежат и не знают что такое окислы между контактами гермобанки и контроллера. Еще пример вентиляторы на ноутбуках которые начинают греметь как трактор после 2 лет использования,которые не смазать не разломав его или не просверлив отверстие в 05 мм в подшипнике для смазки. хотя и после смазки так-же гремит. И многое многое другое.
Павел Ключников Если вы про ST-225 и им подобные, то подозреваю, что контакты там вовсе припаяны. Хотя не помню уже, давно в руках не держал. Но пайка и компоненты там добротные, как на магнитафоне Весна. С Ноутами ещё беда есть - у меня лично на 12" Вайо вентилятор гудит, как будто там не подшипник, а втулка. А причина вся, что недостаточный приток воздуха (под самим вентилятором в нижней крышки отверстий нет, а крыльчатка - рублинного типа, где дарабан с лопатками). Ну и подшипник там тоже не ахти... В этом смысле, больше всего нравятся от Леново. Иногда подходят и на другие.
Через контролер прерываний, скорей всего расширенный (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
"сгоревший" чип - понятие растяжимое, какие-то участки логики вполне могут быть живы, через них-то, наверное, фря и общается с клавой. А винда в те участки не может, например.
+Nikita Suyazov элементарно: приносят мне ноут, нет сигнала на матрице, есть сигнал на VGA. Шлейф? Матрица? Вроде очевидно, а вот фиг. Видеочип перепаял на новый, все работает. Вот и пример частичного отказа чипа.
Значит сгорел не полностью. Если хотите разобраться почему именно так вам предстоит: 1) выпаять южный мост для программистов 2) найти программиста у которого есть программатор, и который разбирается в прошивках 3) этот программист должен разбираться в FreeBSD и, скорее всего, вам ответят почему так происходит.
Южник не умер, вариант-частичный отвал или деградация. Ядро фряхи содержит много низкоуровневого кода и в разы меньше строк кода, чем в современных дистрах. попробуйте OS/2 =) или СТАРЫЕ дистры линукса, (не позже версии 2.4) ту же слакварь 7,8-ку. С большей долей вероятности все сразу заработает как во фряхе, с момента загрузки микроядра. Кстати для удаленной работы с *nix -дистрами на данном ноуте можно пользовать ssh к примеру )
НИХИРА ТУТ ЗАГАДОЧНОГО НЕТУ. ЧИТАТЬ ПРО СЕВЕРНЫЙ МОСТ И ПРЕРЫВАНИЯ. А ЗАОДНО КАК В ОПЕРАЦИОНКАХ РЕАЛИЗУЕТСЯ АДРЕСНОЕ ПРОСТРАНСТВО ЭТИХ САМЫХ ПРЕРЫВАНИЙ.
Ничто в нашей жизни не изведано до конца. Был сервак. Поставил туда линух и попробовал поднять AD. Получилось, но коряво (хотя работало без сбоев). А т.к. я все таки ФриБСД-шник решил все организовать на своей любимой системе. Все построил, все работает. Юзверята не жалуются, но тут начало происходить неведомое. Примерно раз в неделю фря по неведомым причинам подыхала. Прочитал тонну мануалов - нигде ничего. Ради интереса начал изучать железо. Нашел новые прошивки на винты (стоял железный рейд 5). Обновил прошивки и все стало бежать как по маслу. Максимальный аптайм был 80 дней и это только потому, что была проблема с электричеством (упсы не вытянули), а потом увы уволился. Я так подозреваю, что фря немного глубже копает и обращается непосредственно по адресу устройства минуя софтверные версии работы с устройством (т.е. ее драйвера общаются на прямую с устройством минуя BIOS).
Нуу в свое время ixp460 менялись чаще чем видюхи нвидиевские и проблемы с ними возникали просто фантастические, а в твоем случае он просто недопомер. Подарю тебе новый чип если хочешь. Наверняка в запасе осталась парочка. Только компал нужно паять на хорошей паялке, текстолит у компалов какашка и при неравномерном прогреве плату пропеллером крутит, и чип перед посадкой на свинец перекатать будет не лишним.
Возможно разработчики ноутбука вложили в него для отладки такую возможность хоть как-то общаться с железом. Либо же действительно FreeBSD использует какой-то способ напрямую связываться с клавиатурой минуя мост. Удивил конечно, хорошее видео получилось!
Видимо, сгорел не до конца и если передавать сигналы медленно, то успевает отрабатывать. Скорее всего, во FreeBSD какой-то драйвер клавиатуры низкого уровня, а в линукс и винде уже более высокого, которые прежде чем начать отвечать на команды пользователя проводят самодиагностику или что-то подобное.
Допускаю, что он "не прожарился", а у винды с линуксом несколько иной принцип опроса клавы, который рушится тормозами недобитого контроллера. Фре, судя по всему, на тормоза плевать - она просто "тормозит" ввод за компанию.
В ноутбуках нету I/O чипа вместо него служит EC (Embedded Controller), который отвечает за ввод клавы, ACPI события, скорость вентилятора, мониторинг температур и т.д. Скорей всего, так и есть, FreeBSD умеет работать с ЕЦшкой напрямую в обход Юга.
Такая-то проблема. Вот ты не можешь понять, почему работает клавиатура при сгоревшем южном мосте, а мои соседи с местным депутатом и участковым собирают подписи, чтобы сняли wifi антенну с водонапорной башни, которая раздает интернет на моей улице, ибо она отравляет воду! Интернет, интернет, какой-такой интернет?! Он нахер нам не нужон! Средневековье! Чего делать?! Эти "люди" ведь не снимут её через суд, а если не снимут, то сломаю! С*ка, прям не могу, накипело! 21-й век на дворе! Чего делать?!
+whoaboutofcup помню как-то проводил инет одним людям, так они 15 раз спросили про опасность радио волн от роутера с wifi, хотя мобильным пользовались и в ус не дули
У меня есть очень экзотическое предположение... ведь разделение функционала северного и южного моста - вещь относительная, в том смысле, что производитель сам решает в какой именно микрухе реализовать тот или иной функционал . А значит, "северный и южный" мосты - не только некая физическая вещь, но логическая абстракция, т.е. другими словами, часть функционала северного моста вполне может находится в чипе южного и наоборот. Может быть конкретно в этой модели чипсета, работа с Super I/O реализована в микрухе "северного моста" а не южного... а сгоревший чип осуществлял лишь некий аналог арбитража шины??? Думаю, это многое объяснило бы, особенно такую "тормознутость" ввода текста на клавиатуре: "увидев", что физически "арбитраж" не может быть осуществлен был создан механизм виртуальных очередей ввода/вывода... теоретически, этого хватит, чтобы обработать "медленные" устройства, типа клавиатуры. Что касается предположения других товарищей, о "работе через прерывная", то они, с моей точки зрения, не выдерживают критики.
