Bekijk de volledige versie : Время на роутере WL-520gU идет медленнее
и это ради экономии в 5 долларов при покупке? :)
У вас случаем нет желания сделать свою прошивку для 520gU? 8) И когда она примерно появится?
Ну... Скажем так, устройство уже лежит у меня на столе. :)
Вопрос к владельцам 520гу. Проверьте пожалуйста, не отстают ли у Вас часы на роутере? Достаточно зайти на страницу Status и засечь время. А второй раз зайти туда через минуту. У моего экземпляра по непонятной причине часы отстают примерно на 10 секунд в минуту, будто частота процессора 200 мгц а не 240...
Вопрос к владельцам 520гу. Проверьте пожалуйста, не отстают ли у Вас часы на роутере? Достаточно зайти на страницу Status и засечь время. А второй раз зайти туда через минуту. У моего экземпляра по непонятной причине часы отстают примерно на 10 секунд в минуту, будто частота процессора 200 мгц а не 240...
Есть такое: ровно десять секунд в минуту :(
Есть такое: ровно десять секунд в минуту :(
Опа... А серийный номер можно?
Буду беседовать на эту тему с АСУСом.
Да, что я ещё проверил: залил загрузчик от 520гц и прошивку от неё же. Картина осталась прежней. Т.е. дело в железке.
Т.е. либо процессор другой, либо ... Есть там один "странный" элемент на плате, который что-то меняет в части 520гу или 520гц. Может это что-то и снижает частоту до 200 МГц...
Опа... А серийный номер можно?
SN: 79IMAC100655
Вроде оно.
Угу. У меня 76IMAC101293.
Т.е. июнь и сентябрь.
Посмотрел ещё раз на этот "странный" элемент. Он действительно странный. :) Запаян просто для идентификации, все посадочные площадки на земле, т.е. он там для красоты. Странно это видеть, ибо по наличию ЮСБ разъёма можно всегда определить, что это за девайс.
Посмотрел 520гц - явно выпущен на другой фабрике, хотя плата идентичная. Всё распаяно одинаково... Т.е. разница похоже в процессоре. Но оторвать радиатор не получилось - там какая-то китайская жвачка его держит явно.
Во вторник задам вопрос сами знаете кому. :)
Из новостей про мою прошивку для 520гу. Она есть уже, заводится, но во-первых, кривые часы, а во-вторых, с вай-фай какие-то проблемы. Надо разбираться. Непонятно, удастся ли запустить её, ибо всё таки WiFi драйвер и исходники от 500W, которые используются, староваты. В общем, бум посмотреть...
Да, на 330ге она тоже работает. Часы там идут правильно, но с вай-фай такая же бяка. :(
Spacesoft
03-11-2007, 22:23
В 520 (который самый отстойнег) вливал фирмварь отсюдова:
http://downloads.openwrt.org/whiterussian/0.9/pptp/
Телнетился норм, если пришибить несколько процессов - пускал в вебморду...
В теории - заведется и нa C/U, а поскоку памяти больше - мож и заработает норм.
В 520 (который самый отстойнег) вливал фирмварь отсюдова:
http://downloads.openwrt.org/whiterussian/0.9/pptp/
Телнетился норм, если пришибить несколько процессов - пускал в вебморду...
В теории - заведется и нa C/U, а поскоку памяти больше - мож и заработает норм.
Старый 520г - это порезанный 550ге, с ними всё просто. В новых используется совсем новый процессор.
Гуру, добрые, подскажите, плиз !
Проблема с неправильным ходом часов на WL520GU, в новой прошивке решена (отстают на 10 сек. за 1 мин.), или её невозможно решить ?
Сейчас приходится в кроне корректировать, вызывая 'date'.
Гуру, добрые, подскажите, плиз !
Проблема с неправильным ходом часов на WL520GU, в новой прошивке решена (отстают на 10 сек. за 1 мин.), или её невозможно решить ?
Сейчас приходится в кроне корректировать, вызывая 'date'.
на мой взгляд, самое простое решение - это синхронизация с внешним источник времени, т.е. сервером времени.
на мой взгляд, самое простое решение - это синхронизация с внешним источник времени, т.е. сервером времени.
ИМХО, время должно быть точным, поэтому корректирую каждую минуту, особой нагрузки на систему-это не оказывает, а скрипт такой :
#!/bin/sh
DATE=`date +%m%d%H%M`
date ${DATE}.12 >> /dev/null
crond-встроенный, 12-опытным путём.
Может, всё-таки, кто-нибудь, поможет решить эту проблему. Согласитесь, 10 сек. за минуту-никуда не годится, как и все кривые корректировки.
Попытался через adjtimex (специально скомпилил её вызов), удалось снизить до 5 сек., изменив timex.tick=11000, дальнейшее увеличение вызывает ошибку. Изменение timex.freq, вообще, никакого действия не оказывает. Напрашивается вариант, обойти ограничение (если оно накладывается в юзер-моде, исходника не нашёл) на timex.tick, написав модуль ядра. Buildroot установлен, достаточно его? Вроде, кернеловские заголовки-есть.
Подскажите, спуститесь со своих небес, плиз!
palm,
а может отнести в СЦ?
teddy_bear
11-05-2009, 06:06
Может, всё-таки, кто-нибудь поможет решить эту проблему.
В этой прошивке так:
nvram set clkfreq=200
nvram commit
reboot
В этой прошивке так:
nvram set clkfreq=200
nvram commit
reboot
Большое спасибо за ответ, но в этом случае, ИМХО, процессор будет работать на 200 МГц ?
teddy_bear
11-05-2009, 08:25
palm,
Да. Но по-другому никак. Т.е. это способ, предложенный Олегом (см. здесь (http://code.google.com/p/wl500g/source/browse/trunk/kernel/002-bcm5354.patch)). Можно еще сделать изменение в исходниках, и только занижать богомипсы до 200, не трогая clkfreq (использовать другую nvram variable - такой способ применен в dd-wrt и Tomato, и в оригинальной прошивке для 520gu от Asus) - но по сути это примерно одно и то же...
palm,
Да. Но по-другому никак. Т.е. это способ, предложенный Олегом (см. здесь (http://code.google.com/p/wl500g/source/browse/trunk/kernel/002-bcm5354.patch)). Можно еще сделать изменение в исходниках, и только занижать богомипсы до 200, не трогая clkfreq (использовать другую nvram variable - такой способ применен в dd-wrt и Tomato, и в оригинальной прошивке для 520gu от Asus) - но по сути это примерно одно и то же...
Установил-таки переменную ядра tick = 12000 через модуль, теперь часы идут правильно.
P.S. Правда, попутно, пришлось собрать прошивку ;)
teddy_bear
15-05-2009, 08:58
Установил-таки переменную ядра tick = 12000 через модуль, теперь часы идут правильно.
Can you elaborate a bit on what exactly you did? Is it a better fix than this one (http://svn.dd-wrt.com:8000/dd-wrt/changeset/10989)? What does "cat /proc/cpuinfo" show after the change - what BogoMIPS value?
Thanks!
Can you elaborate a bit on what exactly you did? Is it a better fix than this one (http://svn.dd-wrt.com:8000/dd-wrt/changeset/10989)? What does "cat /proc/cpuinfo" show after the change - what BogoMIPS value?
Thanks!
BogoMIPS=238.38, не изменяется. Лучше этот способ, или нет, не знаю. Но это-тоже способ, и его можно использовать без перепрошивки роутера. А вообще, ИМХО, всё это-косметика, надо с таймером разбираться.
P.S. Может, не совсем правильно понял вопрос. Если можно, то по-русски.
theMIROn
15-05-2009, 15:44
BogoMIPS=238.38, не изменяется. Лучше этот способ, или нет, не знаю. Но это-тоже способ, и его можно использовать без перепрошивки роутера. А вообще, ИМХО, всё это-косметика, надо с таймером разбираться.
P.S. Может, не совсем правильно понял вопрос. Если можно, то по-русски.
что и где конкретно было изменено. diff -BurpN приветствуется
что и где конкретно было изменено. diff -BurpN приветствуется
Так, я, ничего в прошивке не менял. Конкретно:
Собрал 10-ку Олега (тулчейн ASUS+uсlibc Олега), получил исходный код ядра, для компиляции модуля + System.map, для определения адреса tick, т.к. из прошивки не экспортируется. Сравнил /proc/ksyms c System.map, адреса совпадают, значит ядро скомпилино 1 в 1. Взял адрес tick из System.map, скомпилил модуль ядра, код тривиальный, главное:
long * ptick = (long *)0x801F68B0;
*ptick = 12000; //default 10000
insmod, rmmod - всё, date показывает, что часы идут правильно.
theMIROn
16-05-2009, 10:45
Так, я, ничего в прошивке не менял. Конкретно:
Собрал 10-ку Олега (тулчейн ASUS+uсlibc Олега), получил исходный код ядра, для компиляции модуля + System.map, для определения адреса tick, т.к. из прошивки не экспортируется. Сравнил /proc/ksyms c System.map, адреса совпадают, значит ядро скомпилино 1 в 1. Взял адрес tick из System.map, скомпилил модуль ядра, код тривиальный, главное:
long * ptick = (long *)0x801F68B0;
*ptick = 12000; //default 10000
insmod, rmmod - всё, date показывает, что часы идут правильно.
как насчет работы samba/usb устройств, как напрямую, так и через хабы.
могут быть зависимости
p.s в 520gU/gC PLL зафиксирован на 200Mhz, быстрее оно работать в любом случае не должно.
p.s в 520gU/gC PLL зафиксирован на 200Mhz, быстрее оно работать в любом случае не должно.
Где-то у Олега пробегало, что есть версии с большей частотой...
как насчет работы samba/usb устройств, как напрямую, так и через хабы.
могут быть зависимости
p.s в 520gU/gC PLL зафиксирован на 200Mhz, быстрее оно работать в любом случае не должно.
Насколько, я, понял из своих изысканий, изменение tick-стандартный механизм корректировки часов через вызов adjtimex. Переменная, содержит время в микросекундах, которое, как-бы проходит между 2-мя прерываниями таймера. Часть ПО, использует её, для интерпритации интервала времени, а часть, системную частоту, например, ntp-клиент, всё-равно, вызывается через 2ч. 20мин., вместо 2ч., а date,crond-работают правильно. В целом роутер, как работал, так и работает, ни быстрее, не медленнее, только, что время правильно показывает.
Пляски с бубном, вокруг таймера и исходников, привели к тому, что на WL520GU ( или в какой-то его партии ), ИМХО, процессор работает на частоте 200 МГц, увеличение clkfreq до 240, вызывает, только, неправильную работу таймера ( 83.3 Гц, вместо 100 ). И, как следствие, завышенное показание BogoMIPS в 1.2 раза. Т.е. реальный BogoMIPS ~ 200.
С чем, это может быть связано :confused:
Grishanenko
01-06-2009, 17:03
palm,
Да. Но по-другому никак. Т.е. это способ, предложенный Олегом (см. здесь (http://code.google.com/p/wl500g/source/browse/trunk/kernel/002-bcm5354.patch)). Можно еще сделать изменение в исходниках, и только занижать богомипсы до 200, не трогая clkfreq (использовать другую nvram variable - такой способ применен в dd-wrt и Tomato, и в оригинальной прошивке для 520gu от Asus) - но по сути это примерно одно и то же...
Установил-таки переменную ядра tick = 12000 через модуль, теперь часы идут правильно.
BogoMIPS=238.38, не изменяется. Лучше этот способ, или нет, не знаю. Но это-тоже способ, и его можно использовать без перепрошивки роутера. А вообще, ИМХО, всё это-косметика, надо с таймером разбираться.
А можно ссылочку на пошаговую инструкцию? Мой 520gu тоже страдает проблемой отставания часов. Хотя проще было бы выложить патченную версию прошивки под этот случай.
А можно ссылочку на пошаговую инструкцию? Мой 520gu тоже страдает проблемой отставания часов. Хотя проще было бы выложить патченную версию прошивки под этот случай.
nvram set clkfreq=200
nvram commit
reboot
Больше ничего не сделать :(
Не даёт покоя, что 520gu, работает на частоте 200 МГц, вместо 240. В то же время, судя по постам, на 500gpv2 этого нет, а процессор такой же. По официальным исходникам, процессоры инициализируются одинаково, кварцы тоже, вроде, по 25 МГц. Шаманство с таймингами SDRAM, привело к 16 ноге флэш ( слава богу, пациент ещё жив :D ). Просьба к владельцам WL-500gpv2, поделитесь своим cpuinfo. Снять, в прошивке Олега, можно так:
cat /proc/cpuinfo > /opt/cpuinfo
Не даёт покоя, что 520gu, работает на частоте 200 МГц, вместо 240. В то же время, судя по постам, на 500gpv2 этого нет, а процессор такой же. По официальным исходникам, процессоры инициализируются одинаково, кварцы тоже, вроде, по 25 МГц. Шаманство с таймингами SDRAM, привело к 16 ноге флэш ( слава богу, пациент ещё жив :D ). Просьба к владельцам WL-500gpv2, поделитесь своим cpuinfo. Снять, в прошивке Олега, можно так:
cat /proc/cpuinfo > /opt/cpuinfo
# cat /proc/cpuinfo
system type : Broadcom BCM5354 chip rev 2
processor : 0
cpu model : BCM3302 V2.9
BogoMIPS : 237.56
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
unaligned_instructions : 15
dcache hits : 0
dcache misses : 0
icache hits : 0
icache misses : 0
instructions : 0
# cat /proc/cpuinfo
system type : Broadcom BCM5354 chip rev 2
processor : 0
cpu model : BCM3302 V2.9
BogoMIPS : 237.56
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
unaligned_instructions : 15
dcache hits : 0
dcache misses : 0
icache hits : 0
icache misses : 0
instructions : 0
Спасибо, у меня тоже самое, кроме BogoMIPS. Похоже, всё-таки, это из-за SDRAM. Кстати, на плате разведена А12. Попробую перепаять на более большую и быструю. Если срастётся, выигрыш будет ощутимым, ИМХО.
P.S. В итоге должен получить, что-то вроде DIR-320 :)
Не знаю, что происходит с моим роутером. Давно заметил, что он никогда не показывает точно текущее время. Постоянно отставание на 5-15 минут. А теперь вот что выяснил:
Дал команду date и спустя ровно 1 минуту запустил date еще раз. Так вот роутер показал разницу во времени лишь 50 секунд!
Таким образом за час реального времени на роутере проходит всего 50 минут. Благодаря синхронизации времени каждый час сильно большого расхождения во времени не происходит, но все же.
Кто может подсказать, что это может быть? Почему в роутере время медленнее идет???
P.S.
Роутер у меня Asus 520gu, прошивка 1.9.2.7-d-r1000.
синхронизация времени включена ?
синхронизация времени включена ?Написано же:
Благодаря синхронизации времени каждый час сильно большого расхождения во времени не происходит
эта фича такая --- см. напр. http://wl500g.info/showpost.php?p=147590&postcount=460
И вообще, поищите по нику palm --- он эту проблему изучал.
А заодно покажите
nvram get clkfreq
и
cat /proc/cpuinfo
Вот:
nvram get clkfreq
200
cat /proc/cpuinfo
system type : Broadcom BCM5354 chip rev 2 pkg 0
processor : 0
cpu model : BCM3302 V2.9
BogoMIPS : 237.56
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented : mips16
VCED exceptions : not available
VCEI exceptions : not available
unaligned_instructions : 22
dcache hits : 0
dcache misses : 0
icache hits : 0
icache misses : 0
instructions : 0
Как я понимаю, мне нужно сделать чтобы CPU Frequency и clock frequency были одинаковыми? Т.е. достаточно выполнить команды:
nvram set clkfreq=240
nvram commit
reboot
Правильно я понимаю?
темное дело (я ожидал увидеть обратную картину). Не могу уверенно сказать как правильно.
Пробовать можно, но нужно морально подготовиться к тому, что если не угадать clkfreq, то девайс может и не запуститься, тогда придется осваивать консоль или сброс nvram
Выполнил команды:
nvram set clkfreq=200
nvram commit
reboot
После перезагрузки часы на роутере стали ходить отлично, без отставаний.
По команде cat /proc/cpuinfo параметр BogoMIPS стал равен 198.24 (раньше было 237.56). Это, как я понимаю, означает, что роутер стал работать на меньшей частоте и соответственно медленней.
не факт. Насколько я помню частота у него зафиксирована на 200МГц, возможно, просто богомипсы неправильно отображаются.
http://wl500g.info/showpost.php?p=147201&postcount=455
Можно попробовать потестировать в приложениях. Разница в 16% должна быть заметна, если она есть.
theMIROn
04-02-2010, 08:20
PLL у него залочен (был во всяком случае) на 200Mhz.
Поэтому, нужно и частоту clkfreq выставлять тоже в 200, иначе неверно работает таймер, привязанный к частоте. Он то думает, что срабатывает часто, а на самом деле срабатывает медленнее, поэтому время отстает.
Если не верите - тестите производительность с помошью nbench
ipkg install nbench-byte
nbench
а почему она автоматом в нашей прошивке не выставляется? Этот факт известен вроде уже давно.
theMIROn
04-02-2010, 10:47
а почему она автоматом в нашей прошивке не выставляется? Этот факт известен вроде уже давно.
нну, эээ, чтобы не создавать прецедентов, что gu с такой прошивкой работает медленнее, чем чем с другой/предыдущей.
смотреть то будут по богомипсам, а на убегание времени многие вообще не обращают внимания.
маркетинг, однако ;)
McMaster
16-05-2010, 16:57
на 1445 прошивке переодически слетают настройки, если выключить роутер и примерно через пол часа, час, включить - роутер голый.
на предыдущей прошивке всё было нормально
ну ещё часы сильно отстают
правки Олега для хода часов на 520gU были всегда и никто их не удалял.
т.е. отставание часов на 520gU не вылечить никак?
McMaster
17-05-2010, 08:31
На своём подопытном 520gU подобной проблемы на замечал,
сброс настроек не всегда происходит, не знаю от чего зависит
т.е. отставание часов на 520gU не вылечить никак?
Выставьте "1" в:
IP Config - Miscellaneous - NTP synchronization interval
Выставьте "1" в:
IP Config - Miscellaneous - NTP synchronization interval
Если в оригинальной 10.7 часы также убегают - надо проверять nvram и, возможно, сбрасывать в дефалт.
Если в оригинальной 10.7 часы также убегают - надо проверять nvram и, возможно, сбрасывать в дефалт.
В оригинальной 10.7 часы отстают и в 1.9.2.7-d тоже отстают. Может кто-нибудь глянуть nvram и, возможно, подправить в нужных местах?
В оригинальной 10.7 часы отстают и в 1.9.2.7-d тоже отстают. Может кто-нибудь глянуть nvram и, возможно, подправить в нужных местах?
Поиск придумали трусы?
P.S. Oszau это и к тебе относится.
Поиск придумали трусы?
Дайте ссылку где искать, у меня так и не получилось найти нужную информацию.
Нашел - nvram set clkfreq=200
Это единственный вариант с изменением параметра PLL с 238.38 на 198.24 или это не влияет на быстродействие и производительность?
Вопрос такой - насколько проблематично включить в прошивке CONFIG_MAGIC_SYSRQ? Штука, IMHO, полезная, чтобы удаленно перезагружать роутер с зомби-процессами. Я попробовал сходу добавить CONFIG_MAGIC_SYSRQ=у в .config, но нужные файл в /proc так и не появились. Возможно, я что-то делаю не так?
Нашел - nvram set clkfreq=200
Это единственный вариант с изменением параметра PLL с 238.38 на 198.24 или это не влияет на быстродействие и производительность?
Альтернативой являются глубокие разборки с новыми моделями 520gU (у меня старая, для которой и работает фикс от Олега), чтобы откорректировать константы ядра. Какое значение clkfreq по умолчанию? С родной прошивкой от ASUS часы ходят нормально?
Вопрос такой - насколько проблематично включить в прошивке CONFIG_MAGIC_SYSRQ? Штука, IMHO, полезная, чтобы удаленно перезагружать роутер с зомби-процессами.
Это абсолютно не нужно и, иногда, приводит к ложному срабатыванию sysrq при мусоре с консоли. /sbin/reboot является линком на rc, который должен корректно завершать процессы, невзирая на zombie. Скорее всего, у тебя дикая каша с optware-uClibc, bash, и т.п.
Для разборок нужен воспроизводимый тестовый пример.
Это абсолютно не нужно и, иногда, приводит к ложному срабатыванию sysrq при мусоре с консоли. /sbin/reboot является линком на rc, который должен корректно завершать процессы, невзирая на zombie. Скорее всего, у тебя дикая каша с optware-uClibc, bash, и т.п.
Нет, конкретно у меня проблема в том, что reboot зависает по причине "отвалившейся" флешки с /opt. Все процессы с диска зависают в состоянии Z, видимо, по I/O. Роутер остается доступен по telnet, но перезагрузить его можно только передергиванием питания. Простой вызов `echo b > /proc/sysrq-trigger` помог бы в этом случае. Я думаю, не один я сталкиваюсь с подобной проблемой...
Для разборок нужен воспроизводимый тестовый пример.Наверное, можно попробовать просто выдернуть флешку и попробовать перезагрузить роутер.
P.S. А откуда может взяться мусор в консоли? Она же по дефолту, AFAIR, никуда не подключена, а сигнальные линии ее наверняка притянуты к земле или питанию...
Нет, конкретно у меня проблема в том, что reboot зависает по причине "отвалившейся" флешки с /opt.
Надо лечить причину, а не следствие...
P.S. А откуда может взяться мусор в консоли? Она же по дефолту, AFAIR, никуда не подключена, а сигнальные линии ее наверняка притянуты к земле или питанию...
Если подключен глючный преобразователь типа pl2303, то бывает - лично наблюдал.
Надо лечить причину, а не следствие...Причина обычно в том, что кто-то накануне вытирал с железок пыль и задел провод. Вариант перестать убираться в квартире мне не очень нравится. :)
Если подключен глючный преобразователь типа pl2303, то бывает - лично наблюдал.Ну проблему глючного преобразователя можно решить отключением sysrq при загрузке через /proc/sys/kernel/sysrq (хотя и тут, IMHO, лучше было бы решать проблему, а не следствие).
Ну ладно, нет - так нет, покопаюсь самостоятельно на досуге.
Альтернативой являются глубокие разборки с новыми моделями 520gU (у меня старая, для которой и работает фикс от Олега), чтобы откорректировать константы ядра. Какое значение clkfreq по умолчанию? С родной прошивкой от ASUS часы ходят нормально?
Значение clkfreq по умолчанию 240. Изменил его на 200 и часы стали ходить точно! Значит у меня старая модель 520gU?
Значение clkfreq по умолчанию 240. Изменил его на 200 и часы стали ходить точно! Значит у меня старая модель 520gU?
Может кто-то (возможно и ты сам) пытался разогнать роутер? Вряд ли стали делать 520gU с 240MHz...
Для уверенности можно вернуть 240, поставить фирменную прошивку от ASUS'а и посмотреть что будет с часами.
Может кто-то (возможно и ты сам) пытался разогнать роутер? Вряд ли стали делать 520gU с 240MHz...
Для уверенности можно вернуть 240, поставить фирменную прошивку от ASUS'а и посмотреть что будет с часами.
Роутер покупался новым и запакованным с родной прошивкой асуса. Потом я обновил прошивку до 2.0.1.0 официальной. С часами все было ОК. Затем прошился 1.9.2.7-d прошивкой и сразу заметил проблему с часами. Посмотрел clkfreq=240, изменил его на 200 и проблема с часами решилась.
Unlimited
18-05-2010, 19:37
Может кто-то (возможно и ты сам) пытался разогнать роутер? Вряд ли стали делать 520gU с 240MHz...
Для уверенности можно вернуть 240, поставить фирменную прошивку от ASUS'а и посмотреть что будет с часами.
Вот Wl-520gU у моей сестры...
Jan 1 03:00:02 kernel: CPU: BCM5354 rev 2 pkg 0 at 240 MHz
Jan 1 03:00:02 kernel: Using 120.000 MHz high precision timer.
Jan 1 03:00:02 kernel: Calibrating delay loop... 237.56 BogoMIPS
Время ходит нормально.
Вот Wl-520gU у моей сестры...
Время ходит нормально.
Прошивка то какая?
Unlimited
18-05-2010, 19:44
Прошивка то какая?
Как бы последняя :) d-r1565. Я конечно никогда не следил за ним, но вот утром эту прошивку налил, сейчас посмотрел время на нем - все окей.
Вот Wl-520gU у моей сестры...
Jan 1 03:00:02 kernel: CPU: BCM5354 rev 2 pkg 0 at 240 MHz
Jan 1 03:00:02 kernel: Using 120.000 MHz high precision timer.
Jan 1 03:00:02 kernel: Calibrating delay loop... 237.56 BogoMIPS
Время ходит нормально.
У меня ходит нормально при таких условиях:
Jan 1 03:00:03 kernel: CPU: BCM5354 rev 2 pkg 0 at 200 MHz
Jan 1 03:00:03 kernel: Using 100.000 MHz high precision timer.
Jan 1 03:00:03 kernel: Calibrating delay loop... 197.83 BogoMIPS
Изначально было так (часы отставали):
Jan 1 03:00:02 kernel: CPU: BCM5354 rev 2 pkg 0 at 240 MHz
Jan 1 03:00:02 kernel: Using 100.000 MHz high precision timer.
Jan 1 03:00:02 kernel: Calibrating delay loop... 237.56 BogoMIPS
Вопрос: как изменить параметр Using 100.000 MHz на 120 как у Вас?
Виктор89
18-05-2010, 20:10
Вот Wl-520gU у моей сестры...
Jan 1 03:00:02 kernel: CPU: BCM5354 rev 2 pkg 0 at 240 MHz
Jan 1 03:00:02 kernel: Using 120.000 MHz high precision timer.
Jan 1 03:00:02 kernel: Calibrating delay loop... 237.56 BogoMIPS
Время ходит нормально.
В моем GU отстает постоянно :(
May 18 18:38:22 ntp client: Synchronizing time with time.nist.gov ...
May 18 18:50:26 pptp[476]: System time change detected.
Возможно потому что ревизии процов разные. У меня третья.
Jan 1 03:00:02 kernel: CPU: BCM5354 rev 3 pkg 0 at 240 MHz
Jan 1 03:00:02 kernel: Using 120.000 MHz high precision timer.
Jan 1 03:00:02 kernel: Calibrating delay loop... 237.56 BogoMIPS
В моем GU отстает постоянно :(
А с родной прошивкой?
Возможно потому что ревизии процов разные. У меня третья.
В родных прошивках, вплоть до версии 3.0.0.3, первая цифра (240MHz) тупо забита константой в Broadcom SDK т.к. нет никакой возможности программно определить залоченную скорость PLL. Вторая (120.000 MHz high precision timer) должна вычисляться в зависимости от модели - 120 для 500gPV2 и 100 для 520gU (точно для ревизий 0,1,2). С третьей похоже никто не разбирался.
Сейчас попробую скачать GPL 520gU 3.0.1.4, посмотреть как там обстоят дела.
Updated: посмотрел - для 520gU тупо забита константа 100.000 (для тех кто хочет разобраться - rate = 200000000 в sb_cpu_clock()). Т.е. правильный вариант clkfreq=200
Unlimited
19-05-2010, 07:54
А с родной прошивкой?
В родных прошивках, вплоть до версии 3.0.0.3, первая цифра (240MHz) тупо забита константой в Broadcom SDK т.к. нет никакой возможности программно определить залоченную скорость PLL. Вторая (120.000 MHz high precision timer) должна вычисляться в зависимости от модели - 120 для 500gPV2 и 100 для 520gU (точно для ревизий 0,1,2). С третьей похоже никто не разбирался.
Сейчас попробую скачать GPL 520gU 3.0.1.4, посмотреть как там обстоят дела.
WL-520gU: На прошивке 1583, сообщения в логе о CPU и таймере пропали, за пол часа часы отстали на 6 минут.
UPD Странно откатил на r1565, но сообщения о таймере в логе не появились :) Посмотрю как часы себя поведут..
WL-520gU: На прошивке 1583, сообщения в логе о CPU и таймере пропали, за пол часа часы отстали на 6 минут.
UPD Странно откатил на r1565, но сообщения о таймере в логе не появились :) Посмотрю как часы себя поведут..
Эта(520gU workaround - см. kernel/002-bcm5354.patch) часть не менялась очень давно, полный лог ядра гарантированно пока только через dmesg.
Unlimited
19-05-2010, 09:28
Эта(520gU workaround - см. kernel/002-bcm5354.patch) часть не менялась очень давно, полный лог ядра гарантированно пока только через dmesg.
Посмотрел, там все тоже самое. Но теперь время отстает :) Значит или я ошибся тогда когда смотрел или оно не всегда отстает а от чего-то зависит :)
Blade131
20-05-2010, 18:05
Всем доброго времени суток. Немного почитав данную ветку форума я чувствую что постоянно ставлю не те версии прошивки...
WL520gu-1.9.2.7-d-r1445 на данный момент... Кажется явно нето)
Если я прав прошу ткнуть носом в нужную ссылочку)
Виктор89
20-05-2010, 18:41
Речь идет про ночные сборки (ftp://core.dumped.ru/wl/) с свн.
У самого такое же устройство, обновляюсь регулярно, зависимости никакой :)