LINUX.ORG.RU

Сообщения carasin

 

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

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

 

carasin
()
5 комментариев

[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
()
4 комментария

[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
()
6 комментариев

compat-wireless не собирается

Доброго всем!
Проблема обстоит вот в чём:
Есть самосборное ядро 2.6.38.2-8.dsdt1201n.fc14.i686.PAE на RFR14 (Fedora), но в 2.6.38 сломали драйвер ath9k (на дистрибутивном из F15 тоже не работает wi-fi, чип AR9285). Поэтому было принято решение установить compat-wireless, отмеченный как стабильный, взятый из ядра 2.6.37 (на ядре 2.6.37 моя карта wi-fi работает отлично). Но в ходе компиляции вылетает ошибка. Порядок действий таков: 

$ ./scripts/driver-select ath9k
Processing new driver-select request...
Backing up makefile: Makefile.bk
Backup exists: Makefile.bk
Backup exists: Makefile.bk
Backup exists: Makefile.bk
Backing up makefile: drivers/net/wireless/Makefile.bk
Backing up makefile: drivers/net/wireless/ath/Makefile.bk
Backing up makefile: net/wireless/Makefile.bk
Backing up makefile: drivers/net/Makefile.bk
Backing up makefile: drivers/ssb/Makefile.bk
Backing up makefile: drivers/misc/eeprom/Makefile.bk
Backup exists: Makefile.bk

$ make
...
/home/carasin/Distrib/Drivers/compat-wireless/compat-wireless-2.6.37-4-sn/net/wireless/util.c: В функции ‘cfg80211_change_iface’:
/home/carasin/Distrib/Drivers/compat-wireless/compat-wireless-2.6.37-4-sn/net/wireless/util.c:790:2: ошибка: неявная декларация функции ‘br_port_exists’
make[3]: *** [/home/carasin/Distrib/Drivers/compat-wireless/compat-wireless-2.6.37-4-sn/net/wireless/util.o] Ошибка 1
make[2]: *** [/home/carasin/Distrib/Drivers/compat-wireless/compat-wireless-2.6.37-4-sn/net/wireless] Ошибка 2
make[1]: *** [_module_/home/carasin/Distrib/Drivers/compat-wireless/compat-wireless-2.6.37-4-sn] Ошибка 2
make[1]: Выход из каталога `/usr/src/kernels/2.6.38.2-8.dsdt1201n.fc14.i686.PAE'
make: *** [modules] Ошибка 2
Смотрим в /home/carasin/Distrib/Drivers/compat-wireless/compat-wireless-2.6.37-4-sn/net/wireless/util.c, видим такое: 
789|	/* if it's part of a bridge, reject changing type to station/ibss */
790|	if (br_port_exists(dev) &&
791|	    (ntype == NL80211_IFTYPE_ADHOC ||
792|	     ntype == NL80211_IFTYPE_STATION ||
793|	     ntype == NL80211_IFTYPE_P2P_CLIENT))
794|		return -EBUSY;
Что бы это могло значить (ни разу не кодер, код не понимаю) и как решить эту проблему?
P.S.: Пробовал и compat-wireless, и compat-wireless-sn - результат один и тот же. Вот немного инфы: 
$ uname -a
Linux berlogue 2.6.38.2-8.dsdt1201n.fc14.i686.PAE #1 SMP Mon Mar 28 21:12:32 MSD 2011 i686 i686 i386 GNU/Linux

$ yum list installed gcc
Установленные пакеты
gcc.i686               4.5.1-4.fc14               @fedora

carasin
()
7 комментариев

[Fedora][2.6.38][AR9285] Не работает

Доброго времени суток!
Я использую RFR14. По ряду причин на моём EeePC 1201N можно использовать ядро либо до *.32 включительно, либо *.37 и выше. Хотя, насчёт «выше» не совсем уверен. В общем, это связано с модулем wi-fi. $ lspci -v выдаёт такое: 

07:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
        Subsystem: Device 1a3b:1a89
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at fbef0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: ath9k
        Kernel modules: ath9k
На промежуточных между указанными выше версиях ядра случались мёртвые фризы системы при работе беспроводной сети. Поэтому ещё с RC-каких-то_там использую kernel-2.6.37-2. Пробовал в своё время 2.6.38-RC* из rawhide - wi-fi не работал вообще. В связи с выпуском финальной версии ядра 2.6.38 решил снова его «пощупать» (2.6.38.1-6 из koji). И снова то же самое!
Непосредственно проблема вылазит так: беспроводные сети видно через nm-applet, к ним можно подключиться, но не пингуется ни один адрес, также не пингуется и эта машина; также я могу создавать сети (ad-hoc), но с других машин их не видно (пробовал разные типы шифрования и без шифрования вообще).
Думал, что проблема в пакете linux-firmware: обновил его из F15 - не помогло. Но интерес вызывает вывод ifconfig: 
wlan0     Link encap:Ethernet  HWaddr 74:F0:6D:4F:2C:79  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:7759 (7.5 KiB)
Смущают строки RX и TX. Похоже, что модуль не может принять данные из сети (или же отослать их во внешнюю сеть?). Google посылает на какие-то Ubuntu'шные англоязычные форумы, где проблема также не решена, а единственная отписка - это предположение о том, что «новая версия драйвера пытается искать firmware в /usr/firmware/» (вольный перевод авт.). Но, ЕМНИП, моей карте фирмварь не нужна.
dmesg тут.
Есть идеи, как заставить wi-fi работать корректно на ядре 2.6.38 ?

 

carasin
()
53 комментария (стр. 2)

Задействование исправленного DSDT

Здравствуйте все! Не совсем уверен в правильности выбора раздела для своего поста, но, всё же...
Дано: RFR14 (kernel 2.6.37-2.fc15); Asus EeePC 1201N с очень кривой таблицей DSDT; потраченный на исправление DSDT день (спасибо Googl'у); вроде как исправленный и безошибочно скомпилировавшийся DSDT (DSDT.aml, DSDT.dsl, DSDT.hex); желание протестировать сотворённое; вера в успех.
Цель: задействовать получившуюся таблицу DSDT в системе и дальнейшее тестирование оной.
Вопрос: как мне достигнуть цели с выше указанными данными?
Благодарю за внимание.
P.S.: в Googl'е ничего конкретного по современным версиям Fedor'ы не нашёл - всё, что есть, либо уже протухло, либо про другие дистры.

carasin
()
34 комментария

[DSDT][17 Errors, 37 Warnings]Хочу исправить.

Доброго всем!
Есть EeePC 1201N. Много где в инете пишут, что очень уж кривой на нём DSDT. И правда, воркэраундов и условностей (связанных с ACPI) для нормального функционирования на этом нетбуке GNU/Linux, предостаточно. Решил проверить, так сказать, экспериментально.
Что делал: 

# acpidump > /home/carasin/dsdt/acpidump.txt
$ acpixtract /home/carasin/dsdt/acpidump.txt
...
$ ls /home/carasin/dsdt/
acpidump.txt  DSDT.dat SSDT.dat
$ cd /home/carasin/dsdt/
$ iasl -d ./DSDT.dat
...
$ ls
acpidump.txt  DSDT.dat  DSDT.dsl  SSDT.dat
$ iasl -tc ./DSDT.dsl
...
...
ASL Input:  ./DSDT.dsl - 10666 lines, 358816 bytes, 4472 keywords
Compilation complete. 17 Errors, 37 Warnings, 0 Remarks, 69 Optimizations
$ ls
acpidump.txt  DSDT.aml  DSDT.dat  DSDT.dsl  DSDT.hex  SSDT.dat
Полный выхлоп iasl -tc ./DSDT.dsl лежит здесь.
Если есть люди, разбирающиеся в коде и правке DSDT, прошу помочь, ибо сам я - и по образованию, и по профессии - ни разу не программер (а как-то к энергетике ближе). Сейчас конфигурация работает с дополнительными параметрами ядра (acpi=copy_dsdt pci=nomsi acpi_osi=Linux acpi_backlight=vendor) и только с ядром 2.6.37. В остальных случаях очень много глюков, особенно связанных с работой сетевых интерфейсов.
P.S.: Intel Atom 330 1.6 GHz, RAM 2 GB DDR2 800 MHz, Nvidia ION 256 MB shared memory, Wi-Fi AR9285 b,g,n, Ethernet AR8132 1000/100 Mbps.

 

carasin
()
4 комментария

[Fedora][boot][segfault]

Доброго времени суток.
Суть проблемы: на одной и той же стационарной машине стали случаться вот такие глюки при загрузке системы. Далее следует переустановка системы с нуля, затем проходит какое-то время (от недели до месяца) - и опять двадцать пять!
Думал, что дело в HDD: проверки результатов не дали, но на всякий случай купил другой (в любом случае, лишние 500 ГБ не помешают). Оказалось, с новым HDD проблемы те же (в обоих случаях используется WD: первый - Caviar Black WD5001AALS, второй - Caviar Blue WD5000AAKS).
Связь с предшествующими данным глюкам событиями туманна, но есть один общий симптом - первым делом пропадают пароли: то пользователя, то root'а (их, конечно, можно восстаноить, но это в лучшем случае лишь отсрочит неминуемое).
В итоге в один прекрасный момент можно лицезреть сегфолты всего и вся при загрузке. Вот тут привожу dmesg последней (естественно, неудачной) попытки загрузиться.
OS: RFR13/14 (одинаковые симптомы болезного компа)
FS: ext4

 , ,

carasin
()
27 комментариев

[EeePC 1201N][Fedora][Fn+F9]Вкл./откл. тачпада

Есть нетбук Asus EeePC 1201N, на котором установлена RFR14. Многие из функциональных клавиш заработали «из коробки», но не Fn + F9 (вкл./откл. тачпада). Порядок моих действий: 

$ acpi_listen
hotkey ASUS010:00 00000037 00000006
 PNP0C14:01 000000d2 00000000
так я узнал код сочетания клавиш Fn + F9. Далее: 
$ ls /etc/acpi/events/
powerconf  videoconf
$ sudo touch /etc/acpi/events/touchpadconf
$ ls /etc/acpi/events/
powerconf  touchpadconf  videoconf
В /etc/acpi/events/touchpadconf пишу: 
event=hotkey ASUS010:00 00000037
action=/etc/acpi/actions/touchpad.sh
Далее: 
$ ls /etc/acpi/actions/
power.sh
$ sudo touch /etc/acpi/actions/touchpad.sh
$ sudo chmod +x /etc/acpi/actions/touchpad.sh
$ ls /etc/acpi/actions/
power.sh  touchpad.sh
В /etc/acpi/actions/touchpad.sh пишу: 
#!/bin/sh

# get the current state of the touchpad
TPSTATUS=`synclient -l | grep TouchpadOff | awk '{print $3}'`

# if getting the status failed, exit
test -z $TPSTATUS && exit 1

if [ $TPSTATUS = 0 ]; then
synclient TouchpadOff=1
else
synclient TouchpadOff=0
fi
Потом делаю рестарт демона acpid. Нажимаю Fn + F9, и... Реакции ноль.
Эксперимантальным путём выяснил, что эта схема начинает работать после после того, как руками сделаю: 
$ sudo acpid
Работа службы acpid выставлена на всех runtime_level'ах в system-config-services (это видно в логе загрузки). Также пробовал запихивать запуск acpid rc.local - аналогично: автоматом не срабатывает.
Как заставить работать Fn + F9 сразу после загрузки системы без вмешательства пользователя?

 

carasin
()
31 комментарий

EeePC 1201N & Fedora

Собственно, сабж. Проблема заключается в постоянных kernel_panic'ах при использовании сети. Проявляется на различных ядрах (2.6.33.X - 2.6.35.X). Раньше вдобавок были и просто мёртвые зависания системы (нетбук не реагировал _ни_на_что_), но после добавления в grub.conf параметров acpi_osi=Linux acpi_backlight=vendor pci=nomsi прерывания в работе системы стали немного реже, причём все исключительно с kernel_panic'ом. Следует отметить, что сбои происходят при использовании сети: как интенсивном, так и слабом. В интеренетах говорят, что проблема заключается в модулях ethernet и wi-fi. lspci -v говорит: 

Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
Subsystem: Device 1a3b:1a89
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fbef0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: ath9k
Kernel modules: ath9k

Ethernet controller: Atheros Communications AR8132 Fast Ethernet (rev c0)
Subsystem: ASUSTeK Computer Inc. Divice 14e5
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at fbfc0000 (64-bit, non-prefetchable) [size=256K]
I/O ports at ec00 [size=128]
Capabilities: <access denied>
Kernel driver in use: atl1c
Kernel modules: atl1c
Путь к решению проблемы с ethernet - параметр ядра pci=nomsi (честно говоря, не проверял - не столь критично). А вот с wi-fi... Короче говоря, последний раз перед сбоем успело выскочить сообщение из трея: 
Message from syslogd@berlogue...
kernel:Disabling IRQ #18
Несмотря на установленный в системе блоб nvidia, дело не в нём: на nouveau происходит то же самое. Проблема также проявляется и при загрузке с live-usb (live-cd), а также при использовании других дистрибутивов (openSuSE 11.3, Ubuntu 10.10). В чём может быть проблема? Что попробовать? Заранее благодарен.

carasin
()
38 комментариев
← предыдущие

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