В ядре Linux, начиная с выпуска 5.2, проявляется ошибка, которая приводит к нарушению содержимого регистра AVX при возврате из обработчика сигнала, обрабатываемого при генерации исключения (page-fault). Проблема возникает при запуске многопоточных программ ("-pthread"), в которых имеются вычисления с регистром AVX, в случае сборки ядра в GCC 9 (при сборке в более ранних выпусках GCC ошибка не проявляется, так как GCC 9 кэширует адрес переменной thread-local в функции, а более ранние версии GCC загружают его каждый раз)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51937
А сколько Go-погромистов думали, что у них руки кривые...
Как будто это не так.
Как видите - нет, не так.
Кривые руки в данном случае, как выяснилось, не у голангеров.
> Кривые руки в данном случае, как выяснилось, не у голангеров.Не _только_ у голангеров.
Это была "закладка", чтобы человек мучился, искал проблему, читал документацию, тестировал. Своего рода через язык Go хотели сделать сверх-программистов, не знающих боли, сна и всегда идущих к цели. Наверно :)
Кто кричал, что Go не нужен? Вот и профит! :)
>Go не нуженБез докера и k8s в современном интерпрайзе далеко не уедешь.
До Сколково, разве что.
Это не в современном энтерпрайзе, это хипстеры кроме модно-современно ни в чем не разбираются.
При этом они создают инновации, зарабатывают деньги... А вы хотите предложить иной путь?
Клепать шаблонные сайты != инновации.
mesa(vulkan), вычислительная химия итд на c99.
и множество скриптов на питоне.ой, как же так, ведь все на пюре-си?!
Вы же сами написали "множество скриптов". Речь про ядро, а не про скрипты. В общем, ваш парад в другом месте, проходите дальше, не задерживайте.
Настоящие пограмисты должны писать только на C89, всё, что было создано после, это для тупой хипстоты, которая не осилила ...
У тебя память как у рыбки. Тезис был в том, что инновации это только хипсто-тех, я его опровергнул.
Я не хотел вызвать сомнение в твоей профессиональности. Настоящий ты или нет
Вы там передернули, приравняв хипсто-тех=клепать шаблонные сайты.То есть по предмету- ничего не сказали.
Ну вот что сейчас модно-современно?
дата майнинг
машинное обучение
питон
голанг
джава+диалекты
быстрое развертывание
консолидацияа вы ни о чем кроме шаблонных сайтов походу понятия не имеете :)
Тем более что то что вы привели в качестве аргумента "вычислительная химия итд на c99" - это внутритематические вещи.
Понимаете?
Нет?
Ну вот есть тематики а есть айтишники. Айтишники создают инновации в ИТ, а тематики- в своих областях. При этом в отношении ИТ- тематики исключительно архаичны и некопенгагены ниразу. Поэтому и используют то что им досталось в наследство.. без всяких инноваций..
Хотите наглядный пример? Вон в соседней ветке товарищ ковыряет систему какого-то там микро-нано-моделирования, и ковыряет ее так как понимает... железо он не знает, ПО не понимает. Если у него и случится какой-то прорыв- он будет ниразу не в ИТ области, а в его предметной, и использоваться у него буде не то что можно современно - а древние проги написанные на коленке кодтато...бБез всяких инноваций (тоесть вместо графического ускорителя все наверное считается на процессоре.)
дата майнинг - на С
машинное обучение - на С
питон - пффффф
голанг - пффффф
джава+диалекты - диалекты??
быстрое развертывание - муахахахахах
консолидация - муахахахахахденьги приносят из всего перечисленного только верхние два пункта.
и только попробуй скажи, что оно на питоне. с тем же успехом можно сказать, что оно на шелле.
Машинное обучение-на python. Соседи по этажу гребут бабки на хайпе нейронок и всё у них на питоне.
> Настоящие пограмисты должны писать только на C89, всё, что было создано после, это для тупой хипстоты, которая не осилила ...Вся эта молодежная C89 исключительно для тупой хипстоты, что не осилили COBOL и Fortran.
Перфолента вам в зубы ...
Ты это не скажи толпам C++-ных гуру. У них-то как раз юзающие С89-старпёры-неосиляторы великого и могучего какого-то там по счёту C++.
>Это не в современном энтерпрайзе,У вас потрясающие знания. Может быть вы и 1с умеете устанавливать?
Эксперты как всегда подъехали, вижу.
это троллинг или ты реально такой идиот?
так проблема в ядре или в гцц?
Да.
В ядре.
В ядре и в ЖэЦэЦэ.
Или в Го
Go вообще не при делах, прост заметили первыми.
Что говорит о том, что с Go программы по-умолчанию лучше оптимизированы (используется AVX). Значительно чаще чем GCC/Clang.
AVX(MMX, SSE, AVX2..) используется только в векторизации математики и пользу приносит только и исключительно при обработке больших объемов данных. А с автоматической векторизацией уже лет 10 отлично справляются всякие gcc.То, что в Го оно везде и всюду - это большой и жирный минус, ибо лишний комбайн в курятнике не нужен.
Регистры SSE часто используются вовсе не для вычислений, а как дополнительная память для локальных переменных.
Возможно в данном случае так.
Идиот? Регистры SSE не умеют работать кусочками и пересылать/принимать данные в другие регистры общего назначения, а только через память.Так объясни, нахера в них держать локальные переменные, если перед их использованием их все равно придется сложить в кучу/стек? Да заодно еще и потерять дополнительные 500 тактов на переключении задач (цпу флажок устанавливает, если юзались ссе и тогда при переключении задач в контекст заодно сбрасывается весь пул ссе регистров)?
Ответ на вопрос - да.
Умеют.movq xmm0, rsi
cvtsi2sd xmm0, rdiОписание команд найдёшь сам.
gcc
В ЦП.
Линус вежливо шаркнув ножкой и с поклоном, умоляет разработчиков не ломать юзерспейс
по этому нужно оставить все как есть - а то сломается такая фича, как сломанные avx
А это точно ошибка в ядре Linux?
Если факты не вписываются в картину мира, то тем хуже для фактов!
Немного сложнее :) Просто 9-й gcc лучше оптимизирует код и оставляет значение в регистре вместо повторного считывания. Но в конечном счете, имхо, да, это ошибка ядра.
Оптимизация от создателей
int rand()
{
return 4 // Гарантированно случайное число. Выбрано подбрасывание кубика.
}
Нет, просто забыли использовать READ_ONCE() для получения переменной, а GCC 9+ лучше оптимизирует код. При сборке GCC 8 баг не проявляется.
чёт тоже кажется что это gcc мутит..
Это ошибка _проявляющаяся_ в ядре.
В Винде
Билл Гейтс лично это проклятье нассылал
Но Линукс выстоял - он же непогрешим
" Рассматривается возможность добавления в runtime языка Go изменений для выборочного обхода ошибки на проблемных ядрах Linux, ценой появления дополнительных накладных расходов." заодно и Kotlin поправить, там то же *рутины. Ужасный костыль будет.
pthread используется в over9000 *nix приложений
И
pthread != coroutine
LOL. поменяйте теплое на мягкое
А на что ты поменял свой сканнер, red shadow?
Ю Рассматривается возможность добавления в runtime языка Go изменений для выборочного обхода ошибки на проблемных ядрах Linux
Дети, не водитесь с ядром Linux, а то костылями заразитесь.
> Ю Рассматривается возможность добавления в runtime языка Go изменений для выборочного обхода
> ошибки на проблемных ядрах Linux
> Дети, не водитесь с ядром Linux, а то костылями заразитесь.Едро твоей в*нды 9-ым GCC собирается? И голоангеры - довольны?
Так держать!
Дай исходники ядра в*нды - попробую и расскажу.
пожалуйста: https://github.com/pustladi/Windows-2000
ждем рассказа.
*вкрадчиво* а ещё более древнего от ещё более мутной персоны не нашлось?
Это не тот рассказ, что был обещан.
Это просто Пирамида Маслоу-Костыля
Software - состоит из костылей на 35%
OS - состоит из костылей на 50%
Firmware - состоит из костылей на 90%
Hardware - состоит из костылей на 100%Вывод: любые вычислительные машины -- это костыль.
"Головой надо думать" - как говорил мой Дед, перед тем как хлебнув самогону, закидывать проезжающих городских коровьими лепешками.
А мой дед говорил: «Я твой дед!».
Этим дедом был Альберт Эйнштейн
Иерархия потребностей Маслоу (которую некоторые люди называю "Пирамидой") она про потребности и порядок их удовлетворения сообразно внутренней ценности, а не про состав.
Без венды и не туды и не сюды.
Сочувствую
>В ядре LinuxНу так just for fan же, врочем ничего нового.
Ну да, во всеми любимой ОС такого нет. Только антивири всё-равно как-то в ядро умудряются свой код пихать, чтобы незаметно сливать данные пользователей. А это уже не just for fun.
почему "незаметно"? На чорном-пречорном экране синюю табличку с надписью "уверены ли вы, что", ОК нажимал? "Не помнишь"?! Что там было написано - тоже не помнишь, или вообще читать не пытался?Ну, вот, для таких - "незаметно".
но ведь на самом деле незаметно. руткиты это спокойно делают уже лет 15.
большая часть - таки с попустительства юзверя, в том числе бодро кликающего OK, или через далеко не 0-year уязвимости. Незаметный 0-day rootkit штука дорогая, ценная, живет очень ограниченное время (и чем чаще применяется, тем это время короче), на вас ее тратить точно никакого резона нет.А антивирус просто вежливо спрашивает - хочешь меня?! Ну хочешь же ж?! Чпок... Добрый вечер!
> just for fanЭто «Для вентилятора» что ли?
>> just for fan
> Это «Для вентилятора» что ли?"[Остр]по за фантики" !
жаст фофан
Уровень знаний критиканов продемонстрирован.
Разницу между fun и fan видишь?
Не напрягайся, это же типичный "анонимный эксперт опеннета", для них обычное дело пользоваться лексиконом, который они не понимают.
Блин, а я уж думал что кто-то делает вещи «just for fan», «чисто для вентилятора». Хотел бы и книгу такую прочитать :-D
fan нужен, чтобы на него shit лопатами вкидывать. Не нужно читать специальных книг, чтобы производить дерьмо для вентиляторов. Есть врождённая функция человеческого организма, которая справляется сама.
Есть такая книга, называется «Just for fun», но современные обитатели опеннета о ней не слышали, судя по всему. Моя фраза про то, что хотел бы почитать и книгу «Just for fan» была отсылкой именно к ней.
> Моя фраза про то,
> что хотел бы почитать и книгу «Just for fan» была отсылкой
> именно к ней.Она получилась довольно забавной отсылкой, намекающей на то, что Торвальдс запилил linux только для того, чтобы набрасывать на вентилятор. Это ещё забавнее потому, что Торвальдс бывало реально набрасывал на вентилятор. То есть в доле шутки есть своя сермяжная истина.
Нужно читать книги, что бы знать историю
https://english.stackexchange.com/questions/21860/whats-the-...
Да. Мы, анонимные эксперты опеннета, только для вентилятора и пишем свои комментарии.
юзайте rust
"благодаря раст я понял насколько красив c++" (c)
И хрустоедов опустил красиво.
Я не вижу каким образом он опустил. Я вот тоже оценил C++ только после знакомства с rust'ом. И это не мешает мне быть фаном раста. И я не вижу в чём опускание? В том, что это намёк на тупизну заурядного растофила, который может понять С++, только через призму rust'а, потому что rust освоить проще чем C++? Ну, может быть и так, но я это вижу скорее как камень в огород C++, который настолько беспорядочно развивался, и такое количество идиотов привлёк, что найти стоящую инфу по нему, не будучи специалистом в C++ практически невозможно.
Ты это серьёзно, насчёт инфы? Книги Саттера, C++ Core Guidelines и https://isocpp.org/faq покрывают фактически всё.Насчёт "раст освоить проще" я, кстати, категорически не согласен - он хочет, чтобы разработчик как-то очень специфически свернул мозги, в то время как плюсы совершенно спокойно ложатся на существующие привычки почти из любого распространённого языка. Единственное, что надо - понять, что есть данные (и у них есть владелец), а есть указатели и ссылки на них, и что это разные вещи.
Раст как раз помагает это все понять, в самой что интераетивной форме, заодно прикрывая твою задницу каждый раз, когда ты лоханулся. Изворачивать мозги не требуется
> Ты это серьёзно, насчёт инфы?Да.
> Книги Саттера, C++ Core Guidelines и https://isocpp.org/faq
> покрывают фактически всё.Я не говорю, что хорошей инфы нет, я говорю что её хрен найдёшь, если не знаешь что именно ищешь, если не знаешь как должна выглядеть хорошая инфа по C++. Про C++ с умным видом вещают толпы идиотов, каждый из которых нашёл в C++ что-то там своё, и считает что так и надо.
> Насчёт "раст освоить проще" я, кстати, категорически не согласен - он хочет,
> чтобы разработчик как-то очень специфически свернул мозги,TL;DR Самый простой способ освоить C++, это освоить раст, а потом потратить пару вечеров на то, чтобы пролистать Страуструпа.
Ой, "специфически свернуть мозги" -- это довольно просто. Если для этого есть официальный хендбук, пара полуофициальных хендбуков покрывающих некоторые тонкости, и куча референсного кода, то дальше остаются чисто технические сложности, надо найти достаточно времени для того, чтобы полепить куличики в песочнице.
А, я чуть не забыл про реддит. Там офигенное сообщество растоманов, туда можно придти с куском кода, на который ругается борроучекер, и тебе объяснят почему он прав, что именно ты сделал не так, уточнят у тебя, что ты хочешь сделать, и предложат способы как это можно сделать. В этих условиях, надо быть либо слабоумным, либо элементарно не хотеть осваивать раст, для того, чтобы не освоить его за 3 месяца, до уровня пониманя того, зачем и когда нужен unsafe и как его использовать, чтобы не обжечься.
И я отмечу, все эти ресурсы несложно найти, возможно для этого даже гугл не нужен, можно до любого добраться в несколько переходов с rust-lang.org.
> в то время как
> плюсы совершенно спокойно ложатся на существующие привычки почти из любого распространённого
> языка.В том-то и проблема. Каждый приходит со своими идиотскими привычками, и начинает рассказывать что его привычки лучше всего, что именно так и надо писать на C++. И среди всех этих рассказов практически невозможно найти те, чьи авторы реально попытались сломать свои старые привычки, заточенные под C/asm/Lisp/..., и выработать новые, которые лучше подходят для С++. То есть, если ты заранее знаешь, какие привычки лучше подходят, то найти изложение этих привычек несложно. Но если ты не знаешь, то ты не можешь отличить хорошие привычки от плохих. Единственный способ -- это несколько лет практики, когда ты перелопатишь всю ту бочку дерьма, которое предлагают доморощенные C++-гуру, и выберешь оттуда искомую каплю мёда.
Блин, глянь на Common Lisp. Пятая ссылка в ddg по запросу "Common Lisp" -- это "Practical Common Lisp", книга которая разбирает CL на примерах, решая вполне практичные задачи лисповым способом. Достаточно прочитать эту книгу за пару вечеров, и ты уже понимаешь как надо писать на CL. Да, ты не знаешь что такое meta-object protocol, и не можешь ещё запиливать свои ООП системы поверх CLOS. Ну и чё? Это уже технические детали которые ты освоишь тогда, когда тебе приспичит написать бинды к qt, которые позволят жонглировать кутишными классами как first-class объектами языка, не создавая ненужных прослоек между lisp'ом и C++. Это дело техники, а философию программирования на lisp'е ты уже освоил за два дня.
С растом это занимает больше, но путь не менее прямолинеен, просто он длинее. С C++ нет никакого пути, точнее есть пути, но у тебя нет gps-навигатора, который позволит тебе найти эти пути.
> Единственное, что надо - понять, что есть данные (и у
> них есть владелец), а есть указатели и ссылки на них, и
> что это разные вещи.Ой, это вообще не проблема. Эти вещи осваиваются максимум за неделю чтения любой книжки по C или C++. Глянь, я C осваивал полгода в школе, у нас парень читал курс сетевых технологий, и полгода он посвятил С. А года через два я купил какую-то книжку по С++, и освоил весь синтаксис и все абстракции C++ за пару недель. Ни в синтаксисе ни в семантике C++ нет ничего сложного, книжки C++ за 21 день для чайников не врут: всё это реально можно освоить за 21 день, даже если две недели прокрастинировать.
Но здесь обратная ситуация с CL. В CL можно философию lisp'а за два дня усвоить, и потратить потом пару лет на то, чтобы освоить всё остальное, читая документацию. С С++ ты освоишь неважные технические детали за неделю, но философию будешь осваивать потом по кусочкам годами. Я в течение 15 лет знал, что такое наследование в C++, что такое темплит, и как написать иерархию из всяких там Person и Employee да ещё и параметризовать её. И все эти 15 лет я не мог понять, что мне с этим знанием делать и как их применять для решения реальных проблем, все эти возможности были полезны как третья нога, без них на С было проще и понятнее. Попытки писать что-то на C++ упирались в то, что я по тысяче раз менял одни и те же куски кода, потому что так как я задумал их было невозможным дописать. То что-то критичное вдруг отказывалось инлайниться, из-за того что приходилось отказаться от const в заголовке функции, то ещё какая хрень. Попытки задавать вопросы в интернетах разбивались об умников, которые больше стремились объяснить мне, что я ничего не понимаю в C++, чем объяснить мне что мне делать в моей ситуации. А если они и объясняли, то всенепременно скатываясь в какой-нибудь холивар-междусобойчик, типа C с классами -- это сакс, или что Александреску надо распять на одном из крестов С++. И пойди потом разберись, кого из этих отморозков слушать, а кого игнорить.
Не то, чтобы я все эти 15 лет только тем и занимался, что писал куски кода на C++ и компилял их в асм, чтобы посмотреть, что получается, но несколько таких забегов я сделал. И если в результате этих ковыряний и получалось что-нибудь похожее на то, что я хочу, то это получалось через огромное количество усилий, а что хуже, я не видел способа воспроизвести результат на другой задаче меньшим количеством усилий: я не видел чтобы у меня копился какой-то опыт, который бы упрощал жизнь.
Когда же я увидел rust, его borrow-checker за три месяца объяснил мне как надо, посредством битья по рукам за каждую попытку сделать так, как не надо. Да, технически это выглядело примерно так же: я писал кусок кода, и потом многократно вносил в него изменения, чтобы посмотреть что получится. Но с borrow-checker'ом каждая итерация занимала существенно меньше времени, потому что borrow-checker, как правило, на ранних этапах сообщает что я спорол чушь. Он не дожидается, когда я напишу полтысячи строк кода, чтобы потом я вдруг выяснил, что какой-то код, на инлайн которого я надеялся, не инлайнится, и задним числом очевидно почему, и очевидно что ничего с этим не сделать, но поскольку я в этот код передаю огромную структуру по значению, то без инлайна тут плохо. И уйти от передачи по значению не удастся, потому что там какие-нибудь требования стандарта к декларации операторов мешают. Через месяц возни с rust'ом я рылся не только в коде std, но и в коде gfx-rs, и это не представляло никаких особенных неудобств, особенно если сравнить с моими давнишними попытками порыться в libstdc++ -- там такой взрыв синтаксиса, размазанный далеко за края экрана, утонувший в темплитах, с минимумом документации, с совершенно идиотским делением на заголовки и сорцы: в заголовках декларации, в сорцах всё остальное, но есть нюанс: однострочники и некоторые другие inline функции/методы живут в заголовках. То есть это даже читать последовательно невозможно, приходится переключатся между файлами туда сюда, и между разными местами одного файла.
Итого самый простой способ освоить C++, это освоить раст, а потом потратить несколько вечеров на то, чтобы полистать Страуструпа. После этого для того, чтобы кодить на С++ на хорошем профессиональном уровне будет не хватать лишь технических деталей, которые на 95% можно извлечь из документации, а остальное задавая вопросы гуглу.
> Итого самый простой способ освоить C++, это освоить раст, а потом потратить
> несколько вечеров на то, чтобы полистать Страуструпа. После этого для того,
> чтобы кодить на С++ на хорошем профессиональном уровне будет не хватать
> лишь технических деталей, которые на 95% можно извлечь из документации, а
> остальное задавая вопросы гуглу.Ну что ж, первое внятное пояснение о том, какая может быть польза от хруста.
Ох и простыня :-)Не, сейчас правда всё проще. Берёшь guidelines (от Саттера и Страуструпа, которые точно знают, что такое правильный плюсовый код) и молотишь по ним. Для желающих - там же объяснено "почему так". Всё.
Ну, или на первый запрос "C++ what to read" получаешь совершенно осмысленный список саттеровских и подобных книг.
Кстати, стандартный (и почти всегда правильный) ответ на вопрос насчёт инлайнов будет "не морочь голову, оно тебе не надо".
А мозги свернуть - потому что вся borrow-концепция уникальна для раста и контринтуитивна, да ещё и вусмерть перепутана всё с тем же различием "ссылка/значение". Начиная с первого примера из учебника про строку - как только ты понимаешь, что можно скопировать строку, а взять ссылку/указатель все примеры резко начинают выглядеть бредовыми с плюсовой точки зрения. Так что я сильно сомневаюсь, что взятые из раста привычки приведут к чему-то осмысленному в плюсах.
> Начиная с первого примера из учебника про строку - как
> только ты понимаешь, что можно скопировать строку, а взять ссылку/указатель все
> примеры резко начинают выглядеть бредовыми с плюсовой точки зрения.Это первые примеры из учебника. Их задача не столько передать строку наилучшим образом в данном случае, их задача продемонстрировать разные способы это сделать. Их задача показать разницу между передачей по ссылке и по значению. И это нужная штука в случае rust'а, даже если читатель уже знает про эту разницу, потому что в rust'е передача по значению, по-дефолту, move передача, она оставляет переменную из которой берётся значение неинициализированной. В расте передача по значению чуть другая, чем в большинстве других языков, поэтому нет ничего бредового в том, чтобы эту разницу показать в одном из первых примеров.
Чтобы понять зачем нужны эти все разные способы -- move, copy, по-ссылке -- надо почитать чуть дальше первых примеров. Кстати в C++ тоже есть все эти три способа, просто в C++ дефолты другие.
Бро, прими мое искреннюю поддержку; ты не зря такую простыню наваял.Я более 20 лет плюсовик, я был плюсовиком еще тогда, когда это не было модным и когда большинство отечественных программеров о нем не слышали. Я прочитал (и понял) александреску от корки до корки.
Но сейчас я в основном сишник и лиспер. Ибо в гробу я видел эти плюсы с их полным отсутствием философии языка, но кучей никому не нужных, кроме выеживающейся своим знанием 1000+1 пункта стандарта хипстоты, плюшек. Лучший код в продакшене - это либо базовый с++, либо (если структура проекта не сильно сложная) с.И хотя раст мне не нравится, и я не согласен с последним абзацем категорически; тем не менее все, что раста не касается ты написал абсолютно правильно.
>"благодаря раст я понял насколько красив c++" (c)наоборот
Сколько нужно ждать, чтобы тест сработал? На Ubuntu 18.04 5.3.0-23-generic не воспроизводится. Написали бы какие дистрибутивы подвержены, то есть собираются GCC 9.
Ну это наверно с Ubuntu 19.10 надо пробовать. Только туда засадили gcc 9
На Арче срабатывает менее чем за секунду.
Надо было писать на джава
Какой язык, какое ядро, такой и результат.
IBM катит бочку на Google?
Отродясь такого не бывало, и опять то же самое
Где бы ещё найти такой дистрибутив с ядром 5.2 и выше, с gcc9/9.1/9.2, на которой собирают программы Go? Арчеводы только их и собирают? Ну так и пусть пожинают плоды. Стабильные дистрибутивы работают максимум на ядре 4.19 и gcc 8.3. Планируемый стабильный devuan 3 и тот будет не сильно впереди стабильного debian 10. Так чего хотят от ядра и gcc если сами тормозят развитие дистрибутивов? Пляшите, ядро 5.4 и gcc9 вышло, правда сырые, но релизы-то новые, а archlinux не может глючить - он ведь весь такой современный и безглючный, ведь во всём современном всегда числа в версиях больше.
А без упоминания "Арчеводы" никак... 5.3 пока. А ошибок в стабильных ядрах нет, главное верить.
стабильный devuan это сильно, да.
обновил вчера ядро до 5.4 и два раза словил зависание графики
причем баг старый оказался,но проявился почемуто только в новом ядре
i915 0000:00:02.0: Resetting bcs0 for hang on rcs0, bcs0
Ждите 5.4.13, потом обновляйте и тестируйте. У longterm вообще за сотню после второй точки легко переваливает, и ведь не просто так.
Гендир красной шляпы сидит на ядре 2.6.100500
> Гендир красной шляпы сидит на ядре 2.6.100500Уверен? Мне сообщали подпольщики, что на ядре 2.6.1488.
А можно подробнее, как это может быть связано?
Начал ловить подобное начиная с какого-то 5.3.х на одроиде. Было бы конечно неплохо, если дело в этой ошибке и будет исправлено в следующих выпусках, но уверенности нет.
видимо косяк в драйверах,но на ветке 5.3.... у меня не было таких подвисаний,хотя ошибка в логах посмотрел старых была и до этого...
так что пока только откат... на 5.3.13
Я на прошлой неделе поставил 5.3.12 ядро для поддержки rx470 купленной в Китае - с amdgpu.dc=0 через hdmi вроде бы нормально.
Как раз gcc9.1.0 собирал. Но у меня thuban - там нет AVX.
> с регистром AVXчто такое регистр AVX? он один, что ли?
Поправили уже несколько часов назад = https://lkml.org/lkml/2019/11/27/304
а сломали тут
https://github.com/torvalds/linux/commit/d9c9ce34ed5c892323c...
"Тупыми, оказывается, бывают не только качки!". (Тот, который стрелял из веника) :-)
Не только регистры AVX: https://github.com/golang/go/issues/35777#issuecomment-55918...(Что за bullshit: "Для сообщений данного типа требуется авторизация по картинке (см. ниже)"?)
> (Что за bullshit: "Для сообщений данного типа требуется авторизация по картинке (см.
> ниже)"?)Ты не прошёл тест Тьюрнга -- форум всё понял про твой блшит.
У меня Firefox периодически падал в случайных местах. Причину установить не получалось. Типичный ответ "кривые дополнения" - не прокатил, т.к. без дополнений тоже иногда вылетал. После прочтения данной новости решил попробовать откатится на более старое ядро. И знаете, вроде сработало - вылеты прекратились. Но пара дней не показатель, так что посмотрим как дальше будет работать.
У меня вылеты были из-за проблем у libvpx, на ютубе и так далее. Причём, не каждый раз. В новости упоминается, что это gcc9 слишком хорошо оптимизирует код, про шланг, которым собирается фф, никто ничего не говорил - может быть совпадение. Тем более, что никаких подробностей ты не предоставил.