Недавно у нас произошла душераздирающая история — за одно утро умерли два ноутбука 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 не имеет выходов на шины CPU — он в принципе недостижим для процессора. Одна из важных (и неочевидных) функций RINKAN — это генерация стабильного напряжения 3.3v на шину VCC3SW (назовем ее стартовой шиной). Поскольку рядом нет никаких дросселей — можно предположить, что построен этот регулятор по простой линейной схеме. То есть где-то там внутри сидит транзистор с обвязкой и своим активным сопротивлением высаживает мощность, оставляя после себя только 3.3v. Запитывается этот регулятор по ноге VREGIN20, на которую через диоды объединены все источники питания ноутбука (док-станция, адаптер питания, главная батарея и батарея ultrabay). То есть он работает вообще всегда (потому и маломощный — нужен очень малый ток собственного потребления!)
PMH — более интеллектуальная микросхема. Как минимум, у нее есть связь с EC по шине SPI. Кроме того, она включает или выключает целую кучу напряжений и тактовых сигналов на материнской плате ноутбука. Обе микросхемы заказные, без наличия datasheet-ов. Поскольку Lenovo/IBM использует одни и те же заказные микросхемы для разных линеек устройств — некоторые ноги PMH в T500-ом не используются. Однако, вряд ли их оставили висеть в воздухе. Типовые рекомендации предлагают подтягивать неиспользуемые выводы либо к питанию схемы, либо к земле. Запомним это.
Несмотря на отсутствие документации, команда проекта Coreboot сумела (сопоставляя схемы ноутбуков серии T60, T40 и старше — где функции RINKAN/PMH еще были разделены между микросхемами меньшей степени интеграции) накопать кое-что интересное. PMH доступен в адресном пространстве CPU. Не напрямую, конечно, а через EC — но все-таки доступен! Чтобы поднять или опустить ногу 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 — все просто.
К большому сожалению, memtest делает примерно то же самое — читает и пишет разные значения в разные области памяти. Теоретически, BIOS должен описывать области памяти, зарезервированные под устройства ввода-вывода. А memtest не должен туда ничего записывать — но… записал! И, видимо, в какой-то момент то-ли поднял, то-ли опустил неудачную ногу PMH. Соответственно, через выходной транзистор ноги PMH, шина питания VCC3SW оказалась накоротко замкнута на землю...
Что было дальше? Дальше RINKAN начал греться. Потому что ток рос, транзитор PMH в ключевом режиме его без проблем протаскивал, а полуоткрытому транзистору в LDO RINKAN становилось все хуже. Но внешне, это никак не проявлялось: во включенном ноутбуке никто не ест с маломощного источника 3.3в, а питание подает специальный мощный DC/DC запитывающий главные шины 3.3 и 5 вольт соответственно.
Ну а когда нажали кнопку питания — главные шины обесточились. Питания же на стартовой шине 3.3в уже не было! И ноутбук превратился в тыкву кирпичик.
С этой теорией приступили к диагностике:
Первый ноутбук — плата COR5SOPV3 с двойной графикой. На шине VCC3SW вместо 3.3, всего 1.2 вольта. Сопротивление на землю — около 400 ом. Аккуратно отпаяли и подняли выход преобразователя напряжения RINKAN. Сопротивление по шине сразу возросло до сотни кило-ом. Подали напряжение 3.3в с внешнего источника — бук ожил. В результате, подобрали внешний маломощный 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-мейнтейнерам пакета отписан, может быть с апстримами чего и найдут...
На этом все — удачи!
И это… вы с тестами памяти давайте все-таки поосторожнее — оно вот ведь как бывает!
Автор: ruomserg
