Jump to content

    

eug

Участник
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

0 Обычный

About eug

  • Rank
    Участник
  • Birthday 09/29/1967

Контакты

  • Сайт
    http://
  • ICQ
    497187383

Информация

  • Город
    Сибирь

Recent Profile Visitors

1293 profile views
  1. Nixon, спасибо огромное за помощь! Спасибо всем откликнувшимся! Всё заработало! Случай оказался единичный. Я думаю, причина в совпадении смены адреса почтового Владом (с сопутствующей повторной активацией) и переезда форума. Это происходило примерно в начале июля. Тему можно закрывать. :)
  2. На очищенные куки/кэш выдаёт: Название страницы: "К сожалению, у вас нет разре шения на это!" Текст в окне: "Извините, возникла проблема Что-то пошло не так. Пожалуйста, попробуйте еще раз. Код ошибки: 2S119/1" При, непосредственно, повторной попытке входа: Название страницы: "К сожалению, мы не могли найти это!" Текст в окне: "Извините, возникла проблема Этот пользователь не ожидает одобрения Код ошибки: 2S129/4" При этом, без очистки куков+кэш переход на главную страницу форума невозможен.
  3. Здравствуйте! Теперь пишет: "Введенный вами пароль недействителен. Пожалуйста, попробуйте еще раз (убедитесь, что режим Caps Lock выключен)".
  4. Создал тему, полагаю это не единичный случай. Ситуация следующая: пользователь "maailmankaikkeus" (работаем в одной фирме) в июле 2018г. изменил e-mail в настройках учетной записи, и после этого не может ее активировать. До октября часть форума была доступна без возможности отправки сообщений и ЛС. Сейчас при попытке захода на сайт появляется сообщение: "Извините, возникла проблема Этот пользователь не ожидает одобрения Код ошибки: 2S129/4" Очистка кэша и куков не влияет на поведение страницы. Проверено на нескольких браузерах. В инете link пишут, что возможна ситуация: "У части пользователей после конвертации данных при обновлении случился глюк, когда система требовала их активации... не требуя их активации." Вопрос: Реально ли починить, или создавать новый аккаунт?
  5. EE & Linux

    Сообщения вида: Цитата(bureau @ Jan 12 2013, 02:17) /opt/mentor/7.9.4EE/SDD_HOME/common/linux/MainWin5/bin-linux_optimized/regedit: symbol lookup error: /usr/lib/i386-linux-gnu/libXext.so.6: undefined symbol: _XGetRequest в ЕЕ 7.9.4 починил коррекцией файлов посредством комментирования строк, относящихся к использованию Х-библиотек, поставляемых с MainWin5: /SDD_HOME/common/linux/MainWin5/setup-mwuser CODE export _THREAD_LOCKS_MISALIGNED fi ;; linux) #~ LD_LIBRARY_PATH=${LD_LIBRARY_PATH:-} #~ libX11=`ldd "${MWHOME}"/bin-${MWARCH_OS}/mwxcbtest | grep libX11.so | awk '{print $3}'` #~ libxcb=`ldd ${libX11} | grep libxcb.so | awk '{print $3}'` #~ if [ "x$libxcb" != "x" ]; then #~ MWUSE_XCB=true #~ LD_LIBRARY_PATH="${MWHOME}"/lib-${MWARCH_OS}/X11:${LD_LIBRARY_PATH} #~ if [ "x$XLOCALEDIR" = "x" ]; then #~ XLOCALEDIR=`strings ${libX11} | grep "/locale" | head -n 1` #~ export XLOCALEDIR #~ fi #~ if [ "x$XKEYSYMDB" = "x" ]; then #~ XKEYSYMDB=`strings ${libX11} | grep "XKeysymDB"` #~ export XKEYSYMDB #~ fi #~ fi #~ export LD_LIBRARY_PATH # For backwards-compatible behaviour of setjmp/longjmp # in glibc-2.4 and higher glibcver=`rpm -q glibc | sed -n -e '1s/^glibc-\([0-9]*\.[0-9]*\)[.-].*$/\1/p'` case ${glibcver} in 2.4) LD_POINTER_GUARD=1;; и /SDD_HOME/common/linux/MainWin5/setup-mwuser.csh : CODE unsetenv osver breaksw case linux: #~ if (! ${?LD_LIBRARY_PATH}) then #~ setenv LD_LIBRARY_PATH "" #~ endif #~ setenv libX11 `ldd "${MWHOME}"/bin-${MWARCH_OS}/mwxcbtest | grep libX11.so | awk '{print $3}'` #~ setenv libxcb `ldd ${libX11} | grep libxcb.so | awk '{print $3}'` #~ if ( x${libxcb} != x) then #~ setenv MWUSE_XCB true #~ if (! ${?XLOCALEDIR}) then #~ setenv XLOCALEDIR `strings ${libX11} | grep "/locale" | head -n 1` #~ endif #~ if (! ${?XKEYSYMDB}) then #~ setenv XKEYSYMDB `strings ${libX11} | grep "XKeysymDB"` #~ endif #~ setenv LD_LIBRARY_PATH "${MWHOME}"/lib-${MWARCH_OS}/X11:${LD_LIBRARY_PATH} #~ endif unsetenv libxcb unsetenv libX11 # For backwards-compatible behaviour of setjmp/longjmp # in glibc-2.4 and higher set glibcver=`rpm -q glibc | sed -n -e '1s/^glibc-\([0-9]*\.[0-9]*\)[.-].*$/\1/p'` switch ($glibcver) Одна проблемма: DX стартует очень долго, бывает до полторы минуты, при выключении DX так же долго пишет резерв какой то базы данных. OpenGL работает нормально. дистрибутив - Gentoo X: xorg-server-1.13.1 glibc-2.15 драйвер nvidia - 313.18 оконная система - Gnome - 2.32
  6. Не стартует Atmega644P

    Однако была подобная тема с контроллерами AT91SAM7S. Часть плат не стартовали при температуре корпуса ниже +20 градусов цельсия. Требовали повторного включения питания. Из 150 плат проблемма проявилась на 4 (фабричный монтаж), из 10 плат не стартовали 5 ( сборка вручную, феном). Проблемма оказалась в "перегреве" при сборке. По даташиту микросхема выдерживает +260С однократно. Практически нагрев до +250С приводил к нарушению внутренних цепей старта микросхемы. Подобный эффект в меньшем обьёме наблюдался так же у микросхем AT91RM9200-QI-002.
  7. Вышел EE7.9.2

    А возможно ли так же залить и Linux - версию с update 6 ?
  8. Спасибо SM и Fill ! Бубен другой системы работает! P.S.: До старта dash (по привычке работаю через Dashboard) добавил: Кодexport LD_LIBRARY_PATH=${LDPATH}:${LD_LIBRARY_PATH} ибо пути к библиотекам OpenGL "Gentoo" прописывает в LDPATH.
  9. Цитата(SM @ Dec 6 2009, 20:12) А как по ментору понять, работает опенгл или нет? У меня вот после "Enable OpenGL" этот пункт меню становится серым... Рассмотрение strace показывает, что все опенгл-евские либы он нашел в /usr/lib, куда их установщик nvidia ставит, ошибок вроде нет. И что дальше? Как понять, заработал опенгл или нет? Если ментор обнаружил наличие ускорителя, пункт "Enable OpenGL" позволяет включить/выключить оное. Если не обнаружил - в окне сообшений пишет: "Info: Hardware acceleration is not available on this system. OpenGL support can not be enabled." При включенном GL прорисовка в несколько раз быстрее производится, чем без ускорения. Это заметно на "больших" платах в редактировании и в 3D-viewer. На счет линков - наверное только в моей ОСке( Gentoo x86 ) установщик драйвера создает следующее: /usr/lib: libcuda.so libnvidia-cfg.so.190.42 libXvMCNVIDIA.a opengl libcuda.so.1 libvdpau_nvidia.so libXvMCNVIDIA.so xorg libcuda.so.190.42 libvdpau_nvidia.so.190.42 libXvMCNVIDIA.so.190.42 /usr/lib/opengl/nvidia/extensions: libglx.so libglx.so.190.42 /usr/lib/opengl/nvidia/lib: libGLcore.so libGL.so libnvidia-tls.so libGLcore.so.1 libGL.so.1 libnvidia-tls.so.1 libGLcore.so.190.42 libGL.so.190.42 libnvidia-tls.so.190.42 /usr/lib/xorg/modules/drivers: nvidia_drv.so т.е. линки *.so.1 в /usr/lib/ в моей ситуации автоматически не создаются. Тогда вопрос по-другому: как обьяснить ЕЕ, что необходимые библиотеки лежат в /usr/lib/opengl/nvidia/lib и /usr/lib/opengl/nvidia/extensions ?
  10. На 32-битной системе OpenGL работает (после применения cd /usr/lib ln -s opengl/nvidia/lib/libGL.so libGL.so.1 ln -s opengl/nvidia/lib/libGLcore.so libGLcore.so.1 ln -s opengl/nvidia/lib/libnvidia-tls.so libnvidia-tls.so.1 ибо установщик драйвера не создает эти линки), на 64-битной танцы с бубном пока бесполезны... Может быть кто подскажет правильное слово?
  11. Всем спасибо за внимание к моему вопросу! ОДНАКО дело было не в бобине (спасибо des00): "Answer Record # 20391: 8.2i XST - "ERROR:Xst:1468 - "file.v" line xx: Unexpected event in always block sensitivity list": The following error occurs when I try to use the Verilog 2001 combinational sensitivity list (always @*) when reading a two-dimensional array:" не синтезируется: // always @* case ( pointer[2:0]) 3'd0 : A[mw-1:0] = msum_I[0][mw-1:0]; 3'd1 : A[mw-1:0] = msum_I[1][mw-1:0]; 3'd2 : A[mw-1:0] = msum_I[2][mw-1:0]; endcase синтезируется: // wire [mw-1:0]mmmmmmmsum0 = msum_I[0][mw-1:0]; wire [mw-1:0]mmmmmmmsum1 = msum_I[1][mw-1:0]; wire [mw-1:0]mmmmmmmsum2 = msum_I[2][mw-1:0]; // always @* case ( pointer[2:0]) 3'd0 : A[mw-1:0] = mmmmmmmsum0[mw-1:0]; 3'd1 : A[mw-1:0] = mmmmmmmsum1[mw-1:0]; 3'd2 : A[mw-1:0] = mmmmmmmsum2[mw-1:0]; endcase // /* синтез ise9.2 + Gentoo2007.0, 64bit */ /* железка работает */
  12. Не синтезируется ISE'й конструкция вида always @ (*) в среде линукса. Одинаково ведут себя ISE8.2i и ISE9.2i В винде синтезируется нормально. Тестовый пример: module test(a,b,c,d,e,f); input wire [2:0]b; input wire a,d,e,f; output reg c; always @(*) case( b ) 1: c = d; 2: c = a; 3: c = e; 4: c = f; endcase endmodule
  13. AT91RM9200 + Linux + Ethernet

    AT91RM9200+Linux2.6.20+самописный сервер+KS8721 => 8.5 МБайт/с в любую сторону на длинных пакетах (TCP).
  14. Цитата(makc @ Nov 15 2006, 20:03) Вы так и не сказали, как называется Ваш файл лицензии. Но называться он должен gig_eth_mac_v8_flexlm.lic. Переименуйте его и положите в G:\Xilinx\coregen\core_licenses\ PS: У меня слеши такие же, все нормально находится. Однако: после перекладывания файла с лицензией в G:\EDK\data\core_licenses\ был получен следующий результат: Name: Gigabit Ethernet MAC Feature: gig_eth_mac_v8 Status: Full - Source Available Expiration date: Does not expire Current host ID: 0558098de232 License type: FLEXlm Built in search paths: C:\.Xilinx\Coregen\CoreLicenses;G:\EDK\data\core_licenses;g:/Xilinx\coregen\core_licenses LM_LICENSE_FILE: C:\flexlm\license.dat FLEXlm license cache locations: G:\EDK\data\core_licenses ...Возможно сей эффект - последствия установки ЕДК... Однако, тему можно закрывать. Хотя и непонятно, где же прописываются пути к лицензионным файлам Ксайлинкс(Built in search paths:)...