Не выключается 16.04
https://s13.postimg.org/61dmbb4on/2018-01-15_22.45.06.jpg
На вот этой надписи может всю ночь провисеть. На CTRL+ALT+DELETE реагирует ребутом как и положено.
https://s13.postimg.org/61dmbb4on/2018-01-15_22.45.06.jpg
На вот этой надписи может всю ночь провисеть. На CTRL+ALT+DELETE реагирует ребутом как и положено.
Щелкает (и очень громко) даже если просто листать 9gag с выключенным звуком, где все ролики по умолчанию в mute. Щелкает не только встроенными колонками, но и в наушниках, если они вставлены.
Началось после недавнего обновления на Ubuntu 16.04
Чет не нашел я как в бубунте (16.04) искаропки сделать чтобы при подключении адаптера питания сразу стало MAX частота процессора, а при вытыкании снова powersafe?
На xU16.04 (lenovo thinkpad L560) наблюдаю следующую проблему - периодически (раз-два в неделю) залипает клавиша на клавиатуре - обычно либо влево, либо пробел, либо backspace либо ctrl. В связи с этим только одно решение - ребут, ибо на сочетания клавиш из-за залипания не реагирует (даже в tty не перейти). После ребута все ок, так что подозреваю софтовую проблему. В /var/log/syslog ничего подозрительного.
Зависает обычно в starbound (влево) или в QtCreator (пробел\ctrl). Иногда (редко) решает так - включением и отключением режима FnLk. В wow не залипало никогда, так что подозреваю что дело в одновременном нажатии какого-то ряда клавиш.
При залипании функциональные клавиши продолжают работать (Fn+F2 - звук тише и проч).
Как отладить и решить? Может это вообще какой-то режим типа виндового shiftx5 включается?
dmesg забит
[ 2372.596719] ACPI: \_SB_.PCI0.LPCB.EC0_.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20150930/nsarguments-230)
[ 2382.604509] ACPI: \_SB_.PCI0.LPCB.EC0_.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20150930/nsarguments-230)
[ 2382.604557] ACPI: \_SB_.PCI0.LPCB.EC0_.ECRD: 1 arguments were passed to a non-method ACPI object (RegionField) (20150930/nsarguments-230)
typedef void (* B)(C *);
typedef struct
{
[..]
B b;
} A;
typedef struct
{
[..]
A * a;
} C;
Уже битый час бьюсь, не могу понять, можно ли решить это нормальным способом. В C всего лишь указатель на A, поэтому скорее всего можно как-то задекларить.
Привет!
Такой вопрос: есть такая вещь как __attribute__ ((constructor)). Предположим я использую его в инициализации библиотеки. Потом использую его в приложении, которое использует эту библиотеку. Я правильно понимаю, что библиотечный ((constructor)) будет вызван раньше приложенческого? Отвечаю на вопрос, зачем мне это нужно - мне надо вызвать функцию библиотеки в инициализаторе приложения, а эта функция работать без инициализатора библиотеки не будет.
Нужен официальный пруф.
Вопрос номер два. А будет это работать в более сложной цепочке? A.so (init A) <- B.so (init B, related on A) <- C.elf (init C, related on B)
Minimal Code Example:
mkdir -p /tmp/libtest && echo -e "#include <stdio.h>\n\nint target = 10;\n\nstatic void target_init(void) __attribute__ ((constructor));\n\nstatic void target_init(void)\n{\n target = 50;\n}\n\nint target_return(void)\n{\n\n return target;\n}\n" > /tmp/libtest/lib.c && echo -e "#include <stdio.h>\n\nextern int target_return(void);\n\nstatic void main_init(void) __attribute__ ((constructor));\n\nstatic void main_init(void)\n{\n printf(\"main_init: %d\\\\n\", target_return())\n}\n\nint main(void)\n{\n printf(\"main: %d\\\\n\", target_return());\n return 0;\n}\n" > /tmp/libtest/main.c && gcc -fPIC -shared /tmp/libtest/lib.c -o /tmp/libtest/liblib.so && gcc main.c -o /tmp/libtest/main.elf -L. -llib && LD_LIBRARY_PATH=/tmp/libtest/ /tmp/libtest/main.elfНа текущей Intel® HD Graphics 520 можно нормально играть в Saints Row IV. Ну, думаю, со Starbound под онтопик проблем не будет. А фиг там:
Доходит до главного меню, потом зависание и вылет.
intel_do_flush_locked failed: Input/output error
Нагуглил что предлагают выставить хардкорный запрет аппаратного ускорения. Понятно, что современная игруля, какой бы примитивной графикой не обладала чисто на проце будет нещадно лагать даже в главном меню.
А адекватные методы решения есть?
Каждый раз при подключении нового монитора мы не создаем новый screen (:0.1), а расширяем нулевой до размеров nx(m1+m2), все равно имея при этом ровно один скрин :0.0.
Так что, ScreenCount не имеет смысла? Всегда будет 1?
Или все-таки имеет смысл обрабатывать мультискрин кейсы на случай если кто-то все таки починит Xы, чтобы они третировали все мониторы как разные скрины для корректной обработки dpi?
When you have two monitors, X treats them as one display with (DISPLAY=:0.0) with a big resolution
Wayland ловеры лесом.
i32 xxxx(const void * p1, const void * p2)
{
const u8 * p1_u8 = p1;
const u8 * p2_u8 = p2;
if (p1_u8 == p2_u8)
return 0;
if (p1_u8 == NULL)
return *p2_u8; // 403
if (p2_u8 == NULL) // 404
return *p1_u8;
V595 The 'p2_u8' pointer was utilized before it was verified against nullptr. Check lines: 403, 404.
Короче эта хреновина не в состоянии элементарно попеременно подставить NULL/val во входных данных как это делает cppcheck/clang-tidy.
Такие дела.
2018й, ракеты летают на Марс, виртуальная реальность уходит в массы, умные дома, киборги и пр..
Тем временем можно ли в линуксе узнать сколько в данный момент потребляет каждый конкретный блок? Например, насколько я уменьшу энергопотребление если прямо сейчас выключу Wi-Fi или экран.
xU16.04, в консоли ничего нет при этом (пробовал запускать его оттуда). Может не туда смотрю? Виснет напрочь, может простоять час, потом зависнуть, может через пять минут.
Делаю в скрипте
# Скрипт запущен от рута\sudo. Надо дать пользователю его шелл
su $user -c /bin/shПолучаю шелл и в прибавку к нему: «/bin/sh: 0: can't access tty; job control turned off».
Если запустить что-то и сделать ^C, то все поломается нафиг:
/bin/sh: 0: can't access tty; job control turned off
$ ping ya.ru
PING ya.ru (87.250.250.242) 56(84) bytes of data.
64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=54 time=27.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=54 time=28.6 ms
^C
Сеанс завершён, выполняется завершение оболочки…
--- ya.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 27.149/27.897/28.646/0.766 ms
$ exit
… ожидает завершения потомка.
Так что не работает.
В инете такую штуку нашел только если ОСь не грузится или когда делают sh /dev/console. Тут просто sh. Как лечить?
Xubuntu 16.04
Почему функции
char *strpbrk(const char *s, const char *accept);
char *strstr(const char *haystack, const char *needle);
char *strcasestr(const char *haystack, const char *needle); // GNU
char *strchr(const char *s, int c);
char *strrchr(const char *s, int c);
Что теперь делать, куда бечь? Сбежал с adblock+ из-за того, что он не блочил vk-related рекламу, теперь все вернулось взад.
./code/test/utils/bximemutils.c
defines:
defined: BX_MEM_NONE: 0x000000
defined: BX_MEM_ZERO: 0x000001
functions:
checking: bxi_memopt_set
checking: bxi_memerr_set
checking: bxi_malloc_set
checking: bxi_malloc
checking: bxi_realloc_set
checking: bxi_realloc
checking: bxi_free_set
checking: bxi_free
checking: bxi_memset
speedtest: memset : 0.01649
speedtest: bxi_memset : 0.04130
checking: bxi_memcpy
speedtest: memcpy : 0.01038
speedtest: bxi_memcpy : 0.04120
checking: bxi_memmove
speedtest: memmove : 0.01202
speedtest: bxi_memmove : 0.04034
checking: bxi_memcmp
speedtest: memcmp : 1.63799
speedtest: bxi_memcmp : 0.58350
checking: bxi_memfrob
speedtest: memfrob : 0.07995
speedtest: bxi_memfrob : 0.08031
checking: bxi_memchr
checking: bxi_memrchr
PASSED
tk@pro7:/tmp/git/codemeow/bixi/bin
$ head -10 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
stepping : 9
microcode : 0x12
cpu MHz : 3300.000
cache size : 8192 KB
physical id : 0
tk@pro7:/tmp/git/codemeow/bixi/bin
$ uname -a
Linux pro7 3.8.5 #4 SMP Mon Oct 9 18:48:32 MSK 2017 i686 Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux
$ ls -l /lib/libc-2.11.1.so
-rwxr-xr-x 1 root root 1649149 2010-05-13 10:55 /lib/libc-2.11.1.so*
Реп: https://github.com/codemeow/bixi (сборка ./scripts/build.sh release, бинари будут в bin)
Как это можно объяснить?
Образ с офсайта, dfly-x86_64-5.0.1_REL.iso
Виртуалка из реп Ubuntu 16.04 - 5.0.40_Ubuntu r115130
Камень Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, виртуализация в бивисе включена (без нее вообще сразу после запуска виртуалки Guru Meditation
В простом режиме (Boot kernel) оно не грузится совсем, виснет на kbd0 at atkbd0.
Пытается грузиться дальше только если грузить в safe mode или без дров ACPI/AHCI.
Однако через пару секунд
Mounting devfs
DOUBLE FAULT
<..>
panic: lockmgr vm_maplk from 0: called from interrupt, ipi, or hard code sectionСкрин гугла по проблеме: https://s1.postimg.org/9frgq6pupb/2017-11-08_14-31-44.png
Чем лечить? Хочу ее потыкать.
Из-за -Werror он стопорит компиляцию. Прописал -Wno-error=unused-command-line-argument, но это не выход, так как все равно срет в stderr и внешняя система воспринимает это как ошибку. Обращу внимание, что это не на необработанный аргумент функции, а «лишний» по мнению кланга аргумент строки компиляции, конкретно тот, который задает место где надо искать библиотеки: -Lxxx. https://ibb.co/bYioHb . Вообще зачем нужно было это (предупреждение) делать, ни один другой компилятор не говорит о «лишних» параметрах.
На новых linux системах по умолчанию grep по умолчанию --color=auto
На новых маках grep по умолчанию --color=always
Ну ок, смирился, ставлю в скрипте принудительно --color=never, все работает.
Включаем старую систему:
grep: unknown option -- color=neverUPD
Разрулил через
grep-flag-available() {
echo | grep $1 "" >/dev/null 2>&1
}
GREP_OPTIONS=""
if grep-flag-available --color=auto; then
GREP_OPTIONS+=" --color=auto"
fi
Перемещено tailgunner из development
Как наиболее переносимым образом проверить, установлена ли нужная утилита?
Ну то есть:
Md5Calc()
{
# Minix : md5 -n $1
md5sum $1
}
P.S. Вопрос на засыпку, реально ли похожий fallback устроить в шебанге? /bin/bash vs /usr/pkg/bin/bash
MWE:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef unsigned char u8;
typedef unsigned int u32;
#define GB (1024ul * 1024ul * 1024ul)
#define TEST_SIZE (10)
int zerofy = 1;
static u8 * alloc(u32 size)
{
u8 * res = calloc(size, 1);
if (!res)
{
printf(" * Cannot alloc %u bytes\n", size);
return NULL;
}
else
{
printf(" * Allocated %u bytes [%p]\n", size, res);
}
if (zerofy)
memset(res, 0, size);
return res;
}
static void rapemem(u32 zero)
{
u32 i;
u8 * p[TEST_SIZE];
printf("Switching zerofy to %u\n", zero);
zerofy = zero;
for (i = 0; i < TEST_SIZE; i++)
p[i] = alloc(GB);
for (i = 0; i < TEST_SIZE; i++)
free(p[i]);
}
int main(void)
{
system("free -mh");
printf("\n\n");
rapemem(0);
rapemem(1);
rapemem(0);
return 0;
}
Выхлоп:
alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ gcc -std=c89 poc.c
alex@alex-thinkpad-l560:~/Разработка/C/Tests/calloc$ ./a.out
total used free shared buff/cache available
Память: 7,6G 2,1G 4,2G 396M 1,2G 4,8G
Подкачка: 0B 0B 0B
Switching zerofy to 0
* Allocated 1073741824 bytes [0x7fe248a9b010]
* Allocated 1073741824 bytes [0x7fe208a9a010]
* Allocated 1073741824 bytes [0x7fe1c8a99010]
* Allocated 1073741824 bytes [0x7fe188a98010]
* Allocated 1073741824 bytes [0x7fe148a97010]
* Allocated 1073741824 bytes [0x7fe108a96010]
* Allocated 1073741824 bytes [0x7fe0c8a95010]
* Allocated 1073741824 bytes [0x7fe088a94010]
* Allocated 1073741824 bytes [0x7fe048a93010]
* Allocated 1073741824 bytes [0x7fe008a92010]
Switching zerofy to 1
* Allocated 1073741824 bytes [0x7fe248a9b010]
* Allocated 1073741824 bytes [0x7fe208a9a010]
* Allocated 1073741824 bytes [0x7fe1c8a99010]
* Allocated 1073741824 bytes [0x7fe188a98010]
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
* Cannot alloc 1073741824 bytes
Switching zerofy to 0
* Allocated 1073741824 bytes [0x7fe248a9b010]
* Allocated 1073741824 bytes [0x7fe208a9a010]
* Allocated 1073741824 bytes [0x7fe1c8a99010]
* Allocated 1073741824 bytes [0x7fe188a98010]
* Allocated 1073741824 bytes [0x7fe143fff010]
* Allocated 1073741824 bytes [0x7fe103ffe010]
* Allocated 1073741824 bytes [0x7fe0c3ffd010]
* Allocated 1073741824 bytes [0x7fe083ffc010]
* Allocated 1073741824 bytes [0x7fe043ffb010]
* Allocated 1073741824 bytes [0x7fe003ffa010]
WTF вообще? Теперь и calloc выделению доверять нельзя? Да здравствуют SIGSEGV без вариантов проверить выделение?
Я знаю про оптимистичное выделение, но всю жизнь эта ботва была только с malloc, calloc от этой херни был свободен так как занулял память.
| ← назад | следующие → |