Комментарии 122
А как же «Press ESC to exit...»
*здесь была картинка с разочаровавшимся бухариком.
Разве не интереснее бы выложить фото потрохов (хотя бы трупика)?
Видимо, повреждена внутренняя логика микросхем, и это не лечится...
Извините, конечно, но тут дело только в целесообразности. СЦ (или народный умелец) может микросхемку-то поменять. На али море типовых микросхем и может быть повезёт найти нужную. Нужно только её обозначнение. Особенно, если немного по стоимости.
Хотя, как я уже написал, посыл в «извлекайте безопасно» и всё хорошо кончится.
А что там смотреть? Такой кирпич по фото ничем от нормального отличаться не будет.Почему же? Увидим микросхему-виновника (её обозначение) и сделаем выводы. Например, можно узнать, косяк это конкретной модели/ревизии/партии с этими микросхемами или вообще всей линейки на такой платформе. К тому же, потом проще будет самоделкиным диагностировать. Звоним обвязку, меняем микросхему и
И как я понял, автор делал тестирование «поднимание ноги», когда оживлял первый ноут программно.
Хотя, как я уже написал, посыл в «извлекайте безопасно» и всё хорошо кончится.Предположение, что при нажатии Esc memtest вдруг откатит все изменения, какие он делал, для меня звучит фантастическим. С чего бы ему это делать? Предполагается, что вся память volatile, и перезагрузка всё равно всё сбросит. Та, что не замаплена на устройства, разумеется, но в замапленную писать случайные паттерны — самоубийство (как мы видим из статьи), да и задачу тестирования памяти оно всё равно никак не поможет выполнить.
Выход из memtest по ESC != насильному выключению во время выполнения записи-чтения бог-знает-куда. Есть вероятность, что программный reset при корректном выходе из теста выставил бы все в исходное состояние.
Стараюсь, если лень ждать пока операционка загрузится, выключать всегда после процедуры всех инициализаций — или в grub или по F8 в меню винды.
Привычка берет корни со времен материнских плат под сокетА на логике Nforce2.
Они очень не любили выключения или сброса во время процедуры POST и инициализации PCI устройств и нелюбовь свою выражали в слёте прошивки BIOS.
В те времена работал в сервисе и материнских плат на Nforce2 с такой проблемой было не одна-две, а десятки.
Так что как писал товарищ выше «извлекайте безопасно» и всё хорошо кончится.
Неизвестно, дежурный источник убился во время теста или же после насильного выключения что-то зависло и само себя изжарило.
В memtest, кстати, ESC не всегда мгновенно срабатывает. Иногда с ощутимой задержкой и кажется что он повис.
Начать стоило с обзвона сервис центров на предмет (а у вас нет дохлой матери от IBM таких-то серий?) Если в той микрухе никаких серийников не хранится, то перепаять и радоваться.
Даже то время, которое удалось потратить на исследование — выделили только из-за крайней необычности случая (два T500 с интервалом в полчаса, и неизвестно почему). Вообще, цель была — дать рекомендации, чтобы и остальные наши буки не погорели. То, что один удалось даже восстановить — это приятный (временный!) бонус. На оба ноутбука будем заказывать с разборов материнские платы, и менять (даже ту, которую восстановили). Простой команды разработчиков где-нибудь в командировке обойдется много дороже стоимости новых материнок.
Вот они на плате: с белой наклейкой — EC, следующий — RINKAN, следующий — PMH. Следов подгара обнаружить не удалось ни при простом осмотре, ни при осмотре с лупой. Снимок сделан в момент подпайки проводов для подключения внешнего регулятора 3.3 вольта (конденсатор C611 сдут, нога RINKAN отпаяна и поднята).

А ruomserg не советую припаивать такие толстые провода к SMD, неосторожное движение — и контакт оторван. В таком случае лучше 2-3 жилы от провода отогнуть и их припаивать, остальные лишние жилы откусить, провод зафиксировать к плате изолентой.
за 10г. тюбикопечатался
На али NC-559-ASM встречал без RMA разве что. Не знаю, есть ли там канифоль.
Я ввиду крайней нужды взяли забадяжил сам.
Состав такой: аптечный вазелин + жидкий безотмывочный флюс ФПБ. Расплавил феном вазелин (на 100 градусах) и смешал с флюсом. Наношу кисточкой, чуть подбавляя по мере испарения. По мере застывания, конечно, разделяется на фракции, но можно наносить и так. Может быть и можно как-то газировать и смешать под давлением до однородной структуры и упаковать в шприц, не пробовал.
Для BGA, QNF, конечно, не подойдёт, но кое-что типа SMD паяльником поковырять можно. Медь лудится влёт, провода многожильные продирает «до самых до глубин». Выходит весьма дёшево. Смывается калошей, можно смешать её с изопропилом 1/1 или уайт-спиритом.
Думаю можно и вазелиновое масло взять. Хочу попробовать смешать силиконовый вазелин. Глицерин для флюсов использовать категорически не советую.
Да, если лудит очень хорошо, значит флюс активный и смывка обязательна.
Насчёт проводов: конечно, толщина критична, если нет других, то я прокладываю, закрепляю, а после уже припаиваю, дабы исключить отрыв дорожек. Можно использовать литцендрат от наушников (у комплектных от продукции Apple весьма неплохие провода), там, действительно, можно использовать несколько волосин. Лудятся хорошо активным флюсом, за неимением — в среде хлора, например на кусочке ПВХ.
Видимо, всё-таки склонна к отказу именно сама микросхема. Может быть защиты какой-то не хватает, статика, пробой, банальный перегрев при активном обращении-стресс работе (memtest) или наводки какие-то есть. Заменить не проблема.
С 輪姦 / rinkan здорово hd_keeper подметил, забавно получилось, правда, омофон, но склонность микрухи к отказу и то, что ломается, даже занятно.
Странно это. По идее memtest должен ходить только по DDR RAM и не пытаться писать в memory mapped io. Иначе, чудеса начались бы намного раньше, ещё в момент натыкания на регионы куда замаплена PCI.
Недавно похожее было, хотя там еще не понятно, кто виноват. habr.com/post/409009
Не могу согласиться что 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 может вляпаться.
Не могу согласиться что memtest виноват.хехе, действительно заголовок звучит как «гадкий мемтест, который убьет ваш ноут» (и его, наверно, стоит переделать в «ноут, который может быть убит простой записью в память (например мемтестом)»)
- Memory-mapped I/O (MMIO)
- 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
Вторая «любимая» ошибка — когда протокол взаимодействия с EC (и прочими так называемыми Super-I/O) требует монопольного доступа к шине. Например, когда парой OUTB специфических значений в специфические порты открывается «секретный» доступ к Super-IO контроллеру.
Для исключения конфликтов, в таких случаях на время обращения к Super-IO приходиться «глушить» все ядра на всех CPU и запрещать прерывания (15 лет назад пришлось повозиться с подобным в специфической драйвере, чтобы безопасно включать «турбо-режимы» на COM-портах).
Поскольку рядом нет никаких дросселей — можно предположить, что построен этот регулятор по простой линейной схеме.Вроде бы логично. Но! Многие производители выпускают высокочастотные импульсные регуляторы со встроенным дросселем, например. Кроме того, бывают регуляторы на переключаемых конденсаторах.
Батарея несъемная, но в BIOS-е, видимо специально для этого, сделали возможность отключать ее программно.
Батарея у HP тоже на уровне 60-80% после месячного простоя.
Столкнулся с такой-же проблемой, только на другой материнке (asus b350-plus). Первый раз система ссд пропал когда установил новую 1060. Подумал на то, что гпу много ест через линии pci на старте, поменял на другую модель (с 6pin на 8pin доп питание), вроде проблема пропала. Но иногда все же ссд не видно, особых корреляций не приметил (разае что при выключении зажимом кнопки питания). Лечится простым отстоем десктопа в обесточенном состоянии на некоторое время (магия).
Про магию конечно-же шутка А что казается пыли или плохого питания: проблемы возникли на свежесобранном десктопе, с двумя бп от разных производителей на 500 и 750вт (второй специально подбирал с повышеным током по линиям 12v)
Попробуйте вот это:
https://youtu.be/0YM3WfHk5To
И коментатору выше киньте, у меня неполноценный аккаунт, ответить ему я не смогу.
А на Lenovo зря нападаете, кому как повезет.
Свой S90 я заряжаю раз в неделю (это в обычном режиме общения со смартфоном). Если на работе запарка и звонков уйма, то зарядки хватает на 2-3 дня. Планшет YB1-X90L как-то пролежал без дела почти полгода, и я был приятно удивлен, что уровень зарядки практически не изменился.
Jedem das Seine!
пожалуйста, сообщите в Lenovo и Microsoft.
Если вы не отзовётесь, мы напишем в Спортлото
Простите, а при чём тут Microsoft? Memtest писали не они.
А все оказалось так просто… пусть только с некоторыми моделями, хотя…
Я к тому, что в принципе бывают всякие окольные пути. Но они все не универсальные, требуют особых условий.
***
Очень образный заголовок. Почему — то мне представился программист, которого заставляют запомнить неудобоваримое количество кода ( тестируют память ), и в конце концов из его глаз ударяют жуткие молнии, уничтожающие компьютер, служащий источником пытки.
По идее, оживить несложно, но отсутствие запчастей озадачивает.
Печально. Есть ли какие-то способы безвредно проверить, подвержен ли ноут этому багу? Я довольный обладатель W520, хотелось бы как-то себя обезопасить на будущее, кроме способа «ни в коем случае не запускать memtest».
Наша самая главная надежда — это, конечно, восстановленный ноутбук (собственно, я с него и пишу сейчас). Когда подойдут материнские платы на замену — устроим натурный эксперимент. Для этого отпаяем выход LDO у починеной платы и подрубим внешнее питание с токовой защитой (скажем, миллиампер 50). Погоняем сначала просто так — чтобы убедиться что ложных срабатываний защиты нет, а потом запустим memtest. Если токовая защита сработает и вырубит все нафиг — значит вот оно и попалось! Научимся тестом баг фиксировать — считай, уже победили…
Во первых, в случае если это LDO, как выпишите:
«И, видимо, в какой-то момент то-ли поднял, то-ли опустил неудачную ногу PMH. Соответственно, через выходной транзистор ноги PMH, шина питания VCC3SW оказалась накоротко замкнута на землю...»
Из каких соображений это написано? Взято из воздуха? Транзистор в линейном стабилизаторе не включается на землю, он включается между входным напряжением и нагрузкой, а затвором рулит управляющая схема с ОС. Если транзистор полностью открыт (или пробит), то на нагрузке будет не КЗ, а полные 20В со входа.
Обычно в контроллерах никто не будет делать цифровое управление аналоговым сигналом (управление затвором и регулирование), т.к. нужны фикс 3,3В, от контролера требует только сигнал ON-OFF. Поэтому данная версия полностью исключена.
Если это имульсный DC-DC (маловероятно): опять же, никто не формирует по цифровым шинам ШИМ сигнал, особенно в том случае, если нам нужен только фикс 3,3В.
В общем, все это не более чем надумка. Есть версия более простая, из опыта ремонта ноутбуков в т.ч. на аналогичных платформах. Преобразователь в контроллере 20В->3,3В приказал долго жить после проблем с иточником питания, либо нагрева, либо сам по себе (такое то же бывает). Может быть и сам контроллер умер быстрее преобразователя и потянул за собой остальное. Чаще всего случается подобное, что подтверждается отзывами ремонтников подобных платформ (так и пишут — после китайских БП).
— Во время теста ноутбуки стояли на разных источниках питания, а характер повреждений одинаковый
— Все предохранители в цепях питания целы
— До момента отключения питания ноутбуки работали (были они зависшие или нет — отдельный вопрос). Следовательно, питание с адаптера по линии VINT20 приходило на все преобразователи, и ни один из них не ушел в защиту. Сценарий, при котором на все преобразователи приходит бросок, но умирает почему-то только LDO RINKAN (напоминаю, она включена через доп.диоды — т.е. на ней никак не может быть напряжение больше чем на VINT20) кажется нам маловероятным.
— Условно-подозрительный блок питания в переговорке подключался к ноутбуку N1 на короткое время, и при этом уже не зажигался светодиод DCIN на панели бука. То есть, бук уже демонстрировал симптомы, характерные для смерти VCC3SW. Да, есть вероятность что это короткое подключение его тоже убило. Мы поместили адаптер в карантин, и используем его для проведения эксперимента. Сейчас времени и техники для эксперимента (с потенциальным выходом из строя еще одного ноутбука), к сожалению, нет.
— О вопросах схемотехнической реализации LDO в RINKAN смысла спорить не вижу, т.к. ни у кого из нас нет надежной информации по этому вопросу. В первом ноутбуке явный отказ схемы регулирования, регулирующий транзистор прикрыт, ток собственного потребления на ХХ 8ma — великоват. Во втором ноутбуке схема регулирования практически пробита на землю с током утечки на ХХ около 0.5A (что вообще ни в какие ворота). Как именно это произошло, по имеющимся данным восстановить мы не можем.
Я лично нес в руках бук N1 с момента его выключения после memtest и до попытки включить в переговорке. Он реально был рабочим 30 минут назад, а потом не реагировал даже на штекер питания (должен светодиод загораться, даже если бук не включен).
Вы же и пишете, что оба подкючались к одному источнику. И не загорался светодиод. Да, сгорает моментально и как раз в момент подачи внешнего питания.
Предохранитель останется цел по двум причинам: т.к. общий ток потребления (с горелым контроллером) не выше его порога срабатывания, либо если возникает КЗ по линии VINT20 (как во втором ноутбуке) входные мосфеты закрываются, соответственно потребления почти не будет.
Умирают не только от броска напряжения, а от шумов источника питания. Диоды вообще ни причем, шумы прекрасно проходят через них.
О LDO и так прекрасно известно. Вы же строите какие то невероятные теории, вроде — выходной транзистор замкнут на землю. Откуда это? Приведите схему такого преобразователя.
Эксперимент покажет, что возможны проблемы с нагрузкой дежурных 3,3В из за каких то там причин, ОК. И? Опять же, в контроллере встроенная защита OCP приведет к выключению контроллера, ноутбук просто выключится. Вообще не факт, что проблемы с нагрузкой вызовут выгорание контроллера.
Зато есть реальное предположение — если посмотрите даташите на аналогичные контроллеры (ту же тошибу из апдейта), то поймете, что эти 3,3 используются и внутри контроллера и там уже вполне возможен внутренний пробой этого напряжения на землю.
Если у вас нет осциллографа, диагностировать импульсные цепи почти невозможно, соответственно лучше тот БП куда нибудь подальше закинуть и больше не включать.
Если вы находитесь в Москве, можете заказать контроллеры и отдать платы мне на восстановление — вы обратились не в тот сервис.
Во-вторых, когда за утро у тебя без видимых причин умирают два ноутбука корпоративного класса — на ум приходит одна цитата из Стругацких: "… Нам разрешается прослыть невеждами, мистиками, суеверными дураками. Нам одного не простят: если мы недооценили опасность. И если в нашем доме вдруг завоняло серой, мы просто не имеем права пускаться в рассуждения о молекулярных флуктуациях — мы обязаны предположить, что где-то рядом объявился черт с рогами, и принять соответствующие меры, вплоть до организации производства святой воды в промышленных масштабах." © Жук в муравейнике
Камрад omz, в отличие от нас, похоже, что профессионал, и его предположениям (sorry!), я склонен доверять больше, чем вашим.
«Хайп» вы, конечно, подняли изрядный. Но как бы потом вам не стало стыдно перед самим собой — это я без всякого упрека, по своему опыту. Вот когда считаешь, что тебе «все ясно», а потом выясняется, что ты просто «сел в лужу» — чего-то не учел, чего-то не знал.
Вы же понимаете, что ноутбуки делают вовсе не «ламеры» или «лохи». И даже в России ноутбуки просто не делают. Да и вообще, страны, в которых ноутбуки именно «делают» (а не паяют чипы на платы), могут уместиться на одной руке трехпалого человека…
Где чинить не знаю, в нашем Кишинёве чинить отказались
А у клиента иль руки кривые или планки давно не планки ;)
DDR3L полностью, обратно, совместимы с DDR3.
Вот наоборот уже сложнее, точнее зависит от «свежести» DDR3 планки, запросто может завестись на 1,35в но стабильность работы будет под большим вопросом.
А вот DDR3L несколько лет работала у меня в ноуте на 1.5 Вольта.
Сам по себе контроллер ОЗУ вообще не в курсе с чем работает.
Сейчас в ноуте распаяно на матери 4гб ОЗУ DDR3, в свободный слот вставлена планка DDR3L, напряжение которое подаётся на оба комплекта = 1,5в
— Они склоняются к спонтанному выходу из строя двух RINKAN по независимым причинам. Возможно, их спровоцировал нагрев платы в процессе длительного MEMTEST-а. Возможно, по предположению omz, виноват блок питания.
— Общая статистика выхода RINKAN от тошиба из строя, по их словам, плохая. Заменять рекомендуют на аналог от ROHM.
— Описанный в статье сценарий КЗ LDO Rinkan через PMH они считают маловероятным. В худшем случае они ожидали бы подгорания выходов PMH, а не стабилизатора RINKAN
— В стабилизаторе RINKAN есть встроенное ограничение по току на уровне 55mA
— Неиспользуемые пины PMH должны действительно висеть в воздухе
— PMH напрямую подключен к ICH по шине LPC, и от прошивки EC это не зависит
— Тем не менее, они рекомендуют провести эксперимент с запуском memtest и ограничением тока LDO VCC3SW.
(хотя по комментам получается что не в этом дело может быть).
А мне нравятся эти модели (lenovo T, X-серии): живучие, легко разбираются. Да, есть кирпичи, но в основном по опыту только положительные эмоции. Почему то порадовало когда увидел их на МКС (всмысле по видеороликам...)
Возможно просто случайность или обычное совпадение, но мне кажется что возможно проблема не в memtest, а в чем-то другом. Например обновление Windows, какая-нибудь сервисная утилита по диагностике, вирус и т.д.
На lenovo t510 при покупке озу гонял memtest более 2 часов. Может быть и 4 часа… Было и много тестов от 2 до 30 минут. Никаких проблем не было.
NB. Биос патченый, ибо стоит неродная wifi-карта.
Тест памяти, убивающий ноутбуки — почти детектив