Sie sind nicht angemeldet.

Anzeigen

**Wir werden in den kommenden Tagen einen Umzug auf einen neuen Server durchführen. Im Rahmen dieser Maßnahme wird das Forum ca. 1 Stunde nicht erreichbar sein.** nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

Lieber Besucher, herzlich willkommen bei: Die NSLU2 Community****wenns ums speichern und streamen geht****. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Sonntag, 19. Februar 2006, 16:00

Uhrzeit der Hardwareuhr stellen...aber wie????

Ich habe ein kleines oder auch großes Problem.
Ich habe meine NSLU erfolgreich auf Debian (LE) geflasht.
Soweit läuft auch alles gut.

So nun mein Problem: Wie stelle ich die interne cmos Clock in der NSLU????

Die Ausgabe von hwclock:

Zitat

nas1:~# hwclock
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.


Die Ausgabe von hwclock --debug:

Zitat

nas1:~# hwclock --debug
hwclock from util-linux-2.12p
hwclock: Open of /dev/rtc failed, errno=19: No such device.
No usable clock interface found.
Cannot access the Hardware Clock via any known method.


Ich hoffe ihr könnt einen blutjungen Linux Jünger helfen. Ich hoffe das es nur ein ganz kleines Problem ist.

MFG Janner200

Anzeigen

2

Sonntag, 19. Februar 2006, 18:13

Hi, bei mir funktioniert hwclock ...

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
slug:~# uname -a
Linux slug 2.6.15 #1 Wed Feb 8 18:53:28 GMT 2006 armv5tel GNU/Linux
slug:~# hwclock
So 19 Feb 2006 18:05:13 UTC  -0.374911 seconds
slug:~# lsmod
Module                  Size  Used by
zd1211                223880  0
af_packet              11624  4
nfsd                  195984  13
exportfs                2976  1 nfsd
lockd                  48660  2 nfsd
sunrpc                104896  8 nfsd,lockd
ixp400_eth             17724  0
ixp400                945668  1 ixp400_eth
pl2303                 12356  1
usbserial              18992  3 pl2303
ext3                   90152  2
jbd                    37332  1 ext3
mbcache                 5028  1 ext3
slug:~# hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1140197996 seconds after 1969
Last calibration done at 1140197996 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2006/02/19 18:09:49
Hw clock time : 2006/02/19 18:09:49 = 1140372589 seconds since 1969
So 19 Feb 2006 18:09:49 UTC  -0.053039 seconds
slug:~# ls -la /dev/rtc
lrwxrwxrwx 1 root root 4 2006-02-17 17:40 /dev/rtc -> rtc0
slug:~# ls -la /dev/rtc0
crw-rw---- 1 root root 254, 0 2006-02-17 17:40 /dev/rtc0
Fehlen dir irgendwelche Module? Welche Version von DebianSlug benutzt du?

Gruss,
EvilDevil

Anzeigen

3

Sonntag, 19. Februar 2006, 20:04

1. Benutze das Image von dir...schmeichel.

2. Bin nach der Anleitung von nslu2-linux.org vorgegangen, den haste als link auf deiner Seite.

3. Einen unterschied habe ich. Ich habe nicht SID genommen sondern Sarge. Hatte es mit SID auch versucht. Dort aber das gleiche ergebnis.

4. Meine lsmod ausgabe:

Zitat

nas1:~# lsmod
Module Size Used by
ixp400_eth 17724 0
ixp400 945668 1 ixp400_eth
ext3 90152 2
jbd 37332 1 ext3
mbcache 5028 1 ext3

caplink811

Forensupporter

Beiträge: 2 200

Verwendetes NAS-Device: 64X2/8GB/Ubuntu10.04LTS

Firmwareversion / your current Firmware: anderes

Wohnort: Berlin

Beruf: TK/IT Consulting and Engineering

  • Nachricht senden

4

Sonntag, 19. Februar 2006, 20:08

N'Abend,

wer lesen kann ist manchmal klar im Vorteil <eg>, Ihm fehlt das Device...
... die Frage ist nur, wo ist es hin, wenn es denn jemals da war..

bye
JrB
"Supporting joe users worldwide" <- that's our motto


5

Sonntag, 19. Februar 2006, 20:18

@caplink811
Wen meinst du damit???
Wenn du mich meinst ok. Bin blutjunger Linux Jünger. Dann kannste du mir ja sicher sagen wo ich suchen muß. Kann auch nur ein Tipp sein.

MFG Janner2000

caplink811

Forensupporter

Beiträge: 2 200

Verwendetes NAS-Device: 64X2/8GB/Ubuntu10.04LTS

Firmwareversion / your current Firmware: anderes

Wohnort: Berlin

Beruf: TK/IT Consulting and Engineering

  • Nachricht senden

6

Sonntag, 19. Februar 2006, 20:36

N'Abend,

Ich meint das Teufelchen ;)

Da das Device anscheinend nicht da ist (überprüfe mit ls -la /dev/rtc), sollte es neu angelegt werden, mit mknod /dev/rtc c 10 135, und ggfs die Rechte mit chmod 660 /dev/rtc angepasst werden. Evil korrigier mich bitte, wenn Du andere Ideen hast.

bye
JrB
"Supporting joe users worldwide" <- that's our motto


7

Sonntag, 19. Februar 2006, 20:59

Das Device /dev/rtc ist auf meinem Gerät schon vorhanden.
Was mich wundert ist, das bei EvilDevil das device /dev/rtc als symlink auf /dev/rtc0 zeigt.

So nun das ergebnis von ls -la:

Zitat

nas1:~# ls -la /dev/rtc
crw-rw---- 1 root root 10, 135 Feb 19 20:51 /dev/rtc


MFG Janner2000

caplink811

Forensupporter

Beiträge: 2 200

Verwendetes NAS-Device: 64X2/8GB/Ubuntu10.04LTS

Firmwareversion / your current Firmware: anderes

Wohnort: Berlin

Beruf: TK/IT Consulting and Engineering

  • Nachricht senden

8

Sonntag, 19. Februar 2006, 21:28

N'Abend,

hm, hier läuft OpenDebianSlug also BE, aber die Version von Hwclock ist ebenfalls 2.12p (im Gegensatz zu EvilDevils) und ein Link nach /dev/rtc0 ist mein /dev/rtc nicht.
Also habe ich spontan keine Ahnung wo es hapert.

bye
JrB

PS: Sind etwaige Hinweise bei Debian.Org zu finden ?
"Supporting joe users worldwide" <- that's our motto


9

Donnerstag, 23. Februar 2006, 08:52

also ich würd sagen NTP installieren (Network Time Protokoll )

dann stimmt s auch mnit der Uhr !

oder lieg ich falsch gehts hier um was anderes ?


MFG
:cool:
Nullinga

10

Mittwoch, 6. September 2006, 10:16

hwclock - cannot access ...

Zitat von »Janner2000;14276«


Die Ausgabe von hwclock --debug:
nas1:~# hwclock
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.


Habe das Gleiche Problem! Hast du mittlerweile eine Lösung gefunden?

Meine Kernel Konfig sagt zu rtc:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# RTC interfaces
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# RTC drivers
CONFIG_RTC_DRV_X1205=y
CONFIG_RTC_DRV_DS1672=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_RS5C372=y
CONFIG_RTC_DRV_M48T86=m
# CONFIG_RTC_DRV_TEST is not set

Sollte also ok sein.

Ich hatte auch keinen Link von /dev/rtc -> /dev/rtc0.
Aber auch eine nachträgliches Anlegen brachte keinen Erfolg.
Mir ist aufgefallen, dass EvilDevil andere Major,Minor Nummern besitzt:

Quellcode

1
2
3
4
ls -la /dev/rtc
lrwxrwxrwx 1 root root 4 2006-02-17 17:40 /dev/rtc -> rtc0
slug:~# ls -la /dev/rtc0
crw-rw---- 1 root root 254, 0 2006-02-17 17:40 /dev/rtc0


Obwohl in der Kernel-Doku 10,135 steht, habe ich mal testweise ein Device
mit 254,0 angelegt.
Ein hwclock --debug ergibt dann:

Quellcode

1
2
3
4
5
6
7
8
9
hwclock --debug
hwclock from util-linux-2.12r
Using /dev/rtc interface to clock.
Last drift adjustment done at 1154000000 seconds after 1969
Last calibration done at 1154000000 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change

... danach passiert rein garnichts mehr. Falls man nun rebootet, hängt die Slug sich beim Bootvorgang auf.

Ach ja, ntpdate kann man natürlich einsetzen. Aber beim Reboot des Slugs steht das Datum wieder auf dem Wert der Erstinstallation, keine saubere Lösung.

trapperjohn

Fortgeschrittener

Beiträge: 558

Wohnort: Bremen

Beruf: SW-Entwickler

  • Nachricht senden

11

Mittwoch, 6. September 2006, 18:43

Soeben bei mir geguckt - sieht genauso aus wie bei debiano!
Gruß,
Flo

12

Freitag, 15. September 2006, 16:25

rtc - udev

@trapperjohn
Was sieht genauso aus?
Welchen(s) Kernel / Flashimage hast du installiert?
Läuft der udevd?

Um auszuschliessen, dass es sich um Kernelabhängigkeiten handelte, habe ich mal den Kernel 2.6.16 mit dem Flashimage von EvilDevil installiert:
debianslug-nslu2-latest.img vom 25-May-2006 21:05
Einzige Änderung: Etch statt SID, wie von EvilDevil empfohlen

Das Verhalten ist leider das Gleiche:

System installiert - es existiert wie bei Janner2000 das Device:

Zitat

crw-rw---- 1 root root 10, 135 Feb 19 20:51 /dev/rtc


hwclock --debug ergibt die zitierten Probleme.

Zu diesem Zeitpukt habe ich noch kein apt-get install udev gemacht.
Nach dem Install von udev werden diverse Devices angelegt und es gibt nun ein

Zitat

crw-rw---- 1 root root 254, 0 Feb xx yy:zz /dev/rtc0


Führe ich nun einen Reboot durch, so lässt sich das System nicht mehr ansprechen oder anpingen. Die Status-LED blinkt abwechselnd ROT/ORANGE.

@EvilDevil
Was fehlt mir, was bei deinem System offensichtlich installiert/gestartet/konfiguriert ist?
Läuft bei Dir der udevd?
Wie kann ich herausfinden, was genau durch den Start von udev nicht funktioniert?

noch nicht hoffnungslos
debiano

13

Freitag, 15. September 2006, 17:43

Hi debiano,

ich habe ein anderes FlashImage laufen

Quellcode

1
Linux slug 2.6.16 #4 Mon Mar 6 11:30:46 GMT 2006 armv5tel GNU/Linux

Das dürfte dieses sein:
http://www.student-zw.fh-kl.de/~pasc0010/debianslug/images/debianslug-nslu2-20060307161151.flashdisk.img.bz2
udevd läuft bei mir.


Quellcode

1
2
lrwxrwxrwx 1 root root      4 2006-09-15 15:48 /dev/rtc -> rtc0
crw-rw---- 1 root root 254, 0 2006-09-15 15:48 /dev/rtc0


Du kannst ja mal probieren, ob du /dev/rtc manuell anlegen kannst (mittels mknod) und falls hwclock immer noch nicht funktioniert, wird es wahrscheinlich am kernel liegen.

Gruss,
EvilDevil
(der heute morgen seine NSLU2 uptime von über 90 Tagen wieder auf 0 zurücksetzen musste, weil Elektriker heute den halben Tag an einem neuen Durchlauferhitzeranschluss gearbeitet haben :(((((((
7 Stunden... da hilft auch keine USV mehr;)

14

Samstag, 16. September 2006, 17:39

rtc - udev - Flashimage

Zitat von »EvilDevil;18819«

Hi debiano,

ich habe ein anderes FlashImage laufen

Quellcode

1
Linux slug 2.6.16 #4 Mon Mar 6 11:30:46 GMT 2006 armv5tel GNU/Linux

Das dürfte dieses sein:
http://www.student-zw.fh-kl.de/~pasc0010/debianslug/images/debianslug-nslu2-20060307161151.flashdisk.img.bz2
udevd läuft bei mir.
Du kannst ja mal probieren, ob du /dev/rtc manuell anlegen kannst (mittels mknod) und falls hwclock immer noch nicht funktioniert, wird es wahrscheinlich am kernel liegen.


Danke für die schnelle Antwort!
Manuelles Anlegen der Devices bringt nichts, wie bereits versucht und beschrieben.
Habe meine Slug also nochmal mit dem obigen Image geflasht und auch die Platte neu formatiert. Bootstrap dieses mal wg. zunehmender Faulheit mittels:

Quellcode

1
wget http://www.nanl.de/nslu2/install.sh

durchgeführt. Vorher aber noch SID --> in ETCH geändert!
Bootstrap bleibt dann bei

Quellcode

1
I: Installing core packages...

hängen, analog zum Thread:
http://www.nslu2-info.de/showthread.php?t=4378

Den blockierenden Prozess

Quellcode

1
iconvconfig
habe ich zweimal manuell beenden müssen, der Rest lief dann "normal" durch.
Resultat: Eine bootfähige Slug mit Deinem Kernel. Soweit also nicht Neues. Also apt-get install udev vorgenommen und ein reboot durchgeführt.
Ergebnis: Slug läßt sich nicht mehr ansprechen, alles wie gehabt.
Leider läßt sich die Slug auch durch manuelles Entfernen der udev-Starteinträge unter rc?.d nicht mehr zum Booten mit Festplatte überreden ;-(
Nur die LED Blinkreihenfolge hat sich verändert, zwischendurch erscheint auch mal eine grüne Status LED im Wechsel mit Orange/Rot.

Muss man bestimmte Module installieren und laden, bevor man udev installiert?
Wozu dient z.B. das Modul: "kernel-modules_2.6.16-r6.4_ixp4xxle.ipk"

Oder liegt es an der Debian Version Etch ?

Die von Dir unter:
http://www.nslu2-info.de/showthread.php?t=4549
beschrieben Flashimage Abhängigkeit des rtc-Problems sehe ich so nicht mehr.

langsam verzweifelnd, aber immer noch nicht hoffnungslos
debiano

15

Sonntag, 17. September 2006, 21:41

Hi,
hast du die Zeit gestellt, nachdem du udev installiert hattest?
Wenn ich mich recht erinnere, gibts boot-probleme, wenn die falsche uhrzeit eingestellt ist.
Habe eben auf meiner Dev-Slug mal DebianSlug 3.10 beta installiert(also nur das FlashImage ohne Bootstrap): Es ging kein Zugriff auf die Hardwareuhr.
Ich habe aber mal in /sys/class/rtc-dev/rtc0 etwas rumgestöbert und dort die Datei "dev" gefunden. Da steht folgendes drin: 254 0
Also hab ich einfach mal
mknod /dev/rtc c 254 0
ausgeführt und hwclock hat darauf direkt funktioniert:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
root@devslug:/sys/class/rtc-dev/rtc0# uname -a
Linux devslug 2.6.16 #1 PREEMPT Wed Jul 12 23:19:51 CEST 2006 armv5tel unknown
root@devslug:/sys/class/rtc-dev/rtc0# cat dev
254:0
root@devslug:/sys/class/rtc-dev/rtc0# hwclock
Mon Dec 27 07:42:06 1999  0.000000 seconds
root@devslug:/sys/class/rtc-dev/rtc0# date -s 091721542006
Sun Sep 17 21:54:00 UTC 2006
root@devslug:/sys/class/rtc-dev/rtc0# hwclock -w
root@devslug:/sys/class/rtc-dev/rtc0# hwclock
Sun Sep 17 21:54:04 2006  0.000000 seconds

Gruss,
EvilDevil

16

Freitag, 22. September 2006, 20:01

Zitat von »EvilDevil;18852«

Hi,
hast du die Zeit gestellt, nachdem du udev installiert hattest?l


Nein, zunächst ntpdate installiert und ausgeführt, danach udev installiert.

Deinen Test kann ich nachvollziehen, obwohl ich eine andere Verzeichnisstruktur habe, bei gleichem Kernel/Flashimage??

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
root@nslu1:/sys/class/rtc/rtc0# ls -l
-r--r--r--    1 root     root         4096 Sep 18 19:59 date
-r--r--r--    1 root     root         4096 Sep 18 19:59 dev
lrwxrwxrwx    1 root     root            0 Sep 18 19:59 device -> ../../../devices/platform/IXP4XX-I2C.0/i2c-0/0-006f
-r--r--r--    1 root     root         4096 Sep 18 19:59 name
-r--r--r--    1 root     root         4096 Sep 18 19:59 since_epoch
-r--r--r--    1 root     root         4096 Sep 18 19:59 time
--w-------    1 root     root         4096 Sep 18 19:59 uevent
root@nslu1:/sys/class/rtc/rtc0# cat dev
254:0
root@nslu1:/sys/class/rtc/rtc0# mknod /dev/rtc c 254 0
root@nslu1:/sys/class/rtc/rtc0# hwclock
Mon Sep 18 19:03:42 2006  0.000000 seconds


Diese Einstellung überlebt allerdings das Booten mit Harddisk nicht und zeigt auch keinerlei Veränderung.

Zusammengefasst nochmal eine Übersicht der Logeinträge:

verwendeter Kernel / Flashimage:

Quellcode

1
2
Linux version 2.6.16 (ubuntu@ubuntu) (gcc version 3.4.4) #4 Mon Mar 6 11:30:46
GMT 2006

aus daemon.log:

Quellcode

1
2
Sep 18 19:18:27 nslu1 udevd[943]: main: the kernel does not support inotify,
udevd can't monitor configuration file changes

aus deiner .config:

Quellcode

1
CONFIG_INOTIFY=y

Sieht so aus, als ob noch eine andere Kernel-Option verhindert, dass config_inotify zieht, aber es ist Dein Image/Kernel.
aus dmesg:

Quellcode

1
2
3
4
5
6
7
8
i2c /dev entries driver
x1205 0-006f: chip found, driver version 1.0.6
x1205 0-006f: rtc intf: sysfs
x1205 0-006f: rtc intf: proc
x1205 0-006f: rtc intf: dev (254:0)
x1205 0-006f: rtc core: registered x1205 as rtc0
...
x1205 0-006f: setting the system clock to 2006-09-18 19:03:42 (1158606222)

aus /var/log/boot:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Mon Sep 18 21:03:59 2006: Setting the system clock..
Mon Sep 18 21:03:59 2006: Cannot access the Hardware Clock via any known
method.
Mon Sep 18 21:03:59 2006: Use the --debug option to see the details of our
search for an access method.
Mon Sep 18 21:03:59 2006: Cannot access the Hardware Clock via any known
method.
Mon Sep 18 21:03:59 2006: Use the --debug option to see the details of our
search for an access method.
Mon Sep 18 21:04:00 2006: System Clock set. Local time: Mon Sep 18 19:03:59
UTC 2006.
Mon Sep 18 21:04:00 2006: Cleaning up ifupdown...done.
Mon Sep 18 21:04:00 2006: Loading modules...
Mon Sep 18 21:04:00 2006: All modules loaded.
Mon Sep 18 21:04:00 2006: Setting the system clock again..
Mon Sep 18 21:04:00 2006: Cannot access the Hardware Clock via any known
method.
Mon Sep 18 21:04:00 2006: Use the --debug option to see the details of our
search for an access method.
Mon Sep 18 21:04:00 2006: System Clock set. Local time: Mon Sep 18 19:04:00
UTC 2006.


aus syslog:

Quellcode

1
2
Mon Sep 18 19:34:28 2006: nslu1 kernel: IRQ LOCK: IRQ22 is locking the system,
disabled

Wer locked hier wohl?

Ich glaube nicht mehr an eine Abhängigkeit vom Image / Kernel. Das Verhalten ist identisch mit dem meiner anderen Versuche mit deinem neueren Image, sowie meinem eigenen Kernel 2.6.17.

Bin ich denn der Einzige mit diesem Poblem?

Social Bookmarks