LINUX.ORG.RU

Devtmpfs - новое решение для заполнения /dev

 , ,


0

0

Kay Sievers послал в LKML патч, реализующий создание tmpfs на ранней стадии инициализации ядра и динамическое заполнение получившейся файловой системы. После монтирования корневой файловой системы, этот экземпляр tmpfs перемонтируется ядром в каталог /dev. Таким образом, "init=/bin/sh" работает без каких-либо статических устройств и вспомогательных программ. Все устройства имеют по умолчанию владельца root, группу root и права 0600, но эти параметры можно изменить (например, с помощью chown, chmod или udev).

Нововведение рассчитано в первую очередь на рынок мобильных устройств, где с целью экономии ресурсов производители избегают использования udev. Однако, udev и devtmpfs друг другу не мешают.

Реакция других разработчиков:

Andrew Morton: "Lol, devfs"

Greg KH: "да, devfs, но сделанная как надо"

Alan Cox: "это убирает проблему из userspace, но добавляет ее в ядро, да так, что ее не выкинуть в swap"

>>> Подробности

Ответ на: комментарий от tailgunner

>Эмбедщики всё осилили.

Тогда к чему сопли?

Macil ★★★★★
()
Ответ на: комментарий от Macil

>>initrd или в initramfs базовые dev устройства типа zero, null, console

>Какие-то проблемы?

Да вобщем то никаких. Зачем тогда вообще какой то менеджмент в /dev? Напихаем как раньше было девайсов на все случаи жизни, и все дела :]

vasily_pupkin ★★★★★
()
Ответ на: комментарий от isden

> а для devfs нужен был демон если мне память не изменяет.

В FreeBSD нету udev, и руками файлы устройств в devfs давно уже создавать не надо.
Для devfs запускается демон devd с собственным файлом конфигурации devd.conf. Демон имеет настройки, описываемые в devd.conf, для обработки событий от подсоединения/отсоединения реальных и виртуальных устройств.
http://www.freebsd.org/cgi/man.cgi?query=devd.conf&apropos=0&sektion=...
В принципе, DEVd может заменить HALd.

iZEN ★★★★★
()
Ответ на: комментарий от Macil

>Достали т.н. "эмбендщики", учитывая тот факт что по-настоящему встраиваемых систем осталось мало и львиная их доля под линуксом не работает.

Как и предполагалось человек мало знаком с областью. linux часто отпугивает своей лицензией всего лишь - нужно открывать исходники, soc применяют часто не для того чтобы все в одном удобно а потому что масочное пзу таких устройств делают секьюрным - практически невозможно прочитать прошивку с них электронным микроскопом чего не скажешь о внешних носителях информации.

>Ну хватит, блин сувать в ядро, что сувать не должно.


Ядро должно содержать то что должно быть там.

monika
()
Ответ на: комментарий от Macil

>Уровень initrd призван подготовить запуск init, и включение чего-то в ядро ИМХО мало поможет.

Многие системы дальше initrd/initramfs ничего и не грузят так как это и есть их основная корневая система, правда busybox/mdev там вполне справляется со всеми задачами. Но опять же ты противоречишь сам себе - тебе нужен единый механизм и тут же предлагаешь плодить юзерспейсных агентов. Кроме как перекладывание этой задачи на ядро единства не достичь.

monika
()
Ответ на: комментарий от isden

Потому что было/есть кому поддерживать эту инфраструктуру. В итоге она эволюционировала во вполне приличную динамическую подсистему.

iZEN ★★★★★
()
Ответ на: комментарий от tailgunner

>Эмбедщики всё осилили. В busybox входит mdev, в более "толстых" системах может использоваться обычный udev (в составе минимальной инсталляции Дебиана, к примеру).

Подскажите, а зачем в эмбедид системах udev?
Как-то никогда не сталкивался с этой необходимостью. Как правило десятка или пары десятков устройств в /dev/ вполне достаточно. Этож не PC.
Тогда зачем усложнять систему и увеличивать время старта?

Dead ★★★★
()
Ответ на: комментарий от Dead

>Подскажите, а зачем в эмбедид системах udev?
>Как правило десятка или пары десятков устройств в /dev/ вполне достаточно.


Подскажи - как ты поступаешь с устройствами для которых ядро назначает major/minor динамически ?

monika
()
Ответ на: комментарий от monika

>Как правило десятка или пары десятков устройств в /dev/ вполне достаточно.

Еще пример - mtd со статическими файлами в /dev - после копирования через cp на spi флеш некоего имиджа файл устройства вдруг превращается в обычный файл и после перезагрузки таким и остается ?

monika
()

Теперь и в /dev можно срать камментами...

gharik
()
Ответ на: комментарий от Dead

> Подскажите, а зачем в эмбедид системах udev?

Да затем же, что и в обычных. И так же, как в обычных, без него можно обойтись при желании. Только зачем?

> Тогда зачем усложнять систему

Что значит "усложнять"? Механизм hotplug входит в ядро, отлажен и готов к использованию.

> и увеличивать время старта?

Ну и сколько процентов во времени старта занимает udev/mdev?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Ну и сколько процентов во времени старта занимает udev/mdev?

Есть мнение, что ручной сборки эмбеддед загружается за доли секунды (плюс время на выкачку образа системы с бут-сервира).

В принципе если всё шибко критично - есть старый-добрый hotplug, он "быстрее" удава, но опять же - целевые характеристики системы лучше знать, чем не знать.

gharik
()
Ответ на: комментарий от monika

>тебе нужен единый механизм и тут же предлагаешь плодить юзерспейсных агентов.

Плодить юзерспейсных агентов - очень просто. Т.к. это юзерспейс. Добавлять в ядро новый функционал сложно. Ядро у нас монолитное.

Единый - не значит один для всех. Единый - значит один в данный момент времени, и без всяких предположений о каих-то других механизмах. Если вдруг нужен тебе udev на уровне initrd - значит делай его на уровне initrd, а уже потом уж монтируй рут и запускай "штатный". В противном случае тебе придется разбираться с тем, что один механизм от другого ожидает.

Собственно что предлагают аффторы devtmpfs? Они предлагают "ядерными" средствами заполнить /dev, а потом уже пускать udev. Все нормально, вот только другой системе udev, mdev, или еще какой придется с этим механизмом _взаимодействовать_. А зачем нем еще одна связь ядро-юзерспейс?

Macil ★★★★★
()
Ответ на: комментарий от Macil

самое невеселое в текущем состоянии дел на десктопах, так это то, что в системе висит udev+hal, а собственно оба делают одно и тоже.

Если бы сделали решение, убирающее оба пункта, то это было бы интересно. А так, шило на мыло, по-мойму.

mrdeath ★★★★★
()
Ответ на: комментарий от monika

>Многие системы дальше initrd/initramfs

Подразумевается, что содержимое initrd херится. Но это заморочки конкретной системы.

Вообще, нужно разделять два очень важных процесса: процесс начального наполнения /dev и обработка событий о подключении "горячих" устройств.

И если первую часть может быть и можно переложить на ядро, то вот второй - без сообщений юзерспейсу и выполнения каких-то действий юзерспейсом сложно организовать. Даже для "настоящих" встраиваемых систем.

Macil ★★★★★
()
Ответ на: комментарий от mrdeath

>Если бы сделали решение, убирающее оба пункта, то это было бы интересно.

А сабж добавляет еще один пункт - ядро. Здорово, да?

Macil ★★★★★
()
Ответ на: комментарий от Macil

ну я же говорю, шило на мыло. :) А в самом деле, почему нельзя создавать устройство в /dev при загрузке модуля? необходимость в каком-то дополнительном xxxfs отпадает автоматом.

mrdeath ★★★★★
()
Ответ на: комментарий от Macil

>А сабж добавляет еще один пункт - ядро. Здорово, да?

Ты только забываешь про то что ядро там всегда присутствует :) Если посмотреть на типичный пример с mdev из документации busybox:

Here's a typical code snippet from the init script:
[0] mount -t proc proc /proc
[1] mount -t sysfs sysfs /sys
[2] echo /bin/mdev > /proc/sys/kernel/hotplug
[3] mdev -s

Alternatively, without procfs the above becomes:
[1] mount -t sysfs sysfs /sys
[2] sysctl -w kernel.hotplug=/bin/mdev
[3] mdev -s


Of course, a more "full" setup would entail executing this before the previous
code snippet: агентом
[4] mount -t tmpfs -o size=64k,mode=0755 tmpfs /dev
[5] mkdir /dev/pts
[6] mount -t devpts devpts /dev/pts

Заполнением занимаются 4,5,6,3 - все упрощается до обработки
подключений hotplug - но это и так было раньше. При этом тебе не нужны лишние сущности для полноценного старта без монтирования /proc и /sys да и hotplug-агентом ты сам себя можешь прописать если тебе это вообще нужно.

monika
()

>Alan Cox: "это убирает проблему из userspace, но добавляет ее в ядро, да так, что ее не выкинуть в swap"

Ага, им бы лишь бы выпихнуть проблему из ядра и вынести в юзерспейс. Ачо, пусть пользователи сами трахаются как хотят, а мы тут ядро разрабатываем, это не наши проблемы.

devfs надо было переписывать сразу. Быстро, решительно. А не городить огород с udev. Алсо, желаю udev'у быстрой и лёгкой смерти.

env ★★☆
()
Ответ на: комментарий от mrdeath

>ну я же говорю, шило на мыло. :) А в самом деле, почему нельзя создавать устройство в /dev при загрузке модуля? необходимость в каком-то дополнительном xxxfs отпадает автоматом.

А если модуль уже загружен, а устройство втыкается-вытыкается в процессе работы?

env ★★☆
()
Ответ на: комментарий от env

ну, _init и _stop функциии то запускаются не по загрузке, а по включению/выключению устройства. Там же можно и девайс добавлять/удалять. хз, может быть я что-то упускаю из виду.

mrdeath ★★★★★
()
Ответ на: комментарий от Alan_Steel

"When this option is enabled the VFAT filesystem will refuse to create new files with long names. Accessing existing files with long names will continue to work.

File names to be created must conform to the 8.3 format. Mixed case is not allowed in either the prefix or the suffix."

http://lkml.org/lkml/2009/5/1/280

Веселуха ))

wyldrodney
()
Ответ на: комментарий от mrdeath

>в системе висит udev+hal, а собственно оба делают одно и тоже.
http://fedoraproject.org/wiki/Features/DeviceKit
"The new udev-extra module will provide udev rules that are needed to make the DeviceKit architecture work. Functionality that was provided via .fdi files in hal will eventually be moved to udev rules, and setting acls on devices will also be done here at some point. "

Deleted
()
Ответ на: комментарий от tailgunner

>Ну и сколько процентов во времени старта занимает udev/mdev?

Например, на ееепц где-то 80%, остальные 19 это монтирование фс

madcore ★★★★★
()
Ответ на: комментарий от tailgunner

ну, всегда можно проверять, и если его нет, то создавать.

mrdeath ★★★★★
()

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

Deleted
()
Ответ на: комментарий от Deleted

> Почему в каждой теме, как-то связанной с ядром, выползает куча безмозглых уродов, и все они начинают высирать своё единственно правильное авторитетное мнение?

Ну, ты эе знаешь, что по стародавней русской традиции можно: решенить все общемирновые проблемы, выиграть все спортивные матчи и выработать способо затащить в постель всех мало-мальских симпатичных женщин, сидя на кухне с граненым стаканом с водкой. Только кухня сменилась на ЛОР, а водка на постинг в треды...

no-dashi ★★★★★
()

Очень вовремя.
Как раз имею проблему с udev на шиве (ARM):


May 3 14:25:18 debian kernel: CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053177
May 3 14:25:18 debian kernel: Machine: Feroceon-KW
...
May 3 14:25:19 debian kernel: Marvell Development Board (LSP Version KW_LSP_4.2.7_patch2)-- SHEEVA PLUG Soc: 88F6281 A0 LE
...
May 3 14:25:19 debian kernel: Freeing init memory: 104K
May 3 14:25:29 debian kernel: Internal error: Oops: 5 [#1]
May 3 14:25:29 debian kernel: Modules linked in:
May 3 14:25:29 debian kernel: CPU: 0 Not tainted (2.6.22.18 #1)
May 3 14:25:29 debian kernel: PC is at strnlen+0x20/0x34
May 3 14:25:29 debian kernel: LR is at vsnprintf+0x314/0x5b4
May 3 14:25:29 debian kernel: pc : [<c0240228>] lr : [<c02414f8>] psr: a0000013
May 3 14:25:29 debian kernel: sp : ddeb5dc0 ip : ddeb5dd0 fp : ddeb5dcc
May 3 14:25:29 debian kernel: r10: ffffffff r9 : ffffffff r8 : 00000000
May 3 14:25:29 debian kernel: r7 : ffffffff r6 : ddd2f041 r5 : 32e432f7 r4 : ddeb5e40
May 3 14:25:29 debian kernel: r3 : c00c8994 r2 : 32e432f7 r1 : fffffffe r0 : 32e432f7
May 3 14:25:29 debian kernel: Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user
May 3 14:25:29 debian kernel: Control: 0005317f Table: 1df04000 DAC: 00000015
May 3 14:25:29 debian kernel: Process udevadm (pid: 1363, stack limit = 0xddeb4268)
May 3 14:25:29 debian kernel: Stack: (0xddeb5dc0 to 0xddeb6000)
May 3 14:25:29 debian kernel: 5dc0: ddeb5e1c ddeb5dd0 c02414f8 c0240218 c023db48 ddeb5dec ddeb5dfc ddeb5df0
May 3 14:25:29 debian kernel: 5de0: c027369c 222d0fbe ddd2f041 c00d321a ddeb5e44 00000014 000May 3 14:25:29 debian kernel: 5e00: ddd2f000 c03ed298 00000000 c03fc7a4 ddeb5e38 ddeb5e20 c0241864 c02411f4
May 3 14:25:29 debian kernel: 5e20: c03ed240 ddeb5e40 ddd2f000 ddeb5eec ddeb5e48 c026ef10 c024184c c00d3219
May 3 14:25:29 debian kernel: 5e40: 32e432f7 32e432f7 ddeb0000 00001000 ddeb0000 ddeb000c ddeb0020 ddeb0033
May 3 14:25:29 debian kernel: 5e60: 32e432f7 00000044 000280d0 c03f1574 00000000 00000000 ffffff9c c03f1574
May 3 14:25:29 debian kernel: 5e80: c08927e8 000080d0 c03f1570 ddd8b820 00000000 00000000 ddeb5eec ddeb5ea8
May 3 14:25:29 debian kernel: 5ea0: c01472ec c0146724 000280d0 00000010 c07e75e0 ddeb4000 40020000 4001f000
May 3 14:25:29 debian kernel: 5ec0: 00100073 dde78b60 c08927e8 c03ed240 dde78b60 c08927e8 c03ed240 dde78b80
May 3 14:25:29 debian kernel: 5ee0: ddeb5efc ddeb5ef0 c026e810 c026ee28 ddeb5f44 ddeb5f00 c019ca14 c026e7fc
May 3 14:25:29 debian kernel: 5f00: ddeb5f74 ddeb5f10 c0153c60 ddeb5f70 00001000 4001f000 00000000 ddd62b40
May 3 14:25:29 debian kernel: 5f20: 4001f000 ddeb5f70 00001000 4001f000 ddeb4000 00000000 ddeb5f6c ddeb5f4800041 ddeb0000
May 3 14:25:29 debian kernel: 5f40: c01625e8 c019c964 00000000 00000000 00000000 00000000 ddd62b40 00001000
May 3 14:25:29 debian kernel: 5f60: ddeb5fa4 ddeb5f70 c01629fc c0162540 00000000 00000000 00000022 00000000
May 3 14:25:29 debian kernel: 5f80: ffffffff 2a022d18 2a022d18 000007ff 00000003 c0027628 00000000 ddeb5fa8
May 3 14:25:29 debian kernel: 5fa0: c0027480 c01629c8 2a022d18 2a022d18 00000007 4001f000 00001000 00000000
May 3 14:25:29 debian kernel: 5fc0: 2a022d18 2a022d18 000007ff 00000003 be8294cc 0000000a 40180000 be8294cc
May 3 14:25:29 debian kernel: 5fe0: 40171000 be829428 400ac138 400ff7ec 60000010 00000007 00000000 00000000
May 3 14:25:29 debian kernel: Backtrace:
May 3 14:25:29 debian kernel: [<c0240208>] (strnlen+0x0/0x34) from [<c02414f8>] (vsnprintf+0x314/0x5b4)
May 3 14:25:29 debian kernel: [<c02411e4>] (vsnprintf+0x0/0x5b4) from [<c0241864>] (sprintf+0x2c/0x34)
May 3 14:25:29 debian kernel: [<c0241838>] (sprintf+0x0/0x34) from [<c026ef10>] (show_uevent+0xf8/0x140)
May 3 14:25:29 debian kernel: r3:32e432f7 r2:32e432f7 r1:c00d3219
May 3 14:25:29 debian kernel: [<c026ee18>] (show_uevent+0x0/0x140) from [<c026e810>] (dev_attr_show+0x24/0x28)
May 3 14:25:29 debian kernel: r7:dde78b80 r6:c03ed240 r5:c08927e8 r4:dde78b60
May 3 14:25:29 debian kernel: [<c026e7ec>] (dev_attr_show+0x0/0x28) from [<c019ca14>] (sysfs_read_file+0xc0/0x130)
May 3 14:25:29 debian kernel: [<c019c954>] (sysfs_read_file+0x0/0x130) from [<c01625e8>] (vfs_read+0xb8/0x148)
May 3 14:25:29 debian kernel: [<c0162530>] (vfs_read+0x0/0x148) from [<c01629fc>] (sys_read+0x44/0x70)
May 3 14:25:29 debian kernel: r7:00001000 r6:ddd62b40 r5:00000000 r4:00000000
May 3 14:25:29 debian kernel: [<c01629b8>] (sys_read+0x0/0x70) from [<c0027480>] (ret_fast_syscall+0x0/0x2c)
May 3 14:25:29 debian kernel: r8:c0027628 r7:00000003 r6:000007ff r5:2a022d18 r4:2a022d18
May 3 14:25:29 debian kernel: Code: ea000000 e2800001 e2511001 3a000002 (e5d03000)



siberean
()
Ответ на: комментарий от siberean

> Как раз имею проблему с udev на шиве (ARM):

Ты правда думаешь, что новый devtmpfs поможет с этой проблемой? %)

P.S. "Everything that crashes OS is an OS bug" (c) D. Cutler

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

нет, просто больше дополнительного шум^Щвнимания со стороны гур^Щзаконодателей мод в кернеле к проблемам udev в embedded сейчас не помешает.

siberean
()
Ответ на: комментарий от tailgunner

Может JFFS - the actual cause? (я пока не спец в ядерных делах)

jffs2_scan_inode_node(): CRC failed on node at 0x1c951fc8: Read 0xffffffff, calculated 0x144103e7
Empty flash at 0x1c95203c ends at 0x1c952800
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 104K
Unable to handle kernel paging request at virtual address 32e432f7
pgd = ddf04000

P.S. надо будет пересобрать более последнее ядро

siberean
()
Ответ на: комментарий от siberean

> Может JFFS - the actual cause? (я пока не спец в ядерных делах)

> jffs2_scan_inode_node(): CRC failed on node at 0x1c951fc8: Read 0xffffffff, calculated 0x144103e7

Судя по 0xffffffff, это битый флэш (стертый, но не заполненный). К тому же, вверху был другой Oops :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

почему я сказал про udev - как раз давеча сделал его apt-get и это - первая вещь, которая крашнулась (на тесте) на шиве, из того что испробовано (vnc-сервер, NFS и прочие поставились и работают пока как часы. Правда с X-клиентом проблема, но надеюсь - решаемая). Из чего делаю вывод - что удав - самая капризная вещь.

Ещё что я заметил - udev висел минут 5 в первый раз, после apt-get.

siberean
()
Ответ на: комментарий от tailgunner

те несколько строк - прямо перед тем Опсом (он один).

В любом случае - перепрошивка может решить проблему, так что пока не буду ни сам копать, ни отнимать время у других (вшитая система - старьё - с января:).

siberean
()
Ответ на: комментарий от tailgunner

Судя по 0xffffffff, это битый флэш (стертый, но не заполненный). К тому же, вверху был другой Oops :)

да, наверное.
Ещё раньше:



NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 324 at 0x02880000
Bad eraseblock 332 at 0x02980000
Bad eraseblock 340 at 0x02a80000
Bad eraseblock 348 at 0x02b80000
Bad eraseblock 356 at 0x02c80000
Bad eraseblock 364 at 0x02d80000
Bad eraseblock 372 at 0x02e80000
Bad eraseblock 380 at 0x02f80000
Bad eraseblock 2372 at 0x12880000
Bad eraseblock 2380 at 0x12980000
Bad eraseblock 2388 at 0x12a80000
Bad eraseblock 2396 at 0x12b80000
Bad eraseblock 2404 at 0x12c80000
Bad eraseblock 2412 at 0x12d80000
Bad eraseblock 2420 at 0x12e80000
Bad eraseblock 2428 at 0x12f80000
Bad eraseblock 3088 at 0x18200000
Bad eraseblock 3636 at 0x1c680000
Bad eraseblock 3637 at 0x1c6a0000
Bad eraseblock 3644 at 0x1c780000
Bad eraseblock 3645 at 0x1c7a0000
Bad eraseblock 3646 at 0x1c7c0000
Bad eraseblock 3647 at 0x1c7e0000
Bad eraseblock 3648 at 0x1c800000
Bad eraseblock 3684 at 0x1cc80000
2 cmdlinepart partitions found on MTD device nand_mtd
Using command line partition definition
Creating 2 MTD partitions on "nand_mtd":
0x00100000-0x00500000 : "uImage"
0x00500000-0x20000000 : "rootfs"
ehci_marvell ehci_marvell.70059: Marvell Orion EHCI
ehci_marvell ehci_marvell.70059: new USB bus registered, assigned bus number 1
ehci_marvell ehci_marvell.70059: irq 19, io base 0xf1050100
ehci_marvell ehci_marvell.70059: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
USB Universal Host Controller Interface driver v3.0
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
Linux telephony interface: v1.00
Marvell Telephony Driver:
mvBoardVoiceAssembleModeGet: TDM not supported(boardId=0x9)
assembly=-1,irq=-1
mp_check_config: Error, invalid voice assembley mode
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
raid6: int32x1 97 MB/s
raid6: int32x2 114 MB/s
raid6: int32x4 122 MB/s
raid6: int32x8 110 MB/s
raid6: using algorithm int32x4 (122 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: measuring checksumming speed
arm4regs : 1084.000 MB/sec
8regs : 754.800 MB/sec
32regs : 899.600 MB/sec
raid5: using function: arm4regs (1084.000 MB/sec)
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
dm_crypt using the OCF package.
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
mvsdmmc: irq =28 start f1090000
mvsdmmc: no IRQ detect
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
mvCLAudioCodecRegGet: Error while reading register!
mvCLAudioCodecInit: Error - Invalid Cirrus Logic chip/rev ID!
Error - Cannot initialize audio decoder.at address =0xff<6>ALSA device list:
#0: Marvell mv88fx_snd ALSA driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: link down
eth0: started
IP-Config: Complete:
device=eth0, addr=10.4.50.4, mask=255.255.255.0, gw=10.4.50.5,
host=DB88FXX81, domain=, nis-domain=(none),
bootserver=10.4.50.5, rootserver=10.4.50.5, rootpath=
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
eth0: link up, full duplex, speed 100 Mbps
jffs2_scan_inode_node(): CRC failed on node at 0x1c951fc8: Read 0xffffffff, calculated 0x144103e7
Empty flash at 0x1c95203c ends at 0x1c952800
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 104K
Unable to handle kernel paging request at virtual address 32e432f7
pgd = ddf04000
[32e432f7] *pgd=00000000
Internal error: Oops: 5 [#1]
Modules linked in:
CPU: 0 Not tainted (2.6.22.18 #1)
PC is at strnlen+0x20/0x34
LR is at vsnprintf+0x314/0x5b4
pc : [<c0240228>] lr : [<c02414f8>] psr: a0000013
sp : ddeb5dc0 ip : ddeb5dd0 fp : ddeb5dcc
r10: ffffffff r9 : ffffffff r8 : 00000000
r7 : ffffffff r6 : ddd2f041 r5 : 32e432f7 r4 : ddeb5e40
r3 : c00c8994 r2 : 32e432f7 r1 : fffffffe r0 : 32e432f7
Flags: NzCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 0005317f Table: 1df04000 DAC: 00000015
Process udevadm (pid: 1363, stack limit = 0xddeb4268)
Stack: (0xddeb5dc0 to 0xddeb6000)
5dc0: ddeb5e1c ddeb5dd0 c02414f8 c0240218 c023db48 ddeb5dec ddeb5dfc ddeb5df0
5de0: c027369c 222d0fbe ddd2f041 c00d321a ddeb5e44 00000014 00000041 ddeb0000
5e00: ddd2f000 c03ed298 00000000 c03fc7a4 ddeb5e38 ddeb5e20 c0241864 c02411f4
5e20: c03ed240 ddeb5e40 ddd2f000 ddeb5eec ddeb5e48 c026ef10 c024184c c00d3219
5e40: 32e432f7 32e432f7 ddeb0000 00001000 ddeb0000 ddeb000c ddeb0020 ddeb0033
...


siberean
()
Ответ на: комментарий от siberean

> Bad eraseblock 324 at 0x02880000

> mvCLAudioCodecRegGet: Error while reading register!

> mvCLAudioCodecInit: Error - Invalid Cirrus Logic chip/rev ID!

Похоже, эта железка свое отслужила.

P.S. а вам правда нужны dm и md?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

это новая железка, пришедшая неделю назад с завода (она ещё не продаётся энд-юзерам).
Как я понимаю - это не проблемы конкретно моего плохого железа, а просто потому что это Marvell _Development_ Board.

рейд и прочие штучки засандалил в ядро не я, а марвелловские девелоперы.
Там вообще - чего только нет. Ведь машинка - мощности почти современной персоналки , но потребляющая несколько ватт (3-5)

вот например я попробовал прокачивать через неё данные через NFS:
root@debian:/mnt/tmp# dd if=/mnt/tmp/tmp/testfile of=/mnt/tmp/tmp/testfile2 bs=1024 count=100000
100000+0 records in
100000+0 records out
102400000 bytes (102 MB) copied, 9.46773 s, 10.8 MB/s

и то наверное только потому - что на удалённой машине - 100Мбит карточка.

Мой пентиум 3/450 несравнимо слабее чем эта железка. Говорят - сильнее UltraSpark III.

Так что скорее всего - ядро не отлажено/не тестилось ещё под эту железку, а не железо - битое (которое, наверное, тестировалось на заводе ещё только пару недель назад).


Хотя могу ошибаться. Надо взять вторую такую и сравнить. Тогда будет понятно.

siberean
()
Ответ на: комментарий от siberean

> это новая железка, пришедшая неделю назад с завода

Ну, может она родилась мертвой. Если моя арифметика мне ни с кем не изменяет, все bad block'и - у тебя в rootfs.

> рейд и прочие штучки засандалил в ядро не я, а марвелловские девелоперы.

> Там вообще - чего только нет. Ведь машинка - мощности почти современной персоналки , но потребляющая несколько ватт (3-5)

з-5 ватт - это с двумя жесткими дисками? :D

tailgunner ★★★★★
()
Ответ на: комментарий от siberean

>Мой пентиум 3/450 __несравнимо__ слабее чем эта железка. Говорят - сильнее UltraSpark III.

CPU: ARM926EJ-S вы бы попроще пиарили :)))

monika
()
Ответ на: комментарий от monika

я не пиарю - я вдохновлён (не сказать excited) - какое у неё отношение производительности к цене и энергопотреблению.

siberean
()
Ответ на: комментарий от siberean

>SheevaPlug

Эх, блин. Прикольная штука. И стоит 100 баксов. Только вот в РФ будет раза в 3-4 дороже, как вышло с ATNGW1000 (AVR32).

Macil ★★★★★
()
Ответ на: комментарий от tailgunner

Это ерунда все - драйверы скорей всего на скорую руку состряпаны, аудиокодек всего лишь не опознается - они как правило по i2c или spi управление имеют.

monika
()
Ответ на: комментарий от monika

там архитектура другая, нет мат.сопроц^Щслабые floating-point, шины там поуже, и нельзя сравнивать гигагерцы, но всё равно - согласно опубликованным уже некоторыми товарищами результам тестов - это аналогично Athlon AMD 1Ghz по большему числу параметров.

siberean
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.