1. Открываете ящик на абузоустойчивом сервисе в литовской-немецком секторе инета.
2. Ищите того, кто близок к данной проблеме.
3. Описываете, что, где и как можно поиметь с этой компании. Без технических деталей и намеков, где это может произойти.
4. Просите разумное вознаграждение.
5. Если не получаете, то при помощи .onion и прямых рук либо выводите средства со счетов, либо устраиваете локальный хаос с 2-3 аккаунтами.
6. Повторяете п.4
7. Если не прокатило — продаете инфу в темном интернете.
P.S. 272ч.1 Касается только злого умысла. В условиях незаинтересованности второй стороны в устранении проблемы злой умысел спорен. Единственное, закон в России трактуется в пользу более состоятельной стороны. Так что адрес из литовско-немецкого сектора — это нормально.
Сначала найдите «Петю», а потом уже думайте куда потратите полученный барыш. Впрочем, жажда денег может просто перейти в традиции увольнения «Вась» за котиков и непрерывном поиске «Петь» для увеличения продаж. Что ж. Такова структура торгового бизнеса России.
Много работать «отсюда и до вечера» можно только на самого себя. Подобная практика при работе на чужого дядю приводит необоснованному обогащению дяди. Или у Вас для самого последнего сотрудника прозрачна бухгалтерия и распределение доходов? Кто рассчитывает КТУ и по каким параметрам?
Я работаю много, но не по правилам освенцима торговой конторы. Есть задачи, есть деньги, есть сроки. Все четко и прозрачно.
Увы, сдельщина вида «работай больше, получишь больше» это как раз из разряда «копать от меня и до вечера». Не раз наблюдал дележ процентов в отделе продаж в одной из своих старых контор. Просто треш.
У человека есть поставленная задача. И он ее делает в указанный срок. Может даже раньше. А может и выйдет в выходные, т.к. не укладывается. И не все ли равно, чем он занимается в остальное время? Конечно, если Вы не предоставляет работу вида «копать от меня и до вечера».
> Я вообще-то гонял soak-тесты 3 недели на P5600 на Malta начиная с первых релизов, плюс массу других тестов раздельно и совместно. И сидел на шее у HW команды, доказывая им, что у них ошибка.
Первый P5600 на Malta у нас был весьмы странный. Там даже был GIC, но в силу архитектуры Malta никуда не подключался :)
> Я устал добиваться того, чтобы они прошли upstream.
А что говорит Ральф? Хотя, кажется я знаю. Он хочет посмотреть их стабильность на реальном железе, а у него нет ни интераптива, ни p5600. Это, кстати, одна из причин, почему Байкальского кода нет до сих пор в маинстриме.
> И вообще — вы будете в головном офисе в RigaLand 10-го? Можем встретиться лично и поговорить подробно, тут мне не все удобно рассказывать.
Постораюсь быть. Вчера мне анонсировали Ваш приезд.
> Но то, в первых версиях не был включен L2 prefetch в первом варианте ядра Linux, и для данных и для кода
А Вы уверены в стабильности его работы?
Кажется, никому не хочется смотреть на креш дамп при обмене с SATA.
> UBoot гасил Config.MM и производительность падала
Естественно — как и было в errata от Imagination
> MAAR не были сконфигурены (30% при копировании)
Еще раз про стабильность. Проверяли?
> FTLB был выключен — это факт
Про это подробнее. Какая версия SDK?
> а включили ли вы bonding — я до сих пор не в курсе.
В последней версии — да, а до этого — см. errata от Imagination
Про авторство и патчи — как-то абсолютно без разницы сколько их написано и для чего они. Просто формально патчи эти никак не повлияли на подъем Linux на Байкале. А изначальный посыл у «пиарящегося товарища» был именно такой :)
Кстати, мы долго пользовались своими драйверами GIC/GCR/CPC до момента пока в маинстриме это все не стало более-менее стабильно на SMP (и все равно GIC время от времени ломают — как было, например в 4.6).
1. Ну скажем так префетчер там никак особо не обслуживается, есть команда prefetch для закачивания в L2 с физических адресов. Кое-где мы ее там использовали, но никакого обслуживания особого она там не требует.
Только L2 проинициализировать, чтобы ECC работало.
2. Про COP0 и оптимизацию ничего радикального не слышали — в первой версии ядра большинство фитч была перекрыта errata, максимум удалось задействовать спекулятивный режим работы с использованием MAAR, но это делали сами Байкальцы.
3. Про написание патчей в ядро тоже не особо видно, Леонид там больше выступает как ревьювер. С 2015 года Imagination ведет определенную активность в ветке MIPS, в основном для последних ядер, но патчи шлют другие люди.
2. Ищите того, кто близок к данной проблеме.
3. Описываете, что, где и как можно поиметь с этой компании. Без технических деталей и намеков, где это может произойти.
4. Просите разумное вознаграждение.
5. Если не получаете, то при помощи .onion и прямых рук либо выводите средства со счетов, либо устраиваете локальный хаос с 2-3 аккаунтами.
6. Повторяете п.4
7. Если не прокатило — продаете инфу в темном интернете.
P.S. 272ч.1 Касается только злого умысла. В условиях незаинтересованности второй стороны в устранении проблемы злой умысел спорен. Единственное, закон в России трактуется в пользу более состоятельной стороны. Так что адрес из литовско-немецкого сектора — это нормально.
Производственная область, конечно не дает «быстрых денег», но тут хотя бы ясно что чего стоит.
Я работаю много, но не по правилам освенцима торговой конторы. Есть задачи, есть деньги, есть сроки. Все четко и прозрачно.
Первый P5600 на Malta у нас был весьмы странный. Там даже был GIC, но в силу архитектуры Malta никуда не подключался :)
> Я устал добиваться того, чтобы они прошли upstream.
А что говорит Ральф? Хотя, кажется я знаю. Он хочет посмотреть их стабильность на реальном железе, а у него нет ни интераптива, ни p5600. Это, кстати, одна из причин, почему Байкальского кода нет до сих пор в маинстриме.
> И вообще — вы будете в головном офисе в RigaLand 10-го? Можем встретиться лично и поговорить подробно, тут мне не все удобно рассказывать.
Постораюсь быть. Вчера мне анонсировали Ваш приезд.
А Вы уверены в стабильности его работы?
Кажется, никому не хочется смотреть на креш дамп при обмене с SATA.
> UBoot гасил Config.MM и производительность падала
Естественно — как и было в errata от Imagination
> MAAR не были сконфигурены (30% при копировании)
Еще раз про стабильность. Проверяли?
> FTLB был выключен — это факт
Про это подробнее. Какая версия SDK?
> а включили ли вы bonding — я до сих пор не в курсе.
В последней версии — да, а до этого — см. errata от Imagination
Про авторство и патчи — как-то абсолютно без разницы сколько их написано и для чего они. Просто формально патчи эти никак не повлияли на подъем Linux на Байкале. А изначальный посыл у «пиарящегося товарища» был именно такой :)
Кстати, мы долго пользовались своими драйверами GIC/GCR/CPC до момента пока в маинстриме это все не стало более-менее стабильно на SMP (и все равно GIC время от времени ломают — как было, например в 4.6).
1. Ну скажем так префетчер там никак особо не обслуживается, есть команда prefetch для закачивания в L2 с физических адресов. Кое-где мы ее там использовали, но никакого обслуживания особого она там не требует.
Только L2 проинициализировать, чтобы ECC работало.
2. Про COP0 и оптимизацию ничего радикального не слышали — в первой версии ядра большинство фитч была перекрыта errata, максимум удалось задействовать спекулятивный режим работы с использованием MAAR, но это делали сами Байкальцы.
3. Про написание патчей в ядро тоже не особо видно, Леонид там больше выступает как ревьювер. С 2015 года Imagination ведет определенную активность в ветке MIPS, в основном для последних ядер, но патчи шлют другие люди.
Можно узнать подробнее что он помог сделать для Байкал-Т?