(UPD: помимо схем добавлена фотография платы)
(UPD2: информация из IRC-канала libreboot)


  • В RINKAN есть защита по току на 55mA, функционал можно смотреть в описании на TB62501F.
  • PMH7 — это массив вентилей ("same thing as FPGA just programmed with up to 3 metal layers, kinda like maskrom"), у Toshiba он назывался TC-200G
  • PMH7 подключен не только к EC, но и к ICH по шине LPC и выглядит с точки зрения хоста как GPIO-extender.
  • Они уверены что неиспользуемые пины PMH действительно висят в воздухе, а замыкание по пинам с большой вероятностью спалит только выходы PMH, но не LDO
  • Предполагают спонтанный выход из строя двух RINKAN по независящим друг от друга причинам (возможно, спровоцированным нагревом мат.платы в процессе мемтеста)
  • Рекомендуют менять RINKAN на такую же микросхему от ROHM: BD4175KVT-BD4176KVT-BD41760KVT, стоимость около $2
  • Согласны, что нужно провести эксперимент по запуску memtest с ограничением по току

Недавно у нас произошла душераздирающая история — за одно утро умерли два ноутбука Lenovo T500. Умер бы один — никто и разбираться не стал. Но два за одно утро — это уже слишком! Тем более, что по крайней мере один из них (и это подтверждают три пользователя!) нормально работал до последней минуты, был выключен кнопкой питания, перенесен за 100 метров в переговорку и… не включился.


Естественно, в первую очередь были опробованы все кустарные способы реанимации: заменить батарею, заменить адаптер питания… Вытащить батарею и обесточить, сбросить CMOS и так далее… Результат? Ровно ноль — ноутбуки продолжали находиться в состоянии кирпичей.


Стали восстанавливать картину событий, чтобы найти хоть какую-то зацепку. Выяснилось следующее:


  • В день "Д-1" обоим ноутбукам добавляли память. После замены планок памяти, оба включились и штатно работали до вечера
  • В ночь на день "Д", на обоих компьютерах запустили memtest (точнее — memtest86+ 5.01-3 из дистрибутива Debian)
  • Утром в день "Д" оба компьютера были выключены кнопкой питания, и не включились
  • Кроме того, их на короткое время подключали по VGA-разъему к одному и тому же проектору, и к одному и тому же адаптеру питания в комнате

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


В первую очередь, проверили проектор. Криминала не нашли, а кроме того выяснили что в этот день (но позже) к нему подключали другие ноутбуки, которые остались живы и здоровы. Во вторую очередь проверили адаптер питания — он вроде бы занижал напряжение, и его изолировали в карантин.


Ноутбуки отдали в сервис, который вернул их обратно со следующим результатом: "отказ материнской платы, запчасти отсутствуют!". Пришлось вскрывать тушки самим (благо в сети можно найти и схемы и сервисные руководства на старую серию Thinkpad-ов).


К этому моменту все стали (методом исключения) подозревать в гибели ноутбуков memtest. Но было совершенно не очевидно — как именно? В конце концов, оставалась вероятность что гибель ноутбуков — это редкое, неприятное, но все же совпадение. Ан нет! Или да… В общем, пока точно не знаем.


Здесь следует сделать лирическое отступление о построении системы управления питанием на буках IBM/Lenovo (по крайней мере старых серий). В более простых устройствах, управление питанием отдается либо процессору/чипсету, либо специализированному контроллеру материнской платы (System controller, он же Embedded controller). Условно говоря, эта штука отвечает за рефлекторно-спинномозговые функции ноутбука: переключение источников тока, заряд батареи, опознание батареек/vendor lock-in, и тому подобные штуки. Но не в IBM/Lenovo!


Инженеры IBM, видимо, задумывались над тем, что прошивка EC может содержать ошибки или сам контроллер вдруг зависнет. Разумеется, у EC есть свой watchdog, но и он не панацея. Поэтому, в обязанности EC входит только генерация высокоуровневых сигналов управления питанием. Силовые ключи же отпирают и запирают две специализированные микросхемы (и не бездумно, а сопоставляя желания EC с показаниями термодатчиков, наличием требуемых для очередного шага напряжений на шинах и т.п.). Эти микросхемы: RINKAN (расшифровка неизвестна) и PMH_7 (Power Management Hub rev7)


RINKAN в интерьере

image


Обратите внимание, что RINKAN не имеет выходов на шины CPU — он в принципе недостижим для процессора. Одна из важных (и неочевидных) функций RINKAN — это генерация стабильного напряжения 3.3v на шину VCC3SW (назовем ее стартовой шиной). Поскольку рядом нет никаких дросселей — можно предположить, что построен этот регулятор по простой линейной схеме. То есть где-то там внутри сидит транзистор с обвязкой и своим активным сопротивлением высаживает мощность, оставляя после себя только 3.3v. Запитывается этот регулятор по ноге VREGIN20, на которую через диоды объединены все источники питания ноутбука (док-станция, адаптер питания, главная батарея и батарея ultrabay). То есть он работает вообще всегда (потому и маломощный — нужен очень малый ток собственного потребления!)


PMH_7 в рабочей обстановке

image


PMH — более интеллектуальная микросхема. Как минимум, у нее есть связь с EC по шине SPI. Кроме того, она включает или выключает целую кучу напряжений и тактовых сигналов на материнской плате ноутбука. Обе микросхемы заказные, без наличия datasheet-ов. Поскольку Lenovo/IBM использует одни и те же заказные микросхемы для разных линеек устройств — некоторые ноги PMH в T500-ом не используются. Однако, вряд ли их оставили висеть в воздухе. Типовые рекомендации предлагают подтягивать неиспользуемые выводы либо к питанию схемы, либо к земле. Запомним это.


Несмотря на отсутствие документации, команда проекта Coreboot сумела (сопоставляя схемы ноутбуков серии T60, T40 и старше — где функции RINKAN/PMH еще были разделены между микросхемами меньшей степени интеграции) накопать кое-что интересное. PMH доступен в адресном пространстве CPU. Не напрямую, конечно, а через EC — но все-таки доступен! UPD: подключен к ICH по шине LPC (Low pin count — аналог ISA). Чтобы поднять или опустить ногу PMH они используют следующую последовательность операций (pmh7.c):


    outb(reg, EC_LENOVO_PMH7_ADDR);
    val = inb(EC_LENOVO_PMH7_DATA);
    outb(reg, EC_LENOVO_PMH7_ADDR);
    outb(val | (1 << bit), EC_LENOVO_PMH7_DATA);

То есть сначала пишем в регистр EC (отображенный в адресное пространство CPU) код регистра PMH, а потом можем читать или записывать его содержимое. Хотим, например, включить подсветку (нога 55 PMH): пишем в регистр 0x55 бит 2 — все просто.


UPD: коллеги из проекта Libreboot считают описанный сценарий КЗ через PMH маловероятным, кроме того — должна была сработать защита по току в RINKAN на уровне 55mA


К большому сожалению, memtest делает примерно то же самое — читает и пишет разные значения в разные области памяти. Теоретически, BIOS должен описывать области памяти, зарезервированные под устройства ввода-вывода. А memtest не должен туда ничего записывать — но… записал! И, видимо, в какой-то момент то-ли поднял, то-ли опустил неудачную ногу PMH. Соответственно, через выходной транзистор ноги PMH, шина питания VCC3SW оказалась накоротко замкнута на землю...


Что было дальше? Дальше RINKAN начал греться. Потому что ток рос, транзитор PMH в ключевом режиме его без проблем протаскивал, а полуоткрытому транзистору в LDO RINKAN становилось все хуже. Но внешне, это никак не проявлялось: во включенном ноутбуке никто не ест с маломощного источника 3.3в, а питание подает специальный мощный DC/DC запитывающий главные шины 3.3 и 5 вольт соответственно.


Ну а когда нажали кнопку питания — главные шины обесточились. Питания же на стартовой шине 3.3в уже не было! И ноутбук превратился в тыкву кирпичик.


UPD: альтернативная теория (omz+libreboot)


В сервисных центрах известна склонность RINKAN к выходу из строя. Коллеги из Libreboot дополнительно утверждают, что это особенно присуще контроллерам производства Toshiba (а ROHM получше будет). Соответственно, memtest всю дорогу был невиновен, а практически одновременный выход из строя двух ноутбуков произошел:


  • Либо по независящим друг от друга причинам (возможно, спровоцированным нагревом материнской платы под длительным memtest)


  • Либо неисправностью (шумом) по выходу питания адаптера, к которому (хотя и на короткое время) присоединялись оба ноутбука.

Результаты диагностики:


Первый ноутбук — плата COR5SOPV3 с двойной графикой. На шине VCC3SW вместо 3.3, всего 1.2 вольта. Сопротивление на землю — около 400 ом. Аккуратно отпаяли и подняли выход преобразователя напряжения RINKAN. Сопротивление по шине сразу возросло до сотни кило-ом. Подали напряжение 3.3в с внешнего источника — бук ожил.


Плата в процессе ремонта

Микросхема с белой наклейкой — Embedded controller, в середине с проводами — RINKAN, крайняя без наклеек — PMH.


image


В результате, подобрали внешний маломощный LDO (LP2930-3.3), который питает стартовую шину вместо RINKAN-а. По итогам тестов обнаружилось, что перенесенная клиническая смерть оставила отпечаток на характере устройства — ноутбук отказывается включаться, если в него вставлена батарея но не вставлен адаптер. Хотите включить — вытащите батарею, включите адаптер питания, и после этого батарею можно вставлять обратно. Все остальные функции (заряд, автономная работа, сон, и т.д) без проблем, а включаться — только так и не иначе. Заморачиваться не стали — решили вопрос административно: использовать сон или перезагрузку вместо выключения. Первому страдальцу повезло!


А второму — нет… Там плата C5ISOVP с интегрированной графикой — напряжения на шине нет совсем, и сопротивление на землю — десятки ом. После отрывания ноги VCC3SW лучше не стало — то же малое сопротивление по VREGIN20. Оторвали еще и ее, включили внешнее питание на стартовую шину — увидели 3.3 и 5 вольт на главной. Однако, несмотря на обнадеживающее начало, сигналов Power-good на выходе PMH/RINKAN не появилось и система стартовать не смогла. Видимо, повреждена внутренняя логика микросхем, и это не лечится...


Весьма вероятно, что memtest может убивать таким образом ноутбуки начиная с серии T6x, и заканчивая серией T420/520 включительно. Начиная с T430/530 изменен способ коммуникации с EC, и записью в память до регистров PMH долезть нельзя в принципе. Возможно, этому подвержены только определенные версии BIOS или прошивки EC. Багрепорт debian-мейнтейнерам пакета отписан, может быть с апстримами чего и найдут...


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


Запуская memtest на ноутбуках Lenovo серий T6x до T420/520 включительно, следует взвешивать потенциальный риск и пользу этого мероприятия. В случае, если вы запустили тест, и он не привел (или привел) к окирпичиванию или зависанию ноутбука — просьба написать в комментарии результат с указанием модели ноутбука и временем работы теста.


На этом все — удачи!

Комментарии (111)


  1. ARD8S
    06.06.2018 22:42

    memtest.
    А как же «Press ESC to exit...»
    *здесь была картинка с разочаровавшимся бухариком.
    Разве не интереснее бы выложить фото потрохов (хотя бы трупика)?

    Видимо, повреждена внутренняя логика микросхем, и это не лечится...

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


    1. myxo
      06.06.2018 23:48
      +2

      А что там смотреть? Такой кирпич по фото ничем от нормального отличаться не будет.


    1. tormozedison
      06.06.2018 23:49

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


      1. ARD8S
        07.06.2018 00:19

        Тут, похоже, столкнулась инженерная недоработка и косяк ПО. Вопрос в том, влияет ли эта версия memtest-а на другие ноуты и влияет ли другая версия memtest-а на эти леновы или косяк во взаимодействии ПО и слишком «продуманного» железа.
        Хотя, как я уже написал, посыл в «извлекайте безопасно» и всё хорошо кончится.

        А что там смотреть? Такой кирпич по фото ничем от нормального отличаться не будет.
        Почему же? Увидим микросхему-виновника (её обозначение) и сделаем выводы. Например, можно узнать, косяк это конкретной модели/ревизии/партии с этими микросхемами или вообще всей линейки на такой платформе. К тому же, потом проще будет самоделкиным диагностировать. Звоним обвязку, меняем микросхему и думаем как жить дальше проверяем работоспособнсть.
        И как я понял, автор делал тестирование «поднимание ноги», когда оживлял первый ноут программно.


        1. CaptainFlint
          07.06.2018 00:45
          +1

          Хотя, как я уже написал, посыл в «извлекайте безопасно» и всё хорошо кончится.
          Предположение, что при нажатии Esc memtest вдруг откатит все изменения, какие он делал, для меня звучит фантастическим. С чего бы ему это делать? Предполагается, что вся память volatile, и перезагрузка всё равно всё сбросит. Та, что не замаплена на устройства, разумеется, но в замапленную писать случайные паттерны — самоубийство (как мы видим из статьи), да и задачу тестирования памяти оно всё равно никак не поможет выполнить.


          1. vvmk
            07.06.2018 08:25

            Возможно еще сыграл фактор «оба компьютера были выключены кнопкой питания».
            Выход из memtest по ESC != насильному выключению во время выполнения записи-чтения бог-знает-куда. Есть вероятность, что программный reset при корректном выходе из теста выставил бы все в исходное состояние.
            Стараюсь, если лень ждать пока операционка загрузится, выключать всегда после процедуры всех инициализаций — или в grub или по F8 в меню винды.
            Привычка берет корни со времен материнских плат под сокетА на логике Nforce2.
            Они очень не любили выключения или сброса во время процедуры POST и инициализации PCI устройств и нелюбовь свою выражали в слёте прошивки BIOS.
            В те времена работал в сервисе и материнских плат на Nforce2 с такой проблемой было не одна-две, а десятки.
            Так что как писал товарищ выше «извлекайте безопасно» и всё хорошо кончится.


            1. ruomserg Автор
              07.06.2018 08:45
              +1

              По (неуверенным) показаниям одного пользователя — ноутбук не реагировал на ESC утром. Поэтому нажали кнопку питания. Но если я правильно интерпретирую схему и результаты измерений — к моменту нажатия ESC, источник питания в RINKAN был уже много часов перегрет. Как бы не был написан memtest — вернуть обратно пробитые транзисторы на кремнии он не в состоянии.


        1. ruomserg Автор
          07.06.2018 08:51

          Программно ноут не оживляется. Только отпайка ноги микросхемы под лупой и подпайка внешнего регулятора напряжения 3.3 вольта.


          1. vvmk
            07.06.2018 09:21

            Так я и не говорю, что то что умерло-оживет.
            Неизвестно, дежурный источник убился во время теста или же после насильного выключения что-то зависло и само себя изжарило.
            В memtest, кстати, ESC не всегда мгновенно срабатывает. Иногда с ощутимой задержкой и кажется что он повис.


            1. ruomserg Автор
              07.06.2018 09:29

              По-идее, после выключения там уже нечему зависать. ЦП со своими шинами питания обесточивается, EC обесточивается путем остановки главного DC/DC 3/5 вольт. С этого момента работает только жесткая логика RINKAN/PMH. Теоретически, переходные процессы в момент выключения, конечно, могут дать такой эффект. Но вероятность такого я даже не берусь подсчитать… И опять же, если переходные процессы могут привести к прожарке источника питания — они одинаковые хоть запускай memtest, хоть что-то еще, и должны проявлять себя при любой жесткой остановке бука. А за долгую жизнь бук должны были неоднократно выключать кнопкой питания принудительно…


              1. Atractor
                07.06.2018 18:51

                Ну, а как-же дежурка? Разве в тех ноутбуках EC не смотрит на кнопку включения? На которой всегда есть некоторое напряжение при заряженном и подключенном АКБ или подключенном запитанном СЗУ. И, да, EC-BIOS крутится в EC, пока есть дежурка, иначе как-бы он отслеживал кнопку?


                1. ruomserg Автор
                  08.06.2018 08:11

                  В Lenovo на EC заводится стабильное напряжение с шины VCC3M. Если ноутбук выключен и не находится на питании с адаптера — EC обесточен. Под напряжением только VCC3SW от RINKAN. От этой же VCC3SW сделана подтяжка кнопки питания. Если не нее нажать, то пара RINKAN/PMH заведет главный преобразователь питания, запитает по VCC3M микросхему EC, и дальше уже EC получит контроль над платой.


    1. Berkof
      07.06.2018 08:04

      Начать стоило с обзвона сервис центров на предмет (а у вас нет дохлой матери от IBM таких-то серий?) Если в той микрухе никаких серийников не хранится, то перепаять и радоваться.


      1. ruomserg Автор
        07.06.2018 08:42
        +1

        Беда в том, что мы вообще-то программисты. На Java пишем для промышленных систем… То, что мы программисты с паяльной станцией, осциллографом и 3D-принтером — это уже несчастный случай и следствие богатого жизненного опыта…

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


    1. ruomserg Автор
      07.06.2018 08:24

      Маркировка микросхем: RINKAN — Toshiba TB62513FG, PMH — lenovo LC272H5

      Вот они на плате: с белой наклейкой — EC, следующий — RINKAN, следующий — PMH. Следов подгара обнаружить не удалось ни при простом осмотре, ни при осмотре с лупой. Снимок сделан в момент подпайки проводов для подключения внешнего регулятора 3.3 вольта (конденсатор C611 сдут, нога RINKAN отпаяна и поднята).

      image


      1. REPISOT
        07.06.2018 08:56
        -1

        Судя по натекам, паяли без канифоли.


        1. ruomserg Автор
          07.06.2018 09:07

          Чуть-чуть мазнули ЛТИ-120. Пайка призов не возьмет — но в первую очередь боялись что оно потечет и замкнет что-нибудь рядом. Самое противное место там — это конденсатор VREGIN20: рядом сбоку контактные площадки VCC3SW и снизу переходное отверстие VCC3SW. Если на трехвольтовую шину попадет 19 вольт от адаптера — ремонт можно считать досрочно завершенным… Перед тем как закрывать наклейкой, натеки пригладили — дабы не проткнули там чего.


          1. Byteman
            07.06.2018 14:42

            Вы это, ЛТИ то смойте лучше, полгодика и скушает дорожки только так. Спиртоканифоль в этом плане будет получше…


        1. GennPen
          07.06.2018 09:26
          +1

          Кто же SMD паяет канифолью? Канифоль только для пайки проводов годится, для мелкой пайки на худой конец (как написали) спирто-канифольный ЛТИ-120, а по-нормальному — хороший неактивный флюс.

          А ruomserg не советую припаивать такие толстые провода к SMD, неосторожное движение — и контакт оторван. В таком случае лучше 2-3 жилы от провода отогнуть и их припаивать, остальные лишние жилы откусить, провод зафиксировать к плате изолентой.


          1. Ghost_nsk
            07.06.2018 13:11
            +1

            Посоветуйте флюс без канифоли. А то какую безотмывочную, нейтральную не возьмешь — все RA/RMA — Rosin Activated — активированные канифолью.


            1. GennPen
              07.06.2018 13:38

              Я сейчас пользуюсь только «FluxPlus 6-412-A EFD», это пока самая лучшая из которых пользовался, нагара не оставляет при выкипании, остатки при необходимости легко счищаются спиртом, годна для пайки BGA микросхем. Единственный минус — цена, у нас 1200р. за 10мг. тюбик, но если без особого фанатизма мазать(через шприц с иглой) то хватает на долго.


              1. GennPen
                07.06.2018 13:47

                за 10г. тюбик
                опечатался


              1. natan555
                07.06.2018 18:16

                Как насчет глицерина


                1. GennPen
                  07.06.2018 19:12

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


                1. AllexIn
                  07.06.2018 20:14

                  Его же смывать обязательно.


                1. ARD8S
                  07.06.2018 23:52

                  Не травитесь. Не используйте глицерин для пайки. При термическом разложении глицерина выделяется ядовитый мутаген акролеин. Даже в губку не советую его подмешивать. Лучше водой лишний раз намочить. Да даже если вы уже X-Men, то хотя бы платам на пользу не пойдёт.


            1. ARD8S
              07.06.2018 18:16

              Не знаю, как вам даже и написать. Канифоль, она не плоха, надо выдерживать условия и температурный режим. Она есть во всех почти флюсах, что EFD Flux Plus, что весь зоопарк с али.
              На али NC-559-ASM встречал без RMA разве что. Не знаю, есть ли там канифоль.
              Я ввиду крайней нужды взяли забадяжил сам.
              Состав такой: аптечный вазелин + жидкий безотмывочный флюс ФПБ. Расплавил феном вазелин (на 100 градусах) и смешал с флюсом. Наношу кисточкой, чуть подбавляя по мере испарения. По мере застывания, конечно, разделяется на фракции, но можно наносить и так. Может быть и можно как-то газировать и смешать под давлением до однородной структуры и упаковать в шприц, не пробовал.
              Для BGA, QNF, конечно, не подойдёт, но кое-что типа SMD паяльником поковырять можно. Медь лудится влёт, провода многожильные продирает «до самых до глубин». Выходит весьма дёшево. Смывается калошей, можно смешать её с изопропилом 1/1 или уайт-спиритом.
              Думаю можно и вазелиновое масло взять. Хочу попробовать смешать силиконовый вазелин. Глицерин для флюсов использовать категорически не советую.


          1. Byteman
            07.06.2018 14:43

            ЛТИ-120 != спиртоканифоль… Часто люди этого не знают и не смывают ЛТИ после пайки, и через полгода-год от дорожек на плате ничего не остаётся.


            1. GennPen
              07.06.2018 17:06
              +1

              Все верно, совсем забыл, что ЛТИ — активная спиртоканифоль.


            1. AllexIn
              07.06.2018 20:15
              -1

              Я вот не смываю. Вернее смываю, но дочиста не выходит… Доверился надписи «не требует смывки». И как быть? Чем заменить?


          1. Atractor
            07.06.2018 19:11

            Как уже написано, канифоль не есть зло. Канифолью не рекомендуется пайка безсвинца по причине более высоких температур, при которых канифоль начинает окисляться и вследствие чего может начать проводить электричество, чему немало способствуют плотный монтаж->малые зазоры и высокие частоты. Также пережжёную канифоль сложнее смыть… Огромное количество флюсов изготовлено на основе канифоли, отличаются степенью её очистки (чем выше, тем лучше) и наличием присадок, активаторов, стабилизаторов… Флюсы рекомендуется смывать, даже безотмывочные, ибо неизвестно доподлинно какой там состав (исключения — положительный опыт использования конкретно вот этой упаковки).
            Да, если лудит очень хорошо, значит флюс активный и смывка обязательна.
            Насчёт проводов: конечно, толщина критична, если нет других, то я прокладываю, закрепляю, а после уже припаиваю, дабы исключить отрыв дорожек. Можно использовать литцендрат от наушников (у комплектных от продукции Apple весьма неплохие провода), там, действительно, можно использовать несколько волосин. Лудятся хорошо активным флюсом, за неимением — в среде хлора, например на кусочке ПВХ.


      1. hd_keeper
        07.06.2018 09:41

        ?? / rinkan


        1. ruomserg Автор
          07.06.2018 10:11

          Какое-то нецензурное, блин, название. Просится на язык — как вы лодку назовете…


      1. ARD8S
        07.06.2018 18:35

        Микруха в КЗ получается?
        Видимо, всё-таки склонна к отказу именно сама микросхема. Может быть защиты какой-то не хватает, статика, пробой, банальный перегрев при активном обращении-стресс работе (memtest) или наводки какие-то есть. Заменить не проблема.
        С ?? / rinkan здорово hd_keeper подметил, забавно получилось, правда, омофон, но склонность микрухи к отказу и то, что ломается, даже занятно.


  1. lorc
    07.06.2018 00:40
    +3

    Странно это. По идее memtest должен ходить только по DDR RAM и не пытаться писать в memory mapped io. Иначе, чудеса начались бы намного раньше, ещё в момент натыкания на регионы куда замаплена PCI.


    1. willyd
      07.06.2018 03:59

      lenovo же…
      Недавно похожее было, хотя там еще не понятно, кто виноват. habr.com/post/409009


  1. quwy
    07.06.2018 00:41
    +3

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


  1. wormball
    07.06.2018 01:08
    +1

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


    1. 1nd1g0
      07.06.2018 06:09
      +1

      Да там вообще только работа с портами. Причём тут память…


      1. ruomserg Автор
        07.06.2018 06:15

        Это верно. Как memtest добрался до портов EC — нам пока неизвестно. Возможна ошибка в фирмвари EC, и он декодирует свой адрес даже если на шине запрошено другое адресное пространство. Возможно, эти же регистры смаплены биосом (см ниже пост yleo) в какой-то memory region, доступный по записи. Наших ресурсов на дальнейшее расследование недостаточно.


  1. yleo
    07.06.2018 01:26
    +7

    Не могу согласиться что memtest виноват.


    На x86, как и на многих других архитектурах на шине CPU есть еще один сигнал, который явно показывает куда обращается CPU: к портам ввода-вывода (инструкции IN/OUT) или к памяти. Соответственно, в обязательном порядке этот сигнал должен использоваться в схеме декодирования адреса.


    Поэтому "просто так" memtest не мог что-либо записать в регистры EC. Однако, ему в этом мог помочь BIOS. Сценарий такой помощи примерно всегда работает через PCI, но тут нужно кое-что пояснить:


    • есть PCI CONFIG SPACE (обращение со стороны процессора только посредством IN/OUT).
    • этот CONFIG SPACE отвечает за конфигурирование всех PCI-устройств (и всех устройств на всех логически совместимых шинах).
    • конфигурирование PCI-устройства предполагает:
      • выделение участков адресного пространства на шине в адресации CPU, но так чтобы эти адреса не были занять чем-либо другим.
      • в зависимости от потребностей и возможонстей PCI-устройства, таких адресных диапазонов может быть несколько, как в I/O SPACE (через IN/OUT), так и в MEM SPACE; с разным режимом допуска: R/O, R/W, non-cacheable, write-combite...
      • разрешение работы устройства на шине = после выделения адресов и записи в соответствующие места PCI CONFIG SPACE, должен быть выставлен еще один ENABLE бит; При этом PCI-устройство будет подключено к шине, точнее говоря начнет работать его логика декодирования адреса и станет вырабатывать чип-селекты и RDY.

    Самое худшее, что может сделать гадкий BIOS = плохо сконфигурировать устройства (с перекрытием адресов) и тем более оставить подключенным в MEMORY SPACE что-то опасное. Тогда ничего не подозревающий о сюрпризе memtest может вляпаться.


    1. vassabi
      07.06.2018 06:11

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


    1. ruomserg Автор
      07.06.2018 06:19

      У мемтеста были сообщники, это факт! Под подозрением прошивка EC.и BIOS. На меня вышли англоязычные коллеги из libreboot, у которых есть больше информации о внутреннем устройстве старых lenovo — возможно мы с ними сумеем накопать больше информации.


    1. ideatum
      07.06.2018 07:19

      Не хотелось бы спорить, но есть различные варианты реализации I/O:

      1. Memory-mapped I/O (MMIO)
      2. Port-mapped I/O (PMIO)

      В современных компьютерах используются и тот и другой варианты. Самый известный вариант использования MMIO в PC это непосредственный вывод информации в видео память. Для этого не используются инструкции IN/OUT, а используются обычные инструкции MOV. При этом в 32-х разрядный системах когда установлено 4GB RAM (максимум адресуемой памяти в 32-х битных ОС), адресное пространство устройства приходится отображать на уже «занятое» RAM адресное пространство. Поэтому всякие проверяльщики памяти обязаны с должным почтением обходить регионы занятые устройствами. Более подробно можно почитать в Memory-mapped I/O, либо в Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1


      1. yleo
        07.06.2018 11:18

        Адекватный BIOS не должен оставлять на выходе разрешенные MMIO регионы, обмен с которыми (запись или чтение) может привести к side effects. Если не ошибаюсь это один из пунктов спецификаций PCI и PnP.

        Вторая «любимая» ошибка — когда протокол взаимодействия с EC (и прочими так называемыми Super-I/O) требует монопольного доступа к шине. Например, когда парой OUTB специфических значений в специфические порты открывается «секретный» доступ к Super-IO контроллеру.

        Для исключения конфликтов, в таких случаях на время обращения к Super-IO приходиться «глушить» все ядра на всех CPU и запрещать прерывания (15 лет назад пришлось повозиться с подобным в специфической драйвере, чтобы безопасно включать «турбо-режимы» на COM-портах).


  1. Cenzo
    07.06.2018 05:14

    Это схемы Lenovo в статье? Apple вон уже ремонтника засудил за публикацию схем «защищенных копирайтом».


    1. vassabi
      07.06.2018 06:06

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


  1. REPISOT
    07.06.2018 06:06
    +1

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


    1. ruomserg Автор
      07.06.2018 06:23

      Мне кажется, что они не стали бы делать микромощный преобразователь с дросселем. На холостом ходу (а там почти 100% времени работа в таком режиме) у импульсного преобразователя ток на собственные нужды (+потери в дросселе) должен быть больше чем у линейного на полевике. А они там за каждый микроампер должны бороться — это же высадка батареи даже когда бук полностью выключен!


      1. Pinkerton42
        07.06.2018 07:18

        Есть Lenovo V510 с полностью заряженной батареей. Через 2 месяца на полке батарея разряжена. Так что, про борьбу за микроамперы, это не к Lenovo.
        Батарея несъемная, но в BIOS-е, видимо специально для этого, сделали возможность отключать ее программно.


        1. garus_ru
          07.06.2018 08:50

          И, видимо, не к HP.
          Батарея у HP тоже на уровне 60-80% после месячного простоя.


        1. REPISOT
          07.06.2018 09:02

          Если это не LSD (Low Self-Discharge) Ni-MH батарея, которая держит заряд годами, то саморазряд сажает ее (в зависимости от качества) за пару недель — месяц.


          1. Pinkerton42
            07.06.2018 09:51

            Это свежая модель с литиевыми банками.


          1. wormball
            07.06.2018 11:27

            Литий-ион также держит заряд годами.


      1. REPISOT
        07.06.2018 09:12
        +1

        TPS82084 (2А выходной ток) по ссылке имеет ток покоя 17 мкА. Указанный линейный LP2930-3.3 — 75 мкА, при этом рассчитан на ток до 100 мА


        1. ruomserg Автор
          07.06.2018 09:20

          Посмотрел. Круто, ничего не скажешь! Одна надежда — что в 2008 году таких игрушек не было. И да, LP2930 — это не идеал, а лучшее, до чего удалось добраться в местном магазине радиодеталей. Сначала вообще хотели подкинуть L78L33 с током покоя 5ma. В RINKAN должно стоять что-то с характеристиками получше.


  1. MzMz
    07.06.2018 07:23
    +2

    У меня на Lenovo P51 утилита обслуживания дисков Seagate SeaTools окирпичила SSD M.2 Samsung при попытке сканирования шин. Я сначала подумал, что это у меня кривые руки, но на всякий случай оформил репорт и через месяц в этот пост пришли отклики от других людей с такой же проблемой. Кто виноват и в чем проблема не сказали, но проблему пофиксили с выпуском новой версии SeaTools и новой прошивки для SSD Samsung


    1. vin2809
      07.06.2018 07:41

      Вот и я о том же, причем здесь Lenovo?


      1. ruomserg Автор
        07.06.2018 08:58
        +1

        Другие компьютеры и буки тестировались с незапамятных времен именно мемтестом разных версий. Пока известных мне случаев смерти ровно два, и оба lenovo. Ждем накопления статистики…


    1. Frankenstine
      07.06.2018 11:52

      А у меня тут SSD M.2 ADATA 512GB XPG SX8000 на материнке Asus Z170-P ведёт себя странно: раз в несколько дней либо не виден в системе (винда 10 пишет о невозможности запуска устройства, «так как оно сообщило о неполадке») либо винда зависает на начальном этапе старта (грузится с другого диска, но на этом лежит своп). После перезагрузки диск появляется и работает без проблем, данные на месте и всё такое. Вот только сбрасывается на ноль количество записанных на него данных в счётчике S.M.A.R.T. Кто виноват тоже не понятно, хотя предполагаю что сам диск таки, ведь другие ему в S.M.A.R.T. ничего записывать не должны.


      1. S_o_T
        07.06.2018 17:28

        Столкнулся с такой-же проблемой, только на другой материнке (asus b350-plus). Первый раз система ссд пропал когда установил новую 1060. Подумал на то, что гпу много ест через линии pci на старте, поменял на другую модель (с 6pin на 8pin доп питание), вроде проблема пропала. Но иногда все же ссд не видно, особых корреляций не приметил (разае что при выключении зажимом кнопки питания). Лечится простым отстоем десктопа в обесточенном состоянии на некоторое время (магия).


        1. Atractor
          07.06.2018 19:24

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


          1. S_o_T
            07.06.2018 19:28

            Про магию конечно-же шутка А что казается пыли или плохого питания: проблемы возникли на свежесобранном десктопе, с двумя бп от разных производителей на 500 и 750вт (второй специально подбирал с повышеным током по линиям 12v)


            1. Atractor
              07.06.2018 19:54

              Свежесобранный =/= исправный, как и собранный правильно. Не сочтите за камень в огород, просто имеется практически ежедневный опыт по свежесобранным ПК (работа в сервисе).


      1. Atractor
        07.06.2018 19:21

        ИМХО, что-то с областью, где лежит SMART, более вероятна неисправность накопителя, нежели некорректная работа матплаты.


  1. vin2809
    07.06.2018 07:40

    Конечно memtest, даже теоретически, не должен попасть в область адресов BIOS или I/O. Но попал же…

    А на Lenovo зря нападаете, кому как повезет.

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

    Jedem das Seine!


    1. Shapeshifter
      07.06.2018 09:31

      suum cuique звучит

      менее... специфично
      image
      Ворота в концлагерь Бухенвальд


  1. as3
    07.06.2018 08:05

    Товарищи, такое взаимодействие memtest'а и ноутбуков является уязвимостью, пожалуйста, сообщите в Lenovo и Microsoft.


    1. Wesha
      07.06.2018 08:21

      пожалуйста, сообщите в Lenovo и Microsoft.

      Если вы не отзовётесь, мы напишем в Спортлото


      Простите, а при чём тут Microsoft? Memtest писали не они.


      1. Frankenstine
        07.06.2018 11:55

        Тогда в Спортлото!


      1. as3
        09.06.2018 01:24

        Я почему-то думал, что они. Моя ошибка.


    1. ruomserg Автор
      07.06.2018 10:04
      +3

      Я не думаю, что Lenovo будет делать исправления для ноутбуков бородатых годов выпуска. Пока проблема обозначена мейнтейнерам и апстриму memtest86+. Если мы сумеем убедить их в правильности нашей версии — они поставят костыль со своей стороны, или хотя бы выведут предупреждение при запуске на потенциально убиваемой системе.


  1. Inanity
    07.06.2018 08:05

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


  1. b0a
    07.06.2018 08:05

    гонял на своем t400 doc-овский мемтест ранее, видимо свезло


  1. noname-x
    07.06.2018 08:05
    +1

    Видел довольно много постов в сети мол сломать пк(ноут) программно невозможно.
    А все оказалось так просто… пусть только с некоторыми моделями, хотя…


    1. Frankenstine
      07.06.2018 12:02
      +1

      Да с любой моделью можно! Например, берём доверху налитый электрочайник, ставим на ноут, втыкаем в управляемую по вайфай розетку. Теперь, программно (и удалённо!) включив эту розетку, выведем из строя ноут :D
      Я к тому, что в принципе бывают всякие окольные пути. Но они все не универсальные, требуют особых условий.


      1. kirillaristov
        07.06.2018 13:05

        Зачем так сложно?) Розетка с таймером на 5 секунд и микроволновка.


        1. Frankenstine
          08.06.2018 10:28

          Остап знал более четырёхсот способов… (с)


  1. Miron11
    07.06.2018 08:15

    Тест памяти, убивающий ноутбуки — почти детектив
    ***
    Очень образный заголовок. Почему — то мне представился программист, которого заставляют запомнить неудобоваримое количество кода ( тестируют память ), и в конце концов из его глаз ударяют жуткие молнии, уничтожающие компьютер, служащий источником пытки.


  1. sidristij
    07.06.2018 09:40

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


    1. Notzeal
      07.06.2018 11:40

      Вы намекаете, что они это сами спровоцировали? :)


    1. Maximuzzz
      07.06.2018 11:58
      +3

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


    1. ubivas
      07.06.2018 15:07
      +1

      Типичный пример ошибки выжившего (survivorship bias). Такие случаи, несомненно, происходили и у других людей. Просто те не смогли их диагностировать, или не написали об этом статью :)


  1. shogunkub
    07.06.2018 11:54

    Очень похоже на историю в Чернобыле — роковое стечение обстоятельств. Вроде обо всём подумали, но мелочи тут и там сложились в смертный приговор.
    По идее, оживить несложно, но отсутствие запчастей озадачивает.
    Печально. Есть ли какие-то способы безвредно проверить, подвержен ли ноут этому багу? Я довольный обладатель W520, хотелось бы как-то себя обезопасить на будущее, кроме способа «ни в коем случае не запускать memtest».


    1. ruomserg Автор
      07.06.2018 12:16
      +2

      Мы у себя до особого распоряжения запретили запуск memtest на всех ноутбуках Lenovo младше T430/530.

      Наша самая главная надежда — это, конечно, восстановленный ноутбук (собственно, я с него и пишу сейчас). Когда подойдут материнские платы на замену — устроим натурный эксперимент. Для этого отпаяем выход LDO у починеной платы и подрубим внешнее питание с токовой защитой (скажем, миллиампер 50). Погоняем сначала просто так — чтобы убедиться что ложных срабатываний защиты нет, а потом запустим memtest. Если токовая защита сработает и вырубит все нафиг — значит вот оно и попалось! Научимся тестом баг фиксировать — считай, уже победили…


      1. shogunkub
        07.06.2018 12:31
        +2

        Будьте добры, напишите апдейт к статье по результатам!


  1. omz
    07.06.2018 12:39

    Сенсация надуманная. Диагностика проведена не верно. С т.з. схемотехники и реализаций питания (будь то линейных преобразователей или импульсных) выводы ошибочные.
    Во первых, в случае если это LDO, как выпишите:
    «И, видимо, в какой-то момент то-ли поднял, то-ли опустил неудачную ногу PMH. Соответственно, через выходной транзистор ноги PMH, шина питания VCC3SW оказалась накоротко замкнута на землю...»
    Из каких соображений это написано? Взято из воздуха? Транзистор в линейном стабилизаторе не включается на землю, он включается между входным напряжением и нагрузкой, а затвором рулит управляющая схема с ОС. Если транзистор полностью открыт (или пробит), то на нагрузке будет не КЗ, а полные 20В со входа.
    Обычно в контроллерах никто не будет делать цифровое управление аналоговым сигналом (управление затвором и регулирование), т.к. нужны фикс 3,3В, от контролера требует только сигнал ON-OFF. Поэтому данная версия полностью исключена.
    Если это имульсный DC-DC (маловероятно): опять же, никто не формирует по цифровым шинам ШИМ сигнал, особенно в том случае, если нам нужен только фикс 3,3В.
    В общем, все это не более чем надумка. Есть версия более простая, из опыта ремонта ноутбуков в т.ч. на аналогичных платформах. Преобразователь в контроллере 20В->3,3В приказал долго жить после проблем с иточником питания, либо нагрева, либо сам по себе (такое то же бывает). Может быть и сам контроллер умер быстрее преобразователя и потянул за собой остальное. Чаще всего случается подобное, что подтверждается отзывами ремонтников подобных платформ (так и пишут — после китайских БП).


    1. ruomserg Автор
      07.06.2018 13:03

      К сожалению, пока мы не поставим натурный эксперимент с запуском memtest на модифицированной плате с токовой защитой по 3.3v — окончательно сделать выбор между версиями «сбой питания» и «КЗ по выходным линиям PMH» не получится. Против версии «сбой по питанию» говорит следующее:
      — Во время теста ноутбуки стояли на разных источниках питания, а характер повреждений одинаковый
      — Все предохранители в цепях питания целы
      — До момента отключения питания ноутбуки работали (были они зависшие или нет — отдельный вопрос). Следовательно, питание с адаптера по линии VINT20 приходило на все преобразователи, и ни один из них не ушел в защиту. Сценарий, при котором на все преобразователи приходит бросок, но умирает почему-то только LDO RINKAN (напоминаю, она включена через доп.диоды — т.е. на ней никак не может быть напряжение больше чем на VINT20) кажется нам маловероятным.
      — Условно-подозрительный блок питания в переговорке подключался к ноутбуку N1 на короткое время, и при этом уже не зажигался светодиод DCIN на панели бука. То есть, бук уже демонстрировал симптомы, характерные для смерти VCC3SW. Да, есть вероятность что это короткое подключение его тоже убило. Мы поместили адаптер в карантин, и используем его для проведения эксперимента. Сейчас времени и техники для эксперимента (с потенциальным выходом из строя еще одного ноутбука), к сожалению, нет.
      — О вопросах схемотехнической реализации LDO в RINKAN смысла спорить не вижу, т.к. ни у кого из нас нет надежной информации по этому вопросу. В первом ноутбуке явный отказ схемы регулирования, регулирующий транзистор прикрыт, ток собственного потребления на ХХ 8ma — великоват. Во втором ноутбуке схема регулирования практически пробита на землю с током утечки на ХХ около 0.5A (что вообще ни в какие ворота). Как именно это произошло, по имеющимся данным восстановить мы не можем.


      1. Sergey_datex
        07.06.2018 13:42

        Горячо обсуждаем хронологию событий и пытаемся по вашему рассказу выяснить первопричину. Есть мнение что первоначально был слет прошивки BIOS, что часто бывает при работе с линуксом. Скажите — вы, либо сервис куда отдавали на попытку ремонта — перешивали его? Паяная ли микросхема Flash?


        1. ruomserg Автор
          07.06.2018 14:25

          BIOS не слетал, следов пайки на платах нет. Сервис тоже ничего не шил — «диагностировали» смерть материнки, и сказали что если мы принесем исправную — они за наши деньги ее заменят. То есть они даже из шасси ее не вынимали. Первый ноутбук ожил после отпайки VCC3SW на RINKAN и подаче на VCC3SW внешнего питания 3.3В. Причем, ожил полностью и попытался загрузиться. Опираясь на это мы начали искать и паять внешний LDO.

          Я лично нес в руках бук N1 с момента его выключения после memtest и до попытки включить в переговорке. Он реально был рабочим 30 минут назад, а потом не реагировал даже на штекер питания (должен светодиод загораться, даже если бук не включен).


        1. luethus
          08.06.2018 00:14

          был слет прошивки BIOS, что часто бывает при работе с линуксом

          Впервые слышу, это как? Можно подробнее?


          1. Sergey_datex
            08.06.2018 00:19
            +1

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


      1. omz
        07.06.2018 14:51

        Опять же — что это за эксперимент? Что вы хотите выяснить им? Что у вас меняется потребление по питанию VCC3SW? Потребление (ток) дает нагрузка. Как это связано с контроллером? Тем более вы даже не знаете какой максимальный ток может быть на этой нагрузке.
        Вы же и пишете, что оба подкючались к одному источнику. И не загорался светодиод. Да, сгорает моментально и как раз в момент подачи внешнего питания.
        Предохранитель останется цел по двум причинам: т.к. общий ток потребления (с горелым контроллером) не выше его порога срабатывания, либо если возникает КЗ по линии VINT20 (как во втором ноутбуке) входные мосфеты закрываются, соответственно потребления почти не будет.
        Умирают не только от броска напряжения, а от шумов источника питания. Диоды вообще ни причем, шумы прекрасно проходят через них.
        О LDO и так прекрасно известно. Вы же строите какие то невероятные теории, вроде — выходной транзистор замкнут на землю. Откуда это? Приведите схему такого преобразователя.


        1. ruomserg Автор
          07.06.2018 15:13

          Как выясняется (см второй апдейт статьи) — в RINKAN есть встроенная защита по току 55 ma. Мы запустим мемтест с внешним ограничением по току VCC3SW и посмотрим как будет вести себя ток на этой шине. Если ограничение по току не сработает — значит никакого КЗ по VCC3SW при запуске memtest не было — и, следовательно, отказ RINKAN произошел по другим причинам (наиболее вероятно, из-за адаптера). Если случится ограничение по току — значит memtest все-таки может вызвать состояние КЗ (или, скажем корректнее — нерасчетно высокого потребления тока) по этой линии питания, и механизм образования КЗ придется уточнять.


          1. omz
            07.06.2018 15:34

            Вот этот апдейт более похож на правду. Но ваш «эксперимент» почти ничего не даст по вашему первоначальному предположению — запись неверных данных по шине в контроллер. Лучше бы вы убрали этот вывод, т.к. повторюсь, это физически невозможно, но вводит людей в заблуждение.
            Эксперимент покажет, что возможны проблемы с нагрузкой дежурных 3,3В из за каких то там причин, ОК. И? Опять же, в контроллере встроенная защита OCP приведет к выключению контроллера, ноутбук просто выключится. Вообще не факт, что проблемы с нагрузкой вызовут выгорание контроллера.
            Зато есть реальное предположение — если посмотрите даташите на аналогичные контроллеры (ту же тошибу из апдейта), то поймете, что эти 3,3 используются и внутри контроллера и там уже вполне возможен внутренний пробой этого напряжения на землю.
            Если у вас нет осциллографа, диагностировать импульсные цепи почти невозможно, соответственно лучше тот БП куда нибудь подальше закинуть и больше не включать.
            Если вы находитесь в Москве, можете заказать контроллеры и отдать платы мне на восстановление — вы обратились не в тот сервис.


            1. voicetranslator
              07.06.2018 22:09
              +1

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


              1. ruomserg Автор
                08.06.2018 08:48
                +1

                Здесь два момента. Во-первых, мы не против опровержения нашей теории. Мир, в котором тест памяти реально убивает ноутбуки — ужасен.

                Во-вторых, когда за утро у тебя без видимых причин умирают два ноутбука корпоративного класса — на ум приходит одна цитата из Стругацких: "… Нам разрешается прослыть невеждами, мистиками, суеверными дураками. Нам одного не простят: если мы недооценили опасность. И если в нашем доме вдруг завоняло серой, мы просто не имеем права пускаться в рассуждения о молекулярных флуктуациях — мы обязаны предположить, что где-то рядом объявился черт с рогами, и принять соответствующие меры, вплоть до организации производства святой воды в промышленных масштабах." © Жук в муравейнике


                1. voicetranslator
                  08.06.2018 09:17

                  По моему, вы немного ударились в «театральность» и излишнюю драматизацию. Я тоже «программист с осциллографом» (при том, купленном за свои деньги just for fun), и немного разбираюсь в схемотехнике (по любительски, конечно).
                  Камрад omz, в отличие от нас, похоже, что профессионал, и его предположениям (sorry!), я склонен доверять больше, чем вашим.

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

                  Вы же понимаете, что ноутбуки делают вовсе не «ламеры» или «лохи». И даже в России ноутбуки просто не делают. Да и вообще, страны, в которых ноутбуки именно «делают» (а не паяют чипы на платы), могут уместиться на одной руке трехпалого человека…


  1. ExtenZ
    07.06.2018 14:16

    Тоже как у меня, клиент решил сменить память ddr3 2*2 на 2*4гиг но с ebay получил не ddr3 а ddr3L, итог = спалил 2 ноута probook 6570b неслабой такой комплектации (тупо моргает CapsLock + NumLock 3 раза = проблемы с памятью)
    Где чинить не знаю, в нашем Кишинёве чинить отказались


    1. POS_troi
      07.06.2018 17:03

      Тут DDR3 vs DDR3L вообще не причём, ну не горит DDR3L от 1,5в ну вот вообще и тем более до состояния «всё спалить на своём пути».
      А у клиента иль руки кривые или планки давно не планки ;)


      1. ExtenZ
        07.06.2018 17:22

        Память не сгорит, а вот обвязка на материнке ноута — сможет (как-никак ей уже 5 лет)


        1. POS_troi
          07.06.2018 21:09

          При исправной планке, ничего не сгорит.
          DDR3L полностью, обратно, совместимы с DDR3.
          Вот наоборот уже сложнее, точнее зависит от «свежести» DDR3 планки, запросто может завестись на 1,35в но стабильность работы будет под большим вопросом.


          1. ExtenZ
            08.06.2018 08:54

            не тогда не знаю, показал фото = память 12600 ddr3L Apple type oO


  1. poznawatel
    07.06.2018 14:28

    Название некоторых ноутбуков можно вольно перевести: «Вирус, сожги меня легко!»


  1. ruomserg Автор
    07.06.2018 15:28

    Результаты обсуждения ситуации на канале libreboot:

    — Они склоняются к спонтанному выходу из строя двух RINKAN по независимым причинам. Возможно, их спровоцировал нагрев платы в процессе длительного MEMTEST-а. Возможно, по предположению omz, виноват блок питания.
    — Общая статистика выхода RINKAN от тошиба из строя, по их словам, плохая. Заменять рекомендуют на аналог от ROHM.
    — Описанный в статье сценарий КЗ LDO Rinkan через PMH они считают маловероятным. В худшем случае они ожидали бы подгорания выходов PMH, а не стабилизатора RINKAN
    — В стабилизаторе RINKAN есть встроенное ограничение по току на уровне 55mA
    — Неиспользуемые пины PMH должны действительно висеть в воздухе
    — PMH напрямую подключен к ICH по шине LPC, и от прошивки EC это не зависит
    — Тем не менее, они рекомендуют провести эксперимент с запуском memtest и ограничением тока LDO VCC3SW.


  1. arthur_veber
    07.06.2018 15:55

    то есть в итоге тест memtest'ом эти ноуты как раз и не прошли ))
    (хотя по комментам получается что не в этом дело может быть).
    А мне нравятся эти модели (lenovo T, X-серии): живучие, легко разбираются. Да, есть кирпичи, но в основном по опыту только положительные эмоции. Почему то порадовало когда увидел их на МКС (всмысле по видеороликам...)


  1. Karafuto76
    07.06.2018 15:58

    всё выше сказанное интересно… я профан в сием вопросе… а не проще просто иметь под рукой стенд для теста памяти?


    1. Atractor
      07.06.2018 19:38
      +1

      Не проще, ибо есть вероятность несовместимости с _конкретно_вот_этой_платформой_ вплоть до того, что все тесты проходит корректно, а ОС не загружается или странные сбои в работе — остановы, перезапуски рандомные BSOD. Да, но тесты — это первое что следует делать после замены, ибо некорректная работа ОЗУ может повредить данные на накопителе (в случае с *nix-based системами вероятность меньше).


  1. ZyuZya
    08.06.2018 08:13

    На этой неделе случилась аналогичная проблема с ноутбуком HP EliteBook G1. Ноутбук был благополучно выключен через кнопку «Пуск» в пятницу(01.06.18) в конце рабочего дня, отключен от питания и положен в рюкзак. На выходных ноутбук с рюкзака не доставался, не включался. В понедельник утром при попытке включить ноутбук, индикатор питания включается на несколько секунд и после гаснет, при этом ноутбук никаких признаков жизни не подает. Сервисный центр поставил диагноз — смерть материнской платы.

    Возможно просто случайность или обычное совпадение, но мне кажется что возможно проблема не в memtest, а в чем-то другом. Например обновление Windows, какая-нибудь сервисная утилита по диагностике, вирус и т.д.


    1. BubaVV
      08.06.2018 12:54

      О, такое у Элитбуков бывает часто. Причем постояв какое-то время (до нескольких часов) с подключенным БП и аккумом заводится нормально. Носил в сервис, проверили дежурку — сказали все норм. Предположили отвал видеокарты. Мое личное предположение — из-за броска тока при старте сваливается в защиту какая-то из многочисленных схем питания


    1. SergeyMax
      08.06.2018 13:15

      Всё в порядке, это феномен Баадера-Майнхофа