LINUX.ORG.RU

Сообщения carasin

 

Кто там желал Opera под x86 (32 бита)?

by Ruarí Ødegaard / April 15, 2015

Today we provide a 32-bit Linux version of our previous developer release. Sadly, there is no Linux 64-bit version this time around—some changes we originally made to accommodate the 32-bit version on our build systems, actually broke the 64-bit version. ;) We have already fixed the issue internally, so the next release should have both 32-bit and 64-bit versions for Linux.

Ссылка #1:
http://blogs.opera.com/desktop/2015/04/opera-developer-30-now-available-32-bi...

Ссылка #2:
ftp://ftp.opera.com/pub/opera-developer/30.0.1833.0/linux/

// Ушёл править спек.

 ,

carasin ()

Wine 1.7.37 + Staging + Gallium Nine

Времени суток!

Народ, есть у кого идеи, ссылки, готовые патч-сеты, чтобы объединить патчи Staging (Compholio) и Gallium Nine?

До Wine версии 1.7.36 включительно патч-сет Staging и патч для поддержки Gallium Nine не пересекались. С версии 1.7.37 эти две сущности стали не [полностью] совместимы. Если после применения патч-сета Staging накладывать патч от iXit, то вылазят ошибки утилиты patch. Если поверх Staging накладывать патч Gallium Nine отсюда, то patch выдаёт несколько успешных hunk'ов, но после сборки (несмотря на наличие «галки» 'Prefer native Direct3D 9' в winecfg) Wine всё равно использует CSMT или стандартный Wine'овский стек D3D (в зависимости от наличия «галки» 'Enable CSMT for better graphic perfomance' в winecfg), а в консоли нет цветастого упоминания 'Native Direct3D 9'.

Может, есть у кого истории успеха «Wine 1.7.37 + Staging + Gallium Nine»? Может, в каком-нибудь OpenSuseBuildService'е, AUR'е или ином COPR/ppa есть нужный совместимый патч?

 , ,

carasin ()

Где брать патч с добавлением Gallium-nine для Wine

Cast Novell-ch.

Здесь не патч, а уже патченый Wine. Здесь как раз патч, но для версии 1.7.31 (актуальная на настоящий момент — 1.7.33).

Для того чтобы собрать пакет под Fedora по уже имеющемуся *.spec-файлу с минимальными изменениями, нужен именно патч.

Таковой в живой природе встречается?

 , , ,

carasin ()

А вы знали, что в kde-plasma-networkmanagement с недавних пор есть AP-mode?

 , ,

carasin ()

Блоб NVIDIA 325.08 beta

Сегодня вышла бета новой ветки R325. Блоб с индексом 325.08 содержит массу нововведений. А именно:

  • Fixed a bug that could cause display flickering after setting some scaling configurations.
  • Fixed a bug that prevented the status bar on the «PowerMizer» and «X Server XVideo Settings» pages in the nvidia-settings control panel from being updated when settings were changed by another NV-CONTROL client.
  • Fixed a bug that could cause some UI elements to be duplicated in the nvidia-settings control panel following a VT switch on X server configurations with multiple NVIDIA X screens.
  • Changed the default PCIe interrupt delivery method from virtual-wire to MSI. Note that if the NVIDIA Linux driver fails to initialize with an error indicating that it is not receiving interrupts, MSI can be disabled by setting the module parameter «NVreg_EnableMSI=0» when loading the NVIDIA kernel module.
  • Removed support for Linux 2.4 kernels. The NVIDIA Linux driver now requires Linux 2.6.9 or later.
  • Fixed a bug that prevented the creation of a mode via RandR with the same name as a previously created mode, even after the previous mode had been deleted.
  • Fixed a bug in nvidia-settings that caused GTK+ theme colors to be ignored for some UI elements.
  • Fixed a bug that caused nvidia-settings to write hostname-based color correction settings to the .nvidia-settings-rc configuration file, even when the «Include X Display Names in the Config File» option was unset. This could lead to a long delay when starting nvidia-settings, if a hostname saved to the configuration file failed to resolve.
  • Fixed a bug that exposed edge overlap controls on the SLI Mosaic page of nvidia-settings on edges where overlap was impossible.
  • Fixed a bug that caused some settings in the nvidia-settings control panel to be reset when reprobing displays.
  • Fixed a bug that could cause OpenGL applications that use Frame Buffer Objects (FBOs) to crash following a mode switch (e.g. changing the resolution of a display or transforming it).
  • Fixed a memory leak that could be triggered by unloading libGL before destroying all GLX contexts.
  • Fixed a bug that could cause color correction settings to be applied to the wrong display when multiple displays are unplugged and then plugged back in again.
  • Fixed a bug that could cause a spurious error message about a missing NV-GLX extension when performing indirect rendering from a GLX client with the NVIDIA client-side OpenGL libraries to a non-NVIDIA GLX server.
  • Fixed an OpenGL bug that prevented conditional rendering from the NV_conditional_render extension from correctly affecting CopyPixels.
  • Improved the rendering performance of complex gradients.
  • Added support for configuring SLI Mosaic and Base Mosaic in the «X Server Display Configuration» page of nvidia-settings.
  • Updated nvidia-installer to look for the following files:
    /usr/lib/nvidia/alternate-install-available
    /usr/lib/nvidia/alternate-install-present
    These files may be provided by NVIDIA driver installers other than the official .run package maintained by NVIDIA, to alert nvidia-installer to the presence or availability of an alternative installation method. See the nvidia-installer(1) manual page for more information.
  • Fixed an X driver bug where the RandR CRTC panning area and tracking area were not getting clamped to the current X screen size when the RandR CRTC transitioned from disabled to enabled.
  • Fixed an X driver bug where successful RandR X_RRSetScreenConfig requests would update the server's RandR 'lastSetTime' too far, potentially causing subsequent RandR requests to be unnecessarily rejected.
  • Fixed an X driver bug that caused GPUs to become inaccessible via the NV-CONTROL X extension when no corresponding X screens could be initialized.
  • Generate a BadMatch error when applications attempt to create GLX pixmaps using glXCreatePixmap() or glXCreateGLXPixmapWithConfigSGIX() and the pixmap's depth doesn't match that of the specified GLXFBConfig.
  • Updated nvidia-settings to explicitly specify the direction of rotation for configuring per-display rotation configuration.
  • Honor a GPU UUID as the GPU qualifier for X configuration options that allow GPU qualifiers (e.g. «MetaModes»).
  • Report GPU UUIDs in the X log when verbose logging is enabled in the X server.
  • Enabled conformant glBlitFrameBuffer() scissor test behavior by default. A driver-provided application profile enables the previous non-conformant behavior for applications that load libcogl, to work around a bug in older versions of libcogl.
  • Application profiles can be added to enable the non-conformant behavior for other applications that depend upon it. See the «Known Issues» section of the README for more details.
  • Fixed a bug that caused the X server to crash when querying the current mode of disabled displays.

Качать тут:
для x86
для x86_64
для x86_64 no compat
для ARMv7_HF

 , , ,

carasin ()

Wine 1.6 «дорос» до RC4

Всё как обычно. Вчера была пятница — разработчики Wine'а выкатили новый RC ветки 1.6. Снова только исправления ошибок.

Пакеты для F19b: i686, x86_64. Если найдутся желающие использовать их на F18 и ниже, то, как обычно, можно пересобрать из *.src.rpm'ок (есть внутри архивов) по любой из этих инструкций, либо установить пакеты от F19.

Напоминаю, что для использования Wine'а на 64-разрядной Fedora не лишним будет доустановить следующие пакеты от 32-битной ОС:

wine-capi
wine-cms
wine-core
wine-ldap
wine-openal
wine-pulseaudio
wine-twain
Тарбол с сорцами для всех остальных:
http://prdownloads.sourceforge.net/wine/wine-1.6-rc4.tar.bz2
http://mirrors.ibiblio.org/wine/source/1.6/wine-1.6-rc4.tar.bz2

 ,

carasin ()

Ветка Wine 1.6 обновилась до RC3

Вчера вышла версия Wine 1.6-rc3. Как и в предыдущие разы, выпуск имеет характер багфикс-релиза.

Как и раньше, опакетил для F19. Архивы с пакетами можно взять здесь и тут (для i686 и x86_64 соответственно). Для пользователей F18 и более старых выпусков (возможно, и для CentOS/etc.) инструкции тут: раз, два. Хотя, можно использовать и пакеты по ссылкам выше, никто не запрещает.

На 64-разрядных системах рекомендуется установить также следующие 32-битные пакеты:

wine-capi
wine-cms
wine-core
wine-ldap
wine-openal
wine-pulseaudio
wine-twain
Исходники — для пользователей остальных дистров:
http://prdownloads.sourceforge.net/wine/wine-1.6-rc3.tar.bz2
http://mirrors.ibiblio.org/wine/source/1.6/wine-1.6-rc3.tar.bz2

 ,

carasin ()

Ветка Wine 1.6 уже имеет версию RC2

Разработчики Wine'а, похоже, решили выкатывать новую версию раз в неделю. В общем, вышел Wine 1.6-rc2. Версия привносит исключительно исправления ошибок.

Пользователи Fedora 19 могут взять пакеты отсюда (для i686) и отсюда (для x86_64). В тарболах находятся, в том числе, и *.src.rpm'ки, так что пользователи других версий Fedora могут просто пересобрать пакеты под используемый ими релиз (локально либо в mock'е). Хотя, никто не мешает накатить пакеты от более нового выпуска на более старую ОС. Параноики традиционно идут лесом ;)

Пользователям 64-битных систем рекомендуется также установить следующие i686-пакеты:

wine-cms-1.6.rc2-0.fc19.i686
wine-openal-1.6.rc2-0.fc19.i686
wine-pulseaudio-1.6.rc2-0.fc19.i686
wine-core-1.6.rc2-0.fc19.i686
wine-twain-1.6.rc2-0.fc19.i686
wine-ldap-1.6.rc2-0.fc19.i686
wine-capi-1.6.rc2-0.fc19.i686

Сорцы для всех остальных:
http://prdownloads.sourceforge.net/wine/wine-1.6-rc2.tar.bz2
http://mirrors.ibiblio.org/wine/source/1.6/wine-1.6-rc2.tar.bz2

 ,

carasin ()

Новая ветка Wine — 1.6-rc1

Как обычно (в пятницу, раз в две недели) проверяю обнову Wine'а, а там такое:

The Wine development release 1.6-rc1 is now available.

This is the first release candidate for the upcoming Wine 1.6. It marks the beginning of the code freeze period. Please give this release a good testing to help us make 1.6 as good as possible.

What's new in this release (see below for details):

  • New implementation of the typelib creation support.
  • GLSL-based support for fixed function vertex shaders.
  • Support for desktop launchers in virtual desktop mode.
  • Fixes for Japanese vertical text.
  • New Croatian translation.
  • Various bug fixes.

The source is available from the following locations:

http://prdownloads.sourceforge.net/wine/wine-1.6-rc1.tar.bz2
http://mirrors.ibiblio.org/wine/source/1.6/wine-1.6-rc1.tar.bz2

Опакетил для Fedora. Выкладываю *.src.rpm, чтобы не было криков «троян!», «вирусы в моих линуксах!». Из-за проблемы с rpmbuild'ом (не хочет воспринимать символ "-" в версии софта) пришлось перепаковать оригинальный тарболл с сорцами (заменил "-" на "." в названии архива), т.ч. без паники ;D

 ,

carasin ()

Снимите ограничение на отправку комментариев в новости о выходе Fedora 18.

Сабж.

carasin ()

Intel HD3000 не умеет OpenGL 3.X

Доброго всем!

Проблема заключается в следующем.

На только что купленном ноутбуке Samsung 300U1A имеется графика Intel HD3000, которая, по идее, умеет OpenGL >= 3.0. На этой машинке установлена Fedora 18 beta (RFRemix), т.е. Mesa имеет версию 9.0.1. Однако, ни о каком OpenGL 3.X система не ведает. Установил пакет libtxc_dxtn, но ситуация не изменилась.

Вот несколько выхлопов:

$ lspci -vnn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL version string: 2.1 Mesa 9.0.1
OpenGL shading language version string: 1.30
OpenGL extensions:

$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
    GL_NV_conditional_render, GL_AMD_draw_buffers_blend,

$ rpm -qa xorg-x11-drv-intel
xorg-x11-drv-intel-2.20.16-1.fc18.i686

$ rpm -qa | grep mesa
mesa-dri-drivers-9.0.1-3.fc18.i686
mesa-libGLU-9.0.0-1.fc18.i686
mesa-libglapi-9.0.1-3.fc18.i686
mesa-libgbm-9.0.1-3.fc18.i686
mesa-libEGL-9.0.1-3.fc18.i686
mesa-dri-filesystem-9.0.1-3.fc18.i686
mesa-libxatracker-9.0.1-3.fc18.i686
mesa-libGL-9.0.1-3.fc18.i686

$ rpm -qa libtxc_dxtn
libtxc_dxtn-1.0.0-2.fc17.i686

$ uname -r
3.6.11-3.fc18.i686
Как получить OpenGL 3.X?

 , , , ,

carasin ()

Блоб nvidia 313.09 beta

Собственно, сабж. По стабильности порадовал больше, чем 310.19, ибо в последнем сломали уход в s2ram и регулировку яркости (в который раз!). В 313.09 с этим всё OK — прям как на 310.14.

Из новшеств (переводить в лом, ибо не релиз; по этой же причине пишу в talks'ах):

  • Added unofficial GLX protocol support (i.e for GLX indirect rendering) for the following extension and core commands:
    • GL_ARB_vertex_array_object;
    • OpenGL 3.0 commands ClearBufferfi, ClearBufferfv, ClearBufferiv, ClearBufferuiv and GetStringi.
  • Fixed a bug that caused the cursor shadow to be clipped to 32x32 pixels, even on Kepler GPUs that support a 256x256 cursor image.
  • Fixed a bug that prevented some cursor image updates from taking effect on displays with rotation or other transformations applied.
  • Fixed cursor alpha blending artifacts on displays with rotation or other transformations applied.
  • Added support for the GLX_EXT_buffer_age extension.
  • Improved the performance of glDrawPixels() by up to 450% when the pixel data is of type GL_BYTE.

Дополнительно можно отметить прогресс в попытках реализовать в проприетарном драйвере поддержку технологии Nvidia Optimus. Пока что разработчики стремятся «подпилить» под свой драйвер апстрим (осуществлена попытка абстрагирования от API DMA-BUF).

// Опакетил под Fedora'у. Кому надо — пишите.
// UPD1: в тред призывается megabaks.
// UPD2: ссылки для скачивания.

 ,

carasin ()

Прошу добавить кнопки LORCODE'а в форму ввода поста

Здравствуйте.

Не так давно LOR окончательно перешёл на LORCODE. Но даже после этого приходится каждый раз писАть [i]курсив[/i], [b]жирный текст[/b], [u]подчёркивание[/u], [s]зачёркивание[/s] и прочие цитаты со ссылками руками.

Намного удобнее было бы использовать встроенные в форму добавления поста соответствующие кнопки (по типу phpBB), которых, к сожалению, на данный момент нет. В этой связи прошу причастных к разработке движка (или как оно правильно называется?) LOR'а людей реализовать данный функционал.

// P.S.: я, похоже, ошибся с разделом; вероятно, стОит перенести в lor-source.

 , , ,

carasin ()

В чём подвох?

Имеется ноут. На нём проц Intel Core i3-2330 и видеокарта Nvidia GT 520M. В силу того, что в процессоре аппаратно заблокирована интеграшка HD 3000, технологии Optimus в ноуте нет в принципе, чему я был несказанно рад.

Но тут я решил сравнить производительность заблоченной интеграшки HD 3000 и дискретки GT 520M. Результат оказался, по меньшей мере, странным.

Вот я теперь и думаю: может, стОило взять такую же модель, но без дискретки? Хотя, конечно, идут и игрушки под Wine'ом, и всё остальное работает, но «осадочек-то остался».

 ,

carasin ()

[HDD][Samsung][SpinPoint M7E] Растёт <Load_Cycle_Count>, hdparm не помогает

Здравствуйте.

Есть ноутбук Samsung RV520, в котором установлен HDD SAMSUNG SpinPoint M7E [SAMSUNG HM321HI] (взято из smart'а). На нём непрерывно растёт показатель Load_Cycle_Count (я постоянно слышу щелчки [парковки головок HDD] во время работы ноута).

Только что было:

225 Load_Cycle_Count        0x0032   094   094   000    Old_age   Always       -       70206
Буквально через минуту уже так:
225 Load_Cycle_Count        0x0032   094   094   000    Old_age   Always       -       70217
Я прописал в rc.local вот это:
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
hdparm -B255 /dev/sda
hdparm -S0 /dev/sda
После перезагрузки проверяю: энергосбережение для HDD отключено:
$ sudo hdparm -B /dev/sda
/dev/sda:
 APM_level      = off
Но Load_Cycle_Count всё равно продолжает расти. Пока писАл этот пост, уже стало вот так:
225 Load_Cycle_Count        0x0032   094   094   000    Old_age   Always       -       70250
Как победить сей ужас (на других-то ноутах hdparm в автозагрузке помогал)? Просто хочется сохранить этот HDD, т.к. в остальном он устраивает (тихий [за исключением щелчков], практически не греется ― 34℃).

// Кстати, странно, что параметр Load_Cycle_Count в выхлопе smartctl находится под номером 225, а не как обычно 193.

carasin ()

[Samsung][RV-520] Не работают клавиши <Fn + Up/Down/F9>

Доброго всем.

Купил давеча Samsung RV-520 ― машинка, бесспорно, достойная. Но не заработали некоторые «горячие» клавиши, как то: Fn + Up, Fn + Down и Fn + F9. Первые две комбинации должны регулировать яркость подсветки дисплея, а последняя ― включать / отключать беспроводные устройства.

Пробовал разные рецепты, но решительно ни один не помог. В основном, в мануалах всё сводится к установке пакетов из PPA «voria», передаче ядру параметра acpi_backlight=vendor (ну, иногда ещё говорят, дескать, нужно отключить KMS,― ну, у меня-то он и так отключен, ибо установлен блоб nvidia, а nouveau «заблэклистчен») и прописыванию в xorg.conf'е строки Option «RegistryDwords» «EnableBrightnessControl=1». Также встречал мануал с редактированием правил udev'а.

Первый вариант, естественно, мне не подходит, т.к. не Ubuntu; а разобраться со вторым ― не хватило скилов (хотя, уверен, что оно тоже не сработает). Дело в том, что, в отличие от всех примеров «в googl'e», у меня проблема проявляется несколько иначе: в мануалах у людей, если не работает, то вообще никак; а в моём случае на мониторе показывается изменение уровня яркости (всплывает полоска, похожая на ту, что появляется при регулировке звука), а на самом деле изменения уровня яркости подсветки не наблюдается.

Интересно то, что при нажатии Fn + Up/Down также происходит изменение содержимого файлов actual_brightness и brightness в директории /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0/ (циферки там меняются от 1 до 7), но толку от этого, увы, нет.

$ sudo dmidecode -s system-product-name
RV420/RV520/RV720/E3530/S3530/E3420/E3520

В /lib/udev/rules.d/95-keymap.rules и /lib/udev/rules.d/95-keyboard-force-release.rules упоминаний о моей модели нет.

После того, как в /etc/acpi/events/videoconf раскомментировал строки:

event=video.*
action=/usr/sbin/vbetool dpms on
перестал сбрасываться уровень яркости подсветки (раньше сбрасывалось примерно на 50%) после выхода из спячки и отключения сети питания. Теперь яркость дисплея всегда «выкручена» до уровня 100% (и убавить её я не могу).

rfkill ничего не знает о беспроводной карте:

$ rfkill list
0: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
Но это меньшее из зол, т.к. и Wi-Fi, и BlueTooth можно «отключать мышкой» в соответствующих апплетах.

В общем, как мне заставить работать регулировку яркости и, по возможности, включение / отключение беспроводных интерфейсов?

// Ах да, на всякий случай создал багрепорт в багзилле RedHat'а. Но регулировку яркости, конечно, хочется получить как можно скорее.

carasin ()

[megabaks, прости] Что стало с блобом?

Заголовок, конечно не совсем информативен, ибо, скорее всего, всё завязано не только и не столько на блобе nvidia, а вовсе даже и на X'ах / glibc / новых ядрах / etc., но всё же...

Долго сидел на RFRemix 14, ибо 15'шка не впечатляла чуть более, чем вовсе. Наконец, случилось: вышла F16 (я не из криокамеры, просто, чтобы всё написанное далее смогло приобрести более-менее законченный вид, видимо, должно было пройти какое-то время)!

Так вот, о чём это я. Всегда в своих машинах использовал графику Nvidia: даже в стареньком ASP Linux 10 эти карточки не подводили - блоб «просто работал» и всё было хорошо.

...До тех пор, пока в моду не вошли X'ы 1.11 и блоб 285.x (и более поздние его версии). Установил в RFRemix 16 блоб 285.x - полезли сегфолты всего и вся. Говорят, в моих любимых кедах (при X'ах 1.11 и блобе >= 285.x) такое явление проявляется чаще. Допустим. Проапдейтил блоб до 290.x - сегфолты полезли ещё чаще. Не, ну ладно, если бы в работе какого-нибудь экзотического софта, но в systemsettings, nvidia-settings, compiz, virtualbox!

У меня на стационаре стоит GTS 250, на ноуте - 310M: то есть карточки практически одной (плюс-минус рюшечки) архитектуры. Естественно, глюки проявлялись идентичнейшие (да простят меня граммар-нацци!) на обеих машинах.

В качестве воркэраунда я выполнил:

# yum remove *nvidia*
# yum --releasever=15 downgrade xorg* --nogpgcheck
# yum --releasever=15 install akmod-nvidia* xorg-x11-drv-nvidia* nvidia-settings  nvidia-xconfig --nogpgcheck
# akmods
Сегфолты прекратились. Единственное, что по-прежнему не запускалось - так это compiz (ну и хрен с ним: всё равно в версии 0.9 его поломали - перейду на kwin). Но ведь это костыль?!

Попросил ребят из Russian Fedora, чтобы создали пакеты для ветки 275.x (ибо ветка стабильная, длительно поддерживаемая, да к тому же и официально рекомендованная). Народ там отзывчивый, понимающий - сделали (за что им сердечное спасибо!). Установил, потестил - нормально: по стабильности так же, как и с даунгрейднутыми до *fс15 блобом и X'ами. И вроде бы всё хорошо да замечательно!

...Думал я, покуда не собрал на днях брату жены одну конфигурацию. В общем-то, середнячок, ничего выдающегося: Core i3 2100, GT 520 1 ГиБ VRAM, 2 ГиБ RAM (по надобности потом сам доустановит), 500 ГиБ HDD (торгаши наглеют, за 1 ТиБ 4,6 kRUR просят, а за этот винт - 3,8). Так вот, установив на всё это хозяйство RFRemix 16 и убедившись в стабильности проявления сегфолтов в KDE на блобе >= 285.x, решил я повторить свой опыт отката на 275.x.

Но оказалось, что к выше упомянутым лагам добавились спонтанные зависания X'ов (видимо, на Fermi есть какие-то «особенности» в работе драйвера с X'ами). Думаю:«Хрен с ним, сделаю откат блоба, всё исправится.» Ан-нет! Зависоны X'ов проявились и на 275.x. Поначалу грешил на зависание всей ОСи (даже пробовал параметры pci=nomsi, pci=nocrs, acpi=copy_dsdt, acpi_osi=<бла-бла-бла>), но потом заметил, что сама ОСь жива (если на момент зависания играла музыка - то она продолжала играть, если шёл ролик в youtub'е - то опять-таки был слышен звук, если шло скачивание чего-то в EisKaltDC++ - то винт продолжал шуршать, а лампочка продолжала светиться, etc.).

В общем, не мудрствуя лукаво, снёс блоб, оставил nouveau. Но и тут меня ждало разочарование. Нет, фризы графики прекратились, но в выхлопе glxinfo | grep OpenGL числились слова wmware и llvmpipe, а по команде glxgears процессор нагружался на добрые 10% практически с нуля. Гугление на эту тему выдало, что используемый в F16 срез кодовой базы драйвера nouveau (от июля-месяца 2011 г.) ещё не поддерживает в сколь-нибудь приемлемом виде карточку GT 520, ибо необходимые изменения в этот драйвер были внесены лишь в октябре минувшего года (в rawhid'е и koji версии nouveau также от июля 2011 г.). К слову, и ядро значительно лучше поддерживает эту видюху только в версии 3.2.
_________________________________________________

В связи с описанными выше событиями у меня возникли два вопроса:

  1. Что случилось с блобом (X'ами / etc.)?
  2. Есть ли здесь люди, столкнувшиеся с аналогичными / похожими проблемами (историй успеха при похожих лагах, суди по гуглению, не было,- так что на решение сих непотребств до апдейта выше означенных компонентов системы не надеюсь)?

//P.S.: В сторону Fedor'ы не плеваться, ибо политика её разработчиков подразумевает отсутствие в официальных репозиториях несвободных (в той или иной форме) компонентов, так что использование RPM-Fusion'а и подобных репозиториев производится на свой страх и риск.
//P.P.S.: Переходить на другие дистры не предлагать, ибо привык к RPM (в то же время суся не впечатлила, магейя недопилена, мандрива почти мертва), да и «канпелять» генту у меня просто нет времени, не то что осваивать (я, в общем-то, и не IT'тишник вовсе).

Перемещено mono из Talks

carasin ()

[bugreport] В моих уведомлениях сообщение, не относящееся к моему аккаунту

Сегодня в моих уведомлениях появилась запись на это сообщение. Выглядит это так.
Собственно, всё :]

carasin ()

[VirtualBox-4.1][Fedora]kernel_panic

При использовании VirtualBox-4.0 всё отлично, но после апдейта до версии 4.1 и переустановки Extension_Pack'а (до соответствующей релизу версии) начинаются kernel_panic'и. Чаще всего - при выключении машины, реже - при очередной загрузке гостевой системы.
Тестировалось на двух машинах (в обоих случаях на хостах используется проприетарный видеодрайвер):

  • стационар (Intel E5200 2,5 ГГц, 2 ГБ RAM DDR3, Nvidia GeForce GTS 250 1 ГБ VRAM GDDR3);
  • ноутбук Lenovo G560 (Intel P6200 2,13 ГГц, 2ГБ RAM DDR3, Nvidia 310M 512 МБ VRAM GDDR3).

Проявляется вне зависимости от рода используемых гостевых ОС.
VirtualBox устанавливался из официального репозитория Oracl'а:

$ cat /etc/yum.repos.d/virtualbox.repo 
[virtualbox]
name=Fedora $releasever - $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/fedora/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc
На данный момент откатился назад на версию 4.0.
Использование именно версии 4.1 для меня не критично, но всё же интересно, у кого-нибудь ещё проявляется такая «регрессия»?
P.S.: Дистрибутив на обеих машинах - RFRemix 14 с последними обновами.

carasin ()

[Fedora][nvidia][vesafb] Перестали грузиться X'ы при использовании vesafb в консоли

Доброго времени суток!
На своём Lenovo G560 с самого начала (Fedora15) использовал связку:

список

  • в X'ах - драйвер nvidia (вот xorg.conf);
  • в консоли - vesafb; в grub.conf'е такие параметры:
    video=vesafb:ywrap,mtrr:3 vga=0x34D

Видеорежим vga=0x34D соответствует разрешению 1360x768@32, присутствует в списке виде-BIOS'а (при параметре vga=ask).
Спустя какое-то время откатился на Fedora14, на которой эта же конфигурация также исправно работала... какое-то время.
Внезапно при очередной загрузке отказались грузиться X'ы. Посмотрел /var/log/Xorg.0.log, там говорилось:

(EE) NVIDIA(0): Failed to initialize the NVIDIA GPU at PCI:1:0:0.  Please
(EE) NVIDIA(0):     check your system's kernel log for additional error
(EE) NVIDIA(0):     messages and refer to Chapter 8: Common Problems in the
(EE) NVIDIA(0):     README for additional information.
(EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device!
(II) UnloadModule: "nvidia"
(II) UnloadModule: "wfb"
(II) UnloadModule: "fb"
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found
Методом тыка было выяснено, что при смене режима на vga=0x34C (1360x768@16) всё начинает работать как надо. На этом и успокоился, пока не...
Повторилась точь-в-точь такая же ситуация. Вот только смена режима vga на любой другой, имеющийся в списке видео-BIOS'а, уже не давала никакого результата (X'ы также не грузились вот с таким логом - приведён проблемный кусок с «хвостиком»).
Метод тыка дал следующий результат: работоспособность X'ов восстанавливается при удалении параметра video=vesafb:ywrap,mtrr:3 vga= вообще. Но так теряется фреймбуферная консоль (а также, в частности, plymouth) и почти нативное её разрешение (оригинальное - 1366x768).

Как исправить ситуацию? Может, какие-то параметры я указал неверно?

P.S.: Версии пакетов

$ yum -C list installed *nvidia* xorg*server*
Установленные пакеты
akmod-nvidia.i686                              1:270.41.06-1.fc14.1.R        @russianfedora-nonfree-updates
kmod-nvidia.i686                               1:270.41.06-1.fc14.1.R        @russianfedora-nonfree-updates
kmod-nvidia-2.6.35.13-91.fc14.i686.i686        1:270.41.06-1.fc14.1.R        @russianfedora-nonfree-updates
kmod-nvidia-2.6.35.13-92.fc14.i686.i686        1:270.41.06-1.fc14.1.R        installed                     
kmod-nvidia-2.6.35.6-45.fc14.i686.i686         1:270.41.06-1.fc14.1.R        installed                     
nvidia-settings.i686                           1.0-9.fc14                    @rpmfusion-nonfree-updates    
nvidia-xconfig.i686                            1.0-7.fc14                    @rpmfusion-nonfree-updates    
xorg-x11-drv-nvidia.i686                       1:270.41.06-1.fc14            @russianfedora-nonfree-updates
xorg-x11-drv-nvidia-libs.i686                  1:270.41.06-1.fc14            @russianfedora-nonfree-updates
xorg-x11-server-Xephyr.i686                    1.9.5-1.fc14                  @updates                      
xorg-x11-server-Xorg.i686                      1.9.5-1.fc14                  @updates                      
xorg-x11-server-common.i686                    1.9.5-1.fc14                  @updates                      
xorg-x11-server-utils.i686                     7.5-5.fc14                    @updates

$ uname -a
Linux berlogue 2.6.35.13-92.fc14.i686 #1 SMP Sat May 21 17:39:42 UTC 2011 i686 i686 i386 GNU/Linux

carasin ()

RSS подписка на новые темы