Сообщения firkax
neponyatnie 502/504 pri otpravke/edit commentov i tem v zavisimosti ot soderjaniya
WTF
Proboval otpravit' comment suda как к произвольному сайту добавить свой css ?
No on ne slalsya poka ne otrezal ot nego polovinu texta.
Redaktirovanie rabotaet idealno esli text to je samii +- probeli no pri popitke sdelat' polnii variant - 502 ili 504
UPD: вроде всё и правда исправилось как ниже написали
sudo опять опозорились
С помощью мутной уязвимости в не менее мутной «фиче» можно редактировать непредусмотренные (любые) файлы, а не только те что в белом списке.
https://www.sudo.ws/security/advisories/sudoedit_any/
Впрочем, кого это волнует, ведь sudo у всех настроено в режим «разрешать юзеру #1000 всё как руту».
Как описание бага, так и описание этого «sudoedit» намекают на совершеннейшую кашу в головах авторов сей утилиты.
В чём смысл именно тайлинговых WM?
Постоянно вижу про них упоминания. Насколько я понимаю, это WM, которые располагают окна только деля между ними площадь экрана, без пересечений. Так вот, вопрос: почему это выставляется за фичу вообще? Так располагать окна умеют абсолютно все WM, но тайлинговые умеют только так и никак иначе. Т.е. явно урезание функционала. Ладно, можно быть кому-то не нравятся пересекающиеся окна (хотя зачем фанатично их избегать всё равно непонятно), но ведь обычные WM не принуждают располагать окна не-тайлингово, т.е. они тоже тайлинговые, если юзер того захочет.
Ещё недавно видел тему о том, что какой-то тайлинговый WM научился располагать окна не впритык, а с зазорами. Странное ощущение, когда дефолтная уже 20-30 как лет фича всех WM преподносится как достижение.
Тема не троллинг, я в самом деле не понимаю.
cuda на 32 битах
Пытаюсь установить компилятор для cuda (nvidia-cuda-dev) в debian 11, он безальтернативно тянется из amd64 репы. Для i386 нет - это у дебиана так, или оно вообще никак? В чём проблема?
Solaris - «format» - «drive type unknown»
(система OmniOS)
Обычно при добавлении новых физических томов достаточно было сделать format - (номер) - label - y и он был доступен для использования. Сейчас в списке дисков для настройки вместо типа (где какие-то буквы, заканчивающиеся его размером) пишет «drive type unknown», когда я его выбираю - предлагает выбрать тип диска из этого списка:
Bad read of fdisk partition.
AVAILABLE DRIVE TYPES:
0. Auto configure
1. Quantum ProDrive 80S
2. Quantum ProDrive 105S
3. CDC Wren IV 94171-344
4. SUN0104
5. SUN0207
6. SUN0327
7. SUN0340
8. SUN0424
9. SUN0535
10. SUN0669
11. SUN1.0G
12. SUN1.05
13. SUN1.3G
14. SUN2.1G
15. SUN2.9G
16. Zip 100
17. Zip 250
18. Peerless 10GB
19. other
Если выбрать 0 (видимо это дефолт) то
Auto configure failed
No Solaris fdisk partition found.
и ничего не даёт делать
format> label
Current Disk Type is not set.
format> fdisk
Current Disk Type is not set.
Можно ввести type - тогда опять появляется список типов. Если выбрать 19 - спрашивает количество цилиндров и ещё какую-то чушь.
Specify disk type (enter its number): 19
Enter number of data cylinders:
Enter number of data cylinders:
Enter number of data cylinders: 1
Enter number of alternate cylinders[2]:
Enter number of physical cylinders[3]:
Enter number of heads: 1
Enter physical number of heads[default]: ^C
Если подозрение, что диски больше 2ТБ (все остальные, с которыми всё в порядке) дефолтятся на линейную геометрию и сами настраиваются нормально, а этот (2ТБ) оказался в CHS-режиме и хочет от меня CxHxS. Как ему сказать что он тоже линейный? Или что тут ещё можно сделать?
связать /dev/ttyUSBx и lsusb
Втыкаю модем в порт, он появляется в lsusb и появляются три штуки /dev/ttyUSB[0-2]. Как понять, что вот эти три устройства они именно от той записи в lsusb? Ну, я конечно вижу что оно всё по времени совпадает (втыкание, появление строчки в lsusb и появление устройств), но это похоже на угадывание, а мне хотелось бы чтоб именно где-то чётко было прописано, что вот /dev/ttyUSB0 обслуживается этим usb-устройством. Есть такое?
Ну а вообще это не только модемов касается, всякие флешки /dev/sr0 туда же.
Очистить состояние процесса без execve()
Допустим, у нас есть привилегированный процесс, и он хочет сделать что-то в контексте каких-то непривилегированных прав (и там и остаться). Для этого он переключает себе uid/gid или лезет в контейнер, не важно.
Тут нас подстерегает опасность: у привилегированного процесса в памяти могут находиться привилегированные данные (те, которые не положено знать обычным процессам), в том числе оставшиеся от когда-то давно free()-d блоков памяти (про explicit_bzero() и подобное тут не будем, это другая тема). Проблема в том, что как только процесс поставит себе права обычного юзера, этот самый обычный юзер может поймать его отладчиком и сдампить память.
Если у нас скрипт и переключаемся на юзера с помощью su, то такой проблемы не возникает: сначала скрипт (форкаясь) делает execve() в su, тот уже с чистой от важных данных памятью делает setuid() и прочее, и потом запускает полезную нагрузку непривилегированного юзера. Но неужели без execve() это никак не сделать? У него есть проблема: ему нужен бинарник в доступном на данный момент файловом пространстве, а если мы например в chroot-е, то там нашего бинарника уже может не быть, либо мы не можем полагаться на его подлинность. Как быть?
Лучше всего подошло бы что-то типа execve-сам-себя, но без указания на файл бинарника (через /proc/self/exe тоже нельзя, потому что в chroot-е его тоже может не быть). Если при этом ещё и можно было передать не только набор текстовых строк, а указать диапазон адресов памяти которые не надо чистить, и точку входа, отличную от main() - вообще прекрасно.
fs перемонтировалась в ro из-за ошибок, как сделать назад
Из-за подлагивающего ssd время от времени (иногда раз в месяц, иногда пару раз в неделю) файловая система не дожидается минутного таймаута и перемонтируется в read-only.
(я сейчас ещё подумал - а может где-то можно увеличть этот таймаут? но тема не об этом)
Допустим, fs у нас уже перемонтировалась, не важно почему. Я сделал ей fsck -f, оно восстановило из журнала (ну или даже если не из него), то есть она теперь в консистентном состоянии. Дальше можно убить все процессы, которые пользуются смонтированное ro-системой, размонтировать её и примонтировать назад как rw, ну либо просто ребутнуть ноут. Этот вариант 100% рабочий, но не всегда удобный. Хотелось бы как-то помягче, хотя бы на время ДО ребута получить к ней доступ на запись.
Понятное дело, перемонтировать ro в rw нельзя, ведь в ядре уже запомнено старое ей (до fsck) состояние и если оно начнёт писать поверх того что сделал fsck, будет плохо. Тут попробовал две идеи, обе провалились.
1) сделать umount -f и смонтировать назад. Нет, пишет umount: /home: target is busy., почему? Вроде как -f означает что надо всем кто ей пользуется сделать битые файловые дескрипторы и принудительно размонтировать, кто может помешать? Вложенных точек монтирования внутри /home нет.
2) примонтировать её второй раз в /mnt/home как rw. Тоже не даёт. Пишет что оно write-protected и поэтому монтирует в ro, даже если указать -o rw.
Что-то можно ещё сделать?
Кнопка «restart firefox» в окне краша
У кого-нить она работает? У меня без разницы что нажимать, он просто закрывается. И всегда было так, но сейчас я догадался создать об этом тему.
«Marking clocksource 'tsc' as unstable because the skew is too large» + отваливается USB
Не знаю это железо или нет (надеюсь нет), и связаны ли друг с другом эти два явления.
2 недели назад на загрузке где-то в начале ядра оно зависло (после ошибок с acpi таблицами но до остального, вроде, сейчас уже не выяснить), но отвисло, когда спустя несколько часов потрогали клавиатуру и дальше всё штатно загрузилось. Но, как выяснилось сейчас, это сопровождалось логом
Aug 30 00:52:18 host3 kernel: [ 4.472485] input: USB OPTICAL MOUSE as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.0/0003:18F8:0F97.0003/input/input6
Aug 30 00:52:18 host3 kernel: [ 4.472558] hid-generic 0003:18F8:0F97.0003: input,hidraw2: USB HID v1.10 Mouse [USB OPTICAL MOUSE ] on usb-0000:00:12.1-3/input0
Aug 30 00:52:18 host3 kernel: [ 4.478684] input: USB OPTICAL MOUSE Keyboard as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.1/0003:18F8:0F97.0004/input/input7
Aug 30 00:52:18 host3 kernel: [ 4.538052] input: USB OPTICAL MOUSE Consumer Control as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.1/0003:18F8:0F97.0004/input/input8
Aug 30 00:52:18 host3 kernel: [ 4.538174] hid-generic 0003:18F8:0F97.0004: input,hiddev0,hidraw3: USB HID v1.10 Keyboard [USB OPTICAL MOUSE ] on usb-0000:00:12.1-3/input1
Aug 30 00:52:18 host3 kernel: [ 5.023896] usb-storage 1-4:1.9: USB Mass Storage device detected
Aug 30 00:52:18 host3 kernel: [ 5.024109] scsi host8: usb-storage 1-4:1.9
Aug 30 00:52:18 host3 kernel: [ 5.024251] usbcore: registered new interface driver usb-storage
Aug 30 00:52:18 host3 kernel: [ 5.026346] usbcore: registered new interface driver uas
Aug 30 00:52:18 host3 kernel: [38262.363188] (t=218468 jiffies g=-655 q=138)
Aug 30 00:52:18 host3 kernel: [38262.363736] task:rcu_sched state:I stack: 0 pid: 12 ppid: 2 flags:0x00004000
Aug 30 00:52:18 host3 kernel: [38262.363740] Call Trace:
Aug 30 00:52:18 host3 kernel: [38262.363747] __schedule+0x24c/0x8f0
Aug 30 00:52:18 host3 kernel: [38262.363751] ? __mod_timer+0x20f/0x3c0
Aug 30 00:52:18 host3 kernel: [38262.363753] schedule+0x42/0xb0
Aug 30 00:52:18 host3 kernel: [38262.363755] schedule_timeout+0x6f/0x110
Aug 30 00:52:18 host3 kernel: [38262.363757] ? __next_timer_interrupt+0xe0/0xe0
Aug 30 00:52:18 host3 kernel: [38262.363759] rcu_gp_kthread+0x451/0xa70
Aug 30 00:52:18 host3 kernel: [38262.363762] kthread+0xf6/0x110
Aug 30 00:52:18 host3 kernel: [38262.363763] ? call_rcu+0x210/0x210
Aug 30 00:52:18 host3 kernel: [38262.363765] ? kthread_associate_blkcg+0xb0/0xb0
Aug 30 00:52:18 host3 kernel: [38262.363768] ret_from_fork+0x1c/0x28
Aug 30 00:52:18 host3 kernel: [38262.363779] Sending NMI from CPU 2 to CPUs 1:
Aug 30 00:52:18 host3 kernel: [38262.364775] NMI backtrace for cpu 1
Aug 30 00:52:18 host3 kernel: [38262.364776] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.10.0-14-686-pae #1 Debian 5.10.113-1
Aug 30 00:52:18 host3 kernel: [38262.364777] Hardware name: Gigabyte Technology Co., Ltd. GA-MA785GT-UD3H/GA-MA785GT-UD3H, BIOS F1 07/03/2009
Aug 30 00:52:18 host3 kernel: [38262.364778] EIP: timekeeping_advance+0x221/0x8e0
Aug 30 00:52:18 host3 kernel: [38262.364779] Code: f4 ce d9 b8 00 ca 9a 3b 11 15 44 f4 ce d9 0f a5 f7 31 db d3 e6 f6 c1 20 8b 0d 18 f4 ce d9 0f 45 fe 0f 45 f3 03 35 1c f4 ce d9 <13> 3d 20 f4 ce d9 31 d2 31 db 89 35 1c f4 ce d9 0f a5 c2 d3 e0 f6
Aug 30 00:52:18 host3 kernel: [38262.364779] EAX: 3b9aca00 EBX: 00000000 ECX: 00000018 EDX: 00000001
Aug 30 00:52:18 host3 kernel: [38262.364780] ESI: 31373eb0 EDI: 007a11ff EBP: c115ddbc ESP: c115dd54
Aug 30 00:52:18 host3 kernel: [38262.364780] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200003
Aug 30 00:52:18 host3 kernel: [38262.364781] CR0: 80050033 CR2: 024fdf44 CR3: 01302f20 CR4: 000006f0
Aug 30 00:52:18 host3 kernel: [38262.364781] Call Trace:
Aug 30 00:52:18 host3 kernel: [38262.364781] ? trigger_load_balance+0x31/0x220
Aug 30 00:52:18 host3 kernel: [38262.364782] ? calc_global_load+0x17a/0x1c0
Aug 30 00:52:18 host3 kernel: [38262.364782] update_wall_time+0xf/0x20
Aug 30 00:52:18 host3 kernel: [38262.364783] tick_do_update_jiffies64.part.0+0xb8/0x120
Aug 30 00:52:18 host3 kernel: [38262.364783] tick_sched_timer+0xe6/0xf0
Aug 30 00:52:18 host3 kernel: [38262.364783] __hrtimer_run_queues+0x13a/0x260
Aug 30 00:52:18 host3 kernel: [38262.364784] ? tick_do_update_jiffies64.part.0+0x120/0x120
Aug 30 00:52:18 host3 kernel: [38262.364784] hrtimer_interrupt+0x113/0x2e0
Aug 30 00:52:18 host3 kernel: [38262.364785] ? tick_irq_enter+0xda/0x100
Aug 30 00:52:18 host3 kernel: [38262.364785] ? sysvec_call_function_single+0x40/0x40
Aug 30 00:52:18 host3 kernel: [38262.364785] __sysvec_apic_timer_interrupt+0x55/0xd0
Aug 30 00:52:18 host3 kernel: [38262.364786] sysvec_apic_timer_interrupt+0x22/0x40
Aug 30 00:52:18 host3 kernel: [38262.364786] handle_exception+0x140/0x140
Aug 30 00:52:18 host3 kernel: [38262.364787] EIP: acpi_idle_do_entry+0x5e/0x60
Aug 30 00:52:18 host3 kernel: [38262.364788] Code: c9 d9 8b 00 a8 08 74 14 c3 8d 76 00 55 89 e5 e8 58 fd ff ff 5d c3 8d b6 00 00 00 00 e9 07 00 00 00 0f 00 2d 9a a7 89 d9 fb f4 <fa> c3 0f 1f 44 00 00 55 89 e5 57 89 d7 56 53 89 c3 83 ec 10 89 4d
Aug 30 00:52:18 host3 kernel: [38262.364788] EAX: 00004000 EBX: 00000001 ECX: 00000001 EDX: 00000002
Aug 30 00:52:18 host3 kernel: [38262.364789] ESI: c1335000 EDI: d9b64840 EBP: c115df14 ESP: c115df00
Aug 30 00:52:18 host3 kernel: [38262.364789] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200246
Aug 30 00:52:18 host3 kernel: [38262.364790] ? sysvec_call_function_single+0x40/0x40
Aug 30 00:52:18 host3 kernel: [38262.364790] ? acpi_idle_do_entry+0x5e/0x60
Aug 30 00:52:18 host3 kernel: [38262.364790] ? acpi_idle_enter+0x81/0xd0
Aug 30 00:52:18 host3 kernel: [38262.364791] ? acpi_idle_enter_s2idle+0x70/0x70
Aug 30 00:52:18 host3 kernel: [38262.364791] cpuidle_enter_state+0x70/0x3b0
Aug 30 00:52:18 host3 kernel: [38262.364792] cpuidle_enter+0x27/0x40
Aug 30 00:52:18 host3 kernel: [38262.364792] do_idle+0x1d1/0x280
Aug 30 00:52:18 host3 kernel: [38262.364792] ? complete+0x35/0x40
Aug 30 00:52:18 host3 kernel: [38262.364793] cpu_startup_entry+0x25/0x30
Aug 30 00:52:18 host3 kernel: [38262.364793] start_secondary+0xfa/0x130
Aug 30 00:52:18 host3 kernel: [38262.364793] startup_32_smp+0x164/0x168
Aug 30 00:52:18 host3 kernel: [38262.364795] NMI backtrace for cpu 2
Aug 30 00:52:18 host3 kernel: [38262.364802] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.0-14-686-pae #1 Debian 5.10.113-1
Aug 30 00:52:18 host3 kernel: [38262.364803] Hardware name: Gigabyte Technology Co., Ltd. GA-MA785GT-UD3H/GA-MA785GT-UD3H, BIOS F1 07/03/2009
Aug 30 00:52:18 host3 kernel: [38262.364804] Call Trace:
Aug 30 00:52:18 host3 kernel: [38262.364808] dump_stack+0x54/0x68
Aug 30 00:52:18 host3 kernel: [38262.364809] nmi_cpu_backtrace.cold+0x16/0x5b
Aug 30 00:52:18 host3 kernel: [38262.364812] ? lapic_can_unplug_cpu+0x70/0x70
Aug 30 00:52:18 host3 kernel: [38262.364815] nmi_trigger_cpumask_backtrace+0x8f/0xb0
Aug 30 00:52:18 host3 kernel: [38262.364817] arch_trigger_cpumask_backtrace+0x15/0x20
Aug 30 00:52:18 host3 kernel: [38262.364819] rcu_dump_cpu_stacks+0x80/0xa9
Aug 30 00:52:18 host3 kernel: [38262.364821] rcu_sched_clock_irq.cold+0x1a4/0x35b
Aug 30 00:52:18 host3 kernel: [38262.364824] update_process_times+0x77/0xb0
Aug 30 00:52:18 host3 kernel: [38262.364827] tick_sched_handle+0x28/0x70
Aug 30 00:52:18 host3 kernel: [38262.364828] tick_sched_timer+0x9b/0xf0
Aug 30 00:52:18 host3 kernel: [38262.364830] __hrtimer_run_queues+0x13a/0x260
Aug 30 00:52:18 host3 kernel: [38262.364832] ? tick_do_update_jiffies64.part.0+0x120/0x120
Aug 30 00:52:18 host3 kernel: [38262.364834] hrtimer_interrupt+0x113/0x2e0
Aug 30 00:52:18 host3 kernel: [38262.364836] ? tick_irq_enter+0xda/0x100
Aug 30 00:52:18 host3 kernel: [38262.364839] ? sysvec_call_function_single+0x40/0x40
Aug 30 00:52:18 host3 kernel: [38262.364840] __sysvec_apic_timer_interrupt+0x55/0xd0
Aug 30 00:52:18 host3 kernel: [38262.364842] sysvec_apic_timer_interrupt+0x22/0x40
Aug 30 00:52:18 host3 kernel: [38262.364845] handle_exception+0x140/0x140
Aug 30 00:52:18 host3 kernel: [38262.364848] EIP: cpuidle_enter_state+0xb9/0x3b0
Aug 30 00:52:18 host3 kernel: [38262.364850] Code: 89 55 d4 0f 1f 44 00 00 31 c0 e8 72 5d a9 ff 80 7d e0 00 74 12 9c 58 f6 c4 02 0f 85 d1 02 00 00 31 c0 e8 ca 98 af ff fb 85 f6 <0f> 88 f9 00 00 00 6b c6 5c 8b 7d e8 89 f1 8d 7c 07 30 8b 47 0c 8b
Aug 30 00:52:18 host3 kernel: [38262.364852] EAX: 00000000 EBX: c117a400 ECX: 00000000 EDX: 00000001
Aug 30 00:52:18 host3 kernel: [38262.364853] ESI: 00000001 EDI: d9b648a8 EBP: c115ff54 ESP: c115ff1c
Aug 30 00:52:18 host3 kernel: [38262.364854] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200202
Aug 30 00:52:18 host3 kernel: [38262.364857] ? sysvec_call_function_single+0x40/0x40
Aug 30 00:52:18 host3 kernel: [38262.364859] ? cpuidle_enter_state+0xb9/0x3b0
Aug 30 00:52:18 host3 kernel: [38262.364861] cpuidle_enter+0x27/0x40
Aug 30 00:52:18 host3 kernel: [38262.364863] do_idle+0x1d1/0x280
Aug 30 00:52:18 host3 kernel: [38262.364865] ? complete+0x35/0x40
Aug 30 00:52:18 host3 kernel: [38262.364867] cpu_startup_entry+0x25/0x30
Aug 30 00:52:18 host3 kernel: [38262.364869] start_secondary+0xfa/0x130
Aug 30 00:52:18 host3 kernel: [38262.364870] startup_32_smp+0x164/0x168
Aug 30 00:52:18 host3 kernel: [38262.364873] Sending NMI from CPU 2 to CPUs 3:
Aug 30 00:52:18 host3 kernel: [38262.364896] NMI backtrace for cpu 3 skipped: idling at acpi_idle_do_entry+0x5e/0x60
Aug 30 00:52:18 host3 kernel: [38262.366015] (t=9564317 jiffies g=-655 q=138)
Aug 30 00:52:18 host3 kernel: [38262.366016] NMI backtrace for cpu 1
Aug 30 00:52:18 host3 kernel: [38262.366019] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.10.0-14-686-pae #1 Debian 5.10.113-1
Aug 30 00:52:18 host3 kernel: [38262.366020] Hardware name: Gigabyte Technology Co., Ltd. GA-MA785GT-UD3H/GA-MA785GT-UD3H, BIOS F1 07/03/2009
Aug 30 00:52:18 host3 kernel: [38262.366021] Call Trace:
Aug 30 00:52:18 host3 kernel: [38262.366024] dump_stack+0x54/0x68
Aug 30 00:52:18 host3 kernel: [38262.366026] nmi_cpu_backtrace.cold+0x16/0x5b
Aug 30 00:52:18 host3 kernel: [38262.366029] ? lapic_can_unplug_cpu+0x70/0x70
Aug 30 00:52:18 host3 kernel: [38262.366032] nmi_trigger_cpumask_backtrace+0x8f/0xb0
Aug 30 00:52:18 host3 kernel: [38262.366034] arch_trigger_cpumask_backtrace+0x15/0x20
Aug 30 00:52:18 host3 kernel: [38262.366037] rcu_dump_cpu_stacks+0x80/0xa9
Aug 30 00:52:18 host3 kernel: [38262.366039] rcu_sched_clock_irq.cold+0x1a4/0x35b
Aug 30 00:52:18 host3 kernel: [38262.366040] ? calc_global_load+0x17a/0x1c0
Aug 30 00:52:18 host3 kernel: [38262.366043] update_process_times+0x77/0xb0
Aug 30 00:52:18 host3 kernel: [38262.366046] tick_sched_handle+0x28/0x70
Aug 30 00:52:18 host3 kernel: [38262.366047] tick_sched_timer+0x9b/0xf0
Aug 30 00:52:18 host3 kernel: [38262.366049] __hrtimer_run_queues+0x13a/0x260
Aug 30 00:52:18 host3 kernel: [38262.366051] ? tick_do_update_jiffies64.part.0+0x120/0x120
Aug 30 00:52:18 host3 kernel: [38262.366053] hrtimer_interrupt+0x113/0x2e0
Aug 30 00:52:18 host3 kernel: [38262.366055] ? tick_irq_enter+0xda/0x100
Aug 30 00:52:18 host3 kernel: [38262.366056] ? sysvec_call_function_single+0x40/0x40
Aug 30 00:52:18 host3 kernel: [38262.366058] __sysvec_apic_timer_interrupt+0x55/0xd0
Aug 30 00:52:18 host3 kernel: [38262.366059] sysvec_apic_timer_interrupt+0x22/0x40
Aug 30 00:52:18 host3 kernel: [38262.366061] handle_exception+0x140/0x140
Aug 30 00:52:18 host3 kernel: [38262.366062] EIP: acpi_idle_do_entry+0x5e/0x60
Aug 30 00:52:18 host3 kernel: [38262.366064] Code: c9 d9 8b 00 a8 08 74 14 c3 8d 76 00 55 89 e5 e8 58 fd ff ff 5d c3 8d b6 00 00 00 00 e9 07 00 00 00 0f 00 2d 9a a7 89 d9 fb f4 <fa> c3 0f 1f 44 00 00 55 89 e5 57 89 d7 56 53 89 c3 83 ec 10 89 4d
Aug 30 00:52:18 host3 kernel: [38262.366065] EAX: 00004000 EBX: 00000001 ECX: 00000001 EDX: 00000002
Aug 30 00:52:18 host3 kernel: [38262.366066] ESI: c1335000 EDI: d9b64840 EBP: c115df14 ESP: c115df00
Aug 30 00:52:18 host3 kernel: [38262.366067] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200246
Aug 30 00:52:18 host3 kernel: [38262.366070] ? sysvec_call_function_single+0x40/0x40
Aug 30 00:52:18 host3 kernel: [38262.366071] ? acpi_idle_do_entry+0x5e/0x60
Aug 30 00:52:18 host3 kernel: [38262.366072] ? acpi_idle_enter+0x81/0xd0
Aug 30 00:52:18 host3 kernel: [38262.366074] ? acpi_idle_enter_s2idle+0x70/0x70
Aug 30 00:52:18 host3 kernel: [38262.366075] cpuidle_enter_state+0x70/0x3b0
Aug 30 00:52:18 host3 kernel: [38262.366077] cpuidle_enter+0x27/0x40
Aug 30 00:52:18 host3 kernel: [38262.366079] do_idle+0x1d1/0x280
Aug 30 00:52:18 host3 kernel: [38262.366080] ? complete+0x35/0x40
Aug 30 00:52:18 host3 kernel: [38262.366085] cpu_startup_entry+0x25/0x30
Aug 30 00:52:18 host3 kernel: [38262.366094] start_secondary+0xfa/0x130
Aug 30 00:52:18 host3 kernel: [38262.366096] startup_32_smp+0x164/0x168
Aug 30 00:52:18 host3 kernel: [38262.366100] Sending NMI from CPU 1 to CPUs 2:
Aug 30 00:52:18 host3 kernel: [38262.366153] NMI backtrace for cpu 2
Aug 30 00:52:18 host3 kernel: [38262.366154] CPU: 2 PID: 148 Comm: kworker/u8:5 Not tainted 5.10.0-14-686-pae #1 Debian 5.10.113-1
Aug 30 00:52:18 host3 kernel: [38262.366155] Hardware name: Gigabyte Technology Co., Ltd. GA-MA785GT-UD3H/GA-MA785GT-UD3H, BIOS F1 07/03/2009
Aug 30 00:52:18 host3 kernel: [38262.366155] Workqueue: events_unbound flush_to_ldisc
Aug 30 00:52:18 host3 kernel: [38262.366156] EIP: vgacon_cursor+0x75/0x210
Aug 30 00:52:18 host3 kernel: [38262.366157] Code: 01 00 00 b8 58 50 d1 d9 2b 1d 5c 1e bb d9 e8 52 9a 35 00 d1 eb 0f b7 15 52 1e bb d9 89 c1 89 d8 25 00 ff 00 00 83 c0 0e 66 ef <c1> e3 08 0f b7 c3 83 c0 0f 66 ef b8 58 50 d1 d9 89 ca e8 44 98 35
Aug 30 00:52:18 host3 kernel: [38262.366158] EAX: 00001e0e EBX: 00001e01 ECX: 00000202 EDX: 000003d4
Aug 30 00:52:18 host3 kernel: [38262.366159] ESI: 00000002 EDI: c1010c00 EBP: f65a5d98 ESP: f65a5d90
Aug 30 00:52:18 host3 kernel: [38262.366159] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00000002
Aug 30 00:52:18 host3 kernel: [38262.366160] CR0: 80050033 CR2: 004a43f0 CR3: 19cb2000 CR4: 000006f0
Aug 30 00:52:18 host3 kernel: [38262.366160] Call Trace:
Aug 30 00:52:18 host3 kernel: [38262.366160] hide_cursor+0x2e/0xd0
Aug 30 00:52:18 host3 kernel: [38262.366161] do_con_write+0xbd7/0x21f0
Aug 30 00:52:18 host3 kernel: [38262.366161] ? update_load_avg+0x99/0x680
Aug 30 00:52:18 host3 kernel: [38262.366161] ? cpuacct_charge+0x5d/0x80
Aug 30 00:52:18 host3 kernel: [38262.366162] con_put_char+0x35/0x40
Aug 30 00:52:18 host3 kernel: [38262.366162] tty_put_char+0x22/0x50
Aug 30 00:52:18 host3 kernel: [38262.366163] __process_echoes+0x1cd/0x2d0
Aug 30 00:52:18 host3 kernel: [38262.366163] n_tty_receive_buf_common+0x2b5/0xbb0
Aug 30 00:52:18 host3 kernel: [38262.366163] ? n_tty_receive_buf_common+0xbb0/0xbb0
Aug 30 00:52:18 host3 kernel: [38262.366164] n_tty_receive_buf2+0x12/0x20
Aug 30 00:52:18 host3 kernel: [38262.366164] tty_ldisc_receive_buf+0x20/0x60
Aug 30 00:52:18 host3 kernel: [38262.366165] tty_port_default_receive_buf+0x2d/0x60
Aug 30 00:52:18 host3 kernel: [38262.366165] ? tty_port_lower_dtr_rts+0x30/0x30
Aug 30 00:52:18 host3 kernel: [38262.366166] flush_to_ldisc+0x80/0xe0
Aug 30 00:52:18 host3 kernel: [38262.366166] process_one_work+0x16c/0x2e0
Aug 30 00:52:18 host3 kernel: [38262.366166] worker_thread+0x15e/0x3e0
Aug 30 00:52:18 host3 kernel: [38262.366167] kthread+0xf6/0x110
Aug 30 00:52:18 host3 kernel: [38262.366167] ? process_one_work+0x2e0/0x2e0
Aug 30 00:52:18 host3 kernel: [38262.366167] ? kthread_associate_blkcg+0xb0/0xb0
Aug 30 00:52:18 host3 kernel: [38262.366168] ret_from_fork+0x1c/0x28
Aug 30 00:52:18 host3 kernel: [38262.367104] clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc' as unstable because the skew is too large:
Aug 30 00:52:18 host3 kernel: [38262.367106] clocksource: 'acpi_pm' wd_now: 342501 wd_last: b99d05 mask: ffffff
Aug 30 00:52:18 host3 kernel: [38262.367108] clocksource: 'tsc' cs_now: 5af33c465e5a cs_last: 12b2286e96 mask: ffffffffffffffff
Aug 30 00:52:18 host3 kernel: [38262.367113] tsc: Marking TSC unstable due to clocksource watchdog
Aug 30 00:52:18 host3 kernel: [38262.367145] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
Aug 30 00:52:18 host3 kernel: [38262.367147] sched_clock: Marking unstable (38262367152341, 2597801)<-(38262371269052, -4124527)
Aug 30 00:52:18 host3 kernel: [38262.369895] clocksource: Checking clocksource tsc synchronization from CPU 1.
Aug 30 00:52:18 host3 kernel: [38262.369918] clocksource: Switched to clocksource acpi_pm
(38262 это аптайм на момент трогания клавиатуры и отвисания)
Спустя неделю после этого события я делал apt-get upgrade в т.ч. ядро (минорное обновление 5.10.113-1, 5.10.136-1) и nvidia (390.144-1, 390.151-1~deb11u1) и ребутнулся. Всё шло хорошо, но, попытавшись спустя несколько часов что-то сделать, обнаружил неработающую клаву и мышь (usb). Заработали после перетыкания их в другие порты (были сзади в углу, вставил спереди). Лог:
Sep 7 20:05:29 host3 kernel: [11467.219586] usb 4-2: USB disconnect, device number 2
Sep 7 20:05:29 host3 kernel: [11467.332516] usb 4-3: USB disconnect, device number 3
Sep 7 20:56:16 host3 kernel: [14515.097518] clocksource: timekeeping watchdog on CPU2: Marking clocksource 'tsc' as unstable because the skew is too large:
Sep 7 20:56:16 host3 kernel: [14515.097528] clocksource: 'acpi_pm' wd_now: cff65d wd_last: 4e1a7b mask: ffffff
Sep 7 20:56:16 host3 kernel: [14515.097533] clocksource: 'tsc' cs_now: 2289322f3b57 cs_last: 2287c0102a89 mask: ffffffffffffffff
Sep 7 20:56:16 host3 kernel: [14515.097541] tsc: Marking TSC unstable due to clocksource watchdog
Sep 7 20:56:16 host3 kernel: [14515.097783] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
Sep 7 20:56:16 host3 kernel: [14515.097791] sched_clock: Marking unstable (14513940105420, 1157667751)<-(14515103369980, -5596777)
Sep 7 20:56:16 host3 kernel: [14515.098441] clocksource: Checking clocksource tsc synchronization from CPU 0.
Sep 7 20:56:16 host3 kernel: [14515.098508] clocksource: Switched to clocksource acpi_pm
Видно как сначала отключились оба устройства, ещё спустя час опять проблема с tsc, но на этот раз без бектрейсов. Обычные порты куда обычно воткнута клава и мышь заработали только после ребута (обычный ребут).
Вчера опять повторилось то же самое
Sep 11 11:19:42 host3 kernel: [298523.000776] clocksource: timekeeping watchdog on CPU2: Marking clocksource 'tsc' as unstable because the skew is too large:
Sep 11 11:19:42 host3 kernel: [298523.000786] clocksource: 'acpi_pm' wd_now: 6e700f wd_last: a59b86 mask: ffffff
Sep 11 11:19:42 host3 kernel: [298523.000792] clocksource: 'tsc' cs_now: 2c52d25ee03cd cs_last: 2c5280fe18ab6 mask: ffffffffffffffff
Sep 11 11:19:42 host3 kernel: [298523.000798] tsc: Marking TSC unstable due to clocksource watchdog
Sep 11 11:19:42 host3 kernel: [298523.001442] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
Sep 11 11:19:42 host3 kernel: [298523.001450] sched_clock: Marking unstable (298499404691887, 23596747125)<-(298523005747237, -4308888)
Sep 11 11:19:42 host3 kernel: [298523.002897] clocksource: Checking clocksource tsc synchronization from CPU 2.
Sep 11 11:19:42 host3 kernel: [298523.002966] clocksource: Switched to clocksource acpi_pm
Sep 15 00:45:54 host3 kernel: [606095.576433] nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device VGA-0
Sep 15 03:12:29 host3 kernel: [614890.025127] usb 4-2: USB disconnect, device number 2
Sep 15 03:12:29 host3 kernel: [614890.293731] usb 4-3: USB disconnect, device number 3
Опять tsc и опять usb. Ребутаться не стал, те два порта сзади так до сих пор не работают и ещё один задний не работают, работают два спереди и три других сзади (хотя питание есть и на неработающих):
lsusb для работающих спереди
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device XXX: ID 1c4f:0026 SiGma Micro Keyboard
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
lsusb для работающих сзади
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device XXX: ID 1c4f:0026 SiGma Micro Keyboard
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Попробую запуститься со старым ядром попозже но вдруг можно что-то сейчас выяснить.
Команда Devuan просрочила основной ключ подписи репозиториев
Ключ, которым подписываются все системные обновления, выпущенный в 2017 году, был действителен до 2 сентября 2022 года. Сегодня пользователи дистрибутива столкнулись с невозможностью штатного обновления системы через apt в связи с отсутствием действительного ключа. Разработчики дистрибутива, судя по всему, узнали о просрочке из жалобы на форуме и сгенерировали новый пакет devuan-keyring, который предлагают скачать через http (поскольку apt неработоспособен) и без каких-либо проверок сразу установить.
wget http://deb.devuan.org/devuan/pool/main/d/devuan-keyring/devuan-keyring_2022.09.04_all.deb
dpkg -i devuan-keyring_2022.09.04_all.deb
sha256sum devuan-keyring_2022.09.04_all.deb
dpkg -i.Старый ключ:
/etc/apt/trusted.gpg.d/devuan-keyring-2017-archive.gpg
------------------------------------------------------
pub rsa4096 2017-09-04 [SC] [просрочен с: 2022-09-03]
E032 601B 7CA1 0BC3 EA53 FA81 BB23 C00C 61FC 752C
uid [ просрочен ] Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>
/etc/apt/trusted.gpg.d/devuan-keyring-2022-archive.gpg
------------------------------------------------------
pub rsa4096 2017-09-04 [SC] [ годен до: 2023-09-03]
E032 601B 7CA1 0BC3 EA53 FA81 BB23 C00C 61FC 752C
uid [ неизвестно ] Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>
sub rsa4096 2017-09-04 [E] [ годен до: 2023-09-03]
Несмотря на то, что, по-видимому, новый ключ легитимен, стоит отметить, что цепочка безопасного доверия ключей прервана, и пользователи вынуждены, при обновлении пакета, полагаться на https-сертификат сайта с информацией о пакетах, который может выпустить (поддельный) любая из огромного количества организаций, в том числе сомнительных, в доверенном списке браузера.
>>> Подробности
немонотонные таймстампы коммитов в свн
Свн позволяет редактировать timestamp в свойствах ревизии (так же как и остальные метаданные). Если я поставлю таймстампы немонотонными, какие это может вызвать проблемы в работе штатных утилит?
Ну то есть, например, есть репозиторий, в нём уже коммиты за 2022 год есть, и я хочу туда импортировать (с датами коммитов) что-то ещё старое откуда-то из другого места (имеется ввиду не заменить этим имеющиеся файлы а положить рядом - это другой код, просто я хочу его хранить в том же репозитории), с датами коммитов например 2010 год. При этом номера ревизий этих импортированных коммитов, разумеется, будут идти после уже существующих за 2022. Ничего не сломается от такого фокуса?
Перемещено hobbit из general
Планируется выход FreeBSD 12.4
Зашёл на freebsd.org и к своему удивлению обнаружил 12.4 в списке планируемых. Что очень радует, т.к. означает продление официальной поддержки 12.х ветки и дальнейшую возможность малыми силами избегать глючную 13.х. Но с чего это они вдруг, кто знает? Планировали же 12.3 последней.
быстрая инкрементальная сборка ядра FreeBSD
Там есть опция KERNFAST=1 чтобы не пересобирать всё, но он всё равно лазит по исходникам всех модулей в поисках изменённых файлов, хоть ничего и не компилируя в них, но всё равно долго (целых 3 минуты вместо 15 секунд), при том что перекомпилировать надо только один файл в kern/. Можно ли это штатно и просто исправить? Аналогично в installkernel - он заново ставит все неизменившиеся модули.
Найти race condition
Только что случившийся со мной случай.
Есть некий объект, упрощённое описание:
typedef struct {
int status;
int status2;
void *data;
rwlock lock1;
rwlock lock2;
}
(1) status==0, status2==0, data==NULL
(2) status==0, status2==0, data!=NULL
(3) status!=0, status2==0, data==NULL
(4) status!=0, status2 [1..3], data==NULL
(5) status==0, status2==4, data!=NULL
Переходы между состояниями такие:
1->2, 1->3, 1->4, 4->5 делаются под write-lock1'ом
5->2 без write-lock1'а
внутри состояния 4 может меняться status2 - без write-lock1'а
status2 меняется между 0 и 4, а так же между 1-2-3 без write-lock1'а, потому что от этих изменений не зависит поведение остальных частей кода (интересующихся status'ом и data), а ещё у status2 есть lock2, который защищает от race между разными его переключалками (то есть именно тем кодом, чья логика завязана именно на него), тут он для упрощения не показан.
И есть ещё один тред, который эти поля иногда читает (использует) и заодно проверяет на корректность структуру (люблю рассовывать ассерты по всем подходящим местам, если оно не критично по времени). В частности, там есть такой код:
READ_LOCK(obj->lock1);
if(obj->status!=0) {
.....
} else {
assert(!obj->status2 || obj->status2==4 && obj->data);
...
}
READ_UNLOCK(obj->lock1);
Так вот, этот ассерт иногда падал. Кто угадает в чём причина?
Для справки: rwlock это примерно то же самое, что мютекс, но у него два вида блокировок, строгая - на запись, ей может владеть только один тред, и нестрогая - на чтение, ей может владеть одновременно сколько угодно тредов, при условии что никто не заблокировал на запись.
Ещё одна занимательная задача по теорверу
По мотивам Не могу ответить в теме, про вопрос из тервер Занимательная задачка по ТВ
Задача по биологическому теорверу уже была (выше ссылки), давайте теперь по физическому.
Достаём из кармана монетку, полученную на сдачу во время последнего похода в магазин, и проводим над ней серию из 100 опытов: подбрасываем и смотрим какой стороной она упала. Если падает не плоской стороной - итерация считается недействительной и повторяется. Так вот, известно, что из 100 раз как минимум 99 раз она упала орлом вверх. Вопрос: какова вероятность, что она упала орлом все 100 раз из 100?
Добавлено 5 августа 13:25: поскольку некоторые придираются, уточняю: всё, что написано перед вопросительным предложением - условие к нему. Вероятность надо найти именно при условии выполнения всего того, что написано до вопроса.
Добавлено 5 августа 13:22: сегодня вечером наверно напишу свой вариант решения (с обоснованием почему именно он верный) и разбор ошибок всех неправильных решений. Пока что в подробностях никто правильное решение не написал, хотя правильные мысли были и не раз, но не оформленные в решение.
Добавлено 6 августа 13:08: мои ответы тут Ещё одна занимательная задача по теорверу (комментарий) Ещё одна занимательная задача по теорверу (комментарий)
Улучшение вида синей темы
div.msg_body {
font-weight: bold !important;
}
предлагаю сделать официально
ipfw fwd loopback + tcpdump
Всё происходит без участия внешних сетевых интерфейсов.
Есть правило ipfw fwd, перенаправляющее исходящий трафик на определённый адрес на локальный слушающий порт. Как его теперь увидеть в tcpdump? Ни на lo0, ни на одном из ethernet-интерфейсов, ни на созданном ipfw0 его не видно.
Условно (убрал ненужные подробности), есть правило
ipfw fwd 192.168.1.10,1005 tcp from 192.168.1.10 to 192.168.1.10 1005
tcpdump -i lo0 -n port 1005
telnet 192.168.1.10 1005
Совместимость zlib и gpl лицензий
https://directory.fsf.org/wiki/License:Zlib
Конкретно интересует пункт 2. Вроде бы в лицензии GPL такого требования нет, а значит zlib налагает дополнительный запрет и не может быть в составе gpl-продукта. С другой стороны, авторитетный источник ( https://www.gnu.org/licenses/license-list.html#ZLib ) говорит что совместима. Я где-то ошибаюсь?
| ← назад | следующие → |
