[workaround gefunden] [0.3] Bei ca. jedem 5. Bootvorgang startet X nicht (dabei läuft auch kein fsck)

Hi!

Ich habe hier ein riesen Problem. Habe für 2 Kollegen VDR-Hardware gekauft und dann meine VDR-Installation (yavdr-0.3) darauf geklont.

Es läuft prinzipiell alles wunderbar, nur kommt es ca. bei jedem 5. Bootvorgang vor, dass kein X gestartet wird, d.h. ich sehe nur einen schwarzen Bildschirm.
Auch wenn ich mich einlogge und openbox neu starte tut sich nichts.
VDR läuft dann zwar und erledigt ggf. Aufnahmen usw. aber so kann ich den VDR nicht weitergeben, denn das würde schon ziemlich nerven wenn man immer wieder mal einen Reboot durchführen muss damit man ein Bild hat.

Ich habe mal die Auszüge aus /var/log/messages für beide Zustände angehängt. Nach den Auszügen kommen dann die VDR-Meldungen vom Start.

Interessant dabei: Wenn das Bild da ist, dann bekomme ich noch eine längliche Warnmeldung die damit beginnt:

WARNING: at /build/buildd/linux-2.6.32/lib/vsprintf.c:1100 vsnprintf+0x3f2/0x410()

Die ist nicht vorhanden wenn kein Bild angezeigt wird. Das scheint mit der HDMI-Verbindung zu tun zu haben, wobei ich hier schon 3 verschiedene Varianten (und 2 Grafikkarten) ausprobiert habe und eigentlich ausschließen kann dass es am TV liegt. Habe 2 TVs und einen Receiver getestet, an denen ich den VDR angeschlossen habe. Bei allen kommt es vor dass mal das Bild nicht aufscheint.

Folgende Meldung kommt zeitlich gesehen auch früher, wenn nachher ein Bild zustande kommt:

vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem

Noch zur Hardware:
Motherboard: Asus P5KPL-AM EPU
Grafikkarte: Gainward GeForce 210 512 MB

Aufgrund der Grafikkarte musste ich gegenüber meinem VDR den Backport-Treiber für Alsa verwenden, wie es hier im Forum empfohlen wird. Ansonsten habe ich keinen Ton.
Das dürfte aber auch der Hauptunterschied sein zu meinem VDR, der einwandfrei funktioniert ..

Hat hier irgendjemand einen Rat für mich in welche Richtung ich hier noch weiter probieren kann ohne anzufangen Hardware auf Verdacht zu tauschen?
Kann das was mit ACPI oder ähnlichem zu tun haben?

Gruß,
Brougs78

Hi!

Cool, dann funktioniert es wirklich. Das habe ich vorher manuell garnicht hinbekommen.

dmesg liefert dann:

[   46.120903] HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=0
[   46.145450] HDMI hot plug event: Pin=5 Presence_Detect=1 ELD_Valid=1
[   46.948508] HDMI: detected monitor LG TV
[   46.948509]    	at connection type HDMI
[   46.948512] HDMI: supports coding type AC-3: channels = 6, rates = 44100 48000 88200, max bitrate = 640000
[   46.948515] ------------[ cut here ]------------
[   46.948521] WARNING: at /build/buildd/linux-2.6.32/lib/vsprintf.c:1100 vsnprintf+0x3f2/0x410()
[   46.948523] Hardware name: System Product Name
[   46.948524] Modules linked in: autofs4 snd_hda_codec_nvhdmi lirc_serial lirc_dev isl6423 stv6110x stv090x nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc budget budget_core lp snd_hda_intel saa7146 nvidia(P) ttpci_eeprom intel_agp snd_hda_codec snd_hwdep agpgart psmouse serio_raw parport dvb_core snd_pcm snd_timer snd soundcore snd_page_alloc asus_atk0110 usbhid hid atl1e
[   46.948551] Pid: 966, comm: hd-audio0 Tainted: P       	2.6.32-32-generic #62-Ubuntu
[   46.948553] Call Trace:
[   46.948558]  [<c014cfb2>] warn_slowpath_common+0x72/0xa0
[   46.948560]  [<c0354de2>] ? vsnprintf+0x3f2/0x410
[   46.948562]  [<c0354de2>] ? vsnprintf+0x3f2/0x410
[   46.948565]  [<c014cffa>] warn_slowpath_null+0x1a/0x20
[   46.948567]  [<c0354de2>] vsnprintf+0x3f2/0x410
[   46.948570]  [<c0354e8a>] snprintf+0x1a/0x20
[   46.948577]  [<efc4264d>] snd_print_pcm_bits+0x5d/0x80 [snd_hda_codec]
[   46.948583]  [<efc4b7f7>] hdmi_show_short_audio_desc+0xf7/0x100 [snd_hda_codec]
[   46.948589]  [<efc4b85f>] snd_hdmi_show_eld+0x5f/0xa0 [snd_hda_codec]
[   46.948594]  [<efc4bb6c>] ? snd_hdmi_get_eld+0x29c/0x2d0 [snd_hda_codec]
[   46.948599]  [<efc4bb6c>] ? snd_hdmi_get_eld+0x29c/0x2d0 [snd_hda_codec]
[   46.948602]  [<efb0a706>] hdmi_unsol_event+0x106/0x110 [snd_hda_codec_nvhdmi]
[   46.948607]  [<c013f283>] ? finish_task_switch+0x43/0xc0
[   46.948611]  [<efc42106>] process_unsol_events+0x56/0x70 [snd_hda_codec]
[   46.948615]  [<c016438e>] run_workqueue+0x8e/0x150
[   46.948619]  [<efc420b0>] ? process_unsol_events+0x0/0x70 [snd_hda_codec]
[   46.948622]  [<c01644d4>] worker_thread+0x84/0xe0
[   46.948625]  [<c0168450>] ? autoremove_wake_function+0x0/0x50
[   46.948628]  [<c0164450>] ? worker_thread+0x0/0xe0
[   46.948630]  [<c01681c4>] kthread+0x74/0x80
[   46.948632]  [<c0168150>] ? kthread+0x0/0x80
[   46.948635]  [<c0104087>] kernel_thread_helper+0x7/0x10
[   46.948636] ---[ end trace 0a25e9a2ddb7ef06 ]---
[   46.948638] HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200 192000, bits = 16

Wie bringe ich das jetzt zu Wege dass das automatisch passiert? Muss ich hier irgendwo einen Delay einbauen?

Interessant dabei ist, dass dabei scheinbar ein "HDMI hot plug event" ausgelöst wird, ohne dass ich das Kabel angefasst habe ...

Gruß,
Brougs78

Nachtrag:

Das ganze ist schräg.

Wenn kein Bild da ist und ich dann "sudo start vdr-frontend" eingebe passiert im ersten Moment nichts und der Befehl hängt.
Erst durch drücken von <strg>+<c> wird der Aufruf abgebrochen, wonach das Frontend aber dann trotzdem startet (mit dem Log von meinem 2. Beitrag).

Die Datein /etc/init/vdr-frontend.conf sieht ja so aus:

brougs@michl:~$ cat /etc/init/vdr-frontend.conf 
#################################################################################
#                                                                           	#
#   The following configuration file is generated automatically by the yaVDR	#
# 	system. Don't change this file as every update of yaVDR will overwrite	#
#     	the local changes. Instead put your required customizations       	#
#   	into /etc/yavdr/templates_custom/ based on the original templates   	#
#                  	under /usr/share/yavdr/templates.                    	#
#                                                                           	#
#   http://www.vdr-wiki.de/wiki/index.php/YaVDR-FAQ#Templating.2FCustomizing	#   
#                                                                           	#
#                                                                           	#
#################################################################################


# Script wartet so lange bis Nvidia Karte oben ist!


pre-start script
while ! DISPLAY=:1 xset -q; do sleep 0.1 ; done
end script


# yavdr-frontend - Starts xine or vdr-sxfe
#


description 	"yavdr-frontend"
author      	"Gerald Dachs <gda@dachsweb.de>"


start on ((started vdr and openbox-started and sound-card-added) or vdr-frontend-restart)
stop on (stopping vdr or stopping openbox)
nice -10


respawn


script
  exec su -c "/usr/bin/start-xineliboutput" vdr 
end script

Warum funktioniert das dann überhaupt? Die Abrage, ob X bereit wird nicht erfüllt, weshalb ich wahrscheinlich auch <strg>+<c> drücken muss damit es weitergeht.
Aber wenn ich auf der Konsole dann unten den Skriptteil mit "/usr/bin/start-xineliboutput" starte, dann funktioniert das auch nicht, da sich vdr-sxfe beschwert dass kein Display vorhanden ist ... was auch logisch ist.
Warum funktioniert es dann über das upstart-Skript?

Ich blicke hier irgendwie nicht durch und weiß nicht woran ich drehen muss dass X zuverlässig startet ...

Gruß,
Brougs78

Hi!

CKone: Ja die Wartezeit hatte ich drinnen. Habe sie jetzt auch wieder aktiviert, wobei das auf das Hauptroblem leider keinen Einfluss hat.

rkp: Danke für den Tipp. Da ich ja auf der Konsole den Start von vdr-frontend abbrechen muss, dachte ich mir ich versuche das anders und habe jetzt das Skript vdr-frontend so umgeschrieben (hier nur der pre-start-Teil):

pre-start script
logger TEST frontend starten
# warte max. 10 Sekunden auf X
for i in `seq 0 100`; do
	if DISPLAY=:1 xset -q; then
	logger TEST Abbruch nach $i
	break
	fi
	sleep 0.1
done
logger TEST Display vorhanden
while ! [ $(cat /proc/asound/cards|grep -c "\- HDA NVidia") -gt 0 ] ; do sleep 1 ; done
logger TEST Ton vorhanden
end script

D.h. ich lasse maximal 10 Sekunden auf X warten und logge immer die Zeitpunkte mit, wann das Pre-Start-Script startet, das Display verfügbar ist und der Ton bereit ist.

Für einen normalen Start sieht dann der Log so aus:

Jun 19 11:36:57 michl logger: TEST frontend starten
Jun 19 11:36:57 michl logger: TEST Abbruch nach 0
Jun 19 11:36:57 michl logger: TEST Display vorhanden
Jun 19 11:37:04 michl logger: TEST Ton vorhanden

Auf das Display wird garnicht gewartet, aber auf den Ton.

Wenn es nicht auf Anhieb klappt sieht das ganze so aus:

Jun 19 11:44:09 michl logger: TEST frontend starten
Jun 19 11:44:20 michl logger: TEST Display vorhanden
Jun 19 11:44:20 michl logger: TEST Ton vorhanden
Jun 19 11:44:26 michl logger: TEST frontend starten
Jun 19 11:44:26 michl logger: TEST Abbruch nach 0
Jun 19 11:44:26 michl logger: TEST Display vorhanden
Jun 19 11:44:26 michl logger: TEST Ton vorhanden

Beim ersten Versuch läuft also die Zeit ab, ohne dass ein Display gefunden wird und das Frontend startet auch nicht. Beim 2. Durchgang sieht es wieder wie oben aus, ohne dass auf den Ton gewartet werden muss.
Dass es überhaupt 2 Durchgänge gibt liegt an "respawn" im Upstart-Skript richtig? Kenne mich mit Upstart nicht aus.

So funktioniert das ganze jetzt also. Vielleicht hat aber doch noch jemand eine Idee an was da grundsätzlich liegen kann. Ist ja irgendwie eine sehr unbefriedigende Lösung ...

Gruß,
Brougs78

H!

ochja: Ja klar, das habe ich schon gemacht. Aber da Problem ist ja auch nicht dass es garnicht funktioniert hat, sondern nur nicht immer ...
Danke trotzdem, für den Hinweis.

Gruß,
Brougs78

Hi!

rkp: Also die Modifikation, mit der auf den Ton gewartet wird, ist nicht von mir. Die habe ich aus einem anderen Thread wo es um die Tonprobleme mit der GT2xx geht.
Aber schön wenn es geholfen hat

Ich werde das ganze jetzt auch so lassen, denn produktiv kann man das so ja durchwegs einsetzen. Dann braucht halt der Startvorgang etwa jedes 5. Mal 10 Sekunden länger. Das ist auch nicht so schlimm, denn das Board ist sowieso schon extrem langsam (über 30 Sekunden bis der Kernel geladen wird).

Gruß,
Brougs78

Hi!

Also das Problem dass X garnicht gestartet ist, hatte bei mir nichts mit dem LG-TV zu tun, war auf einem Philips direkt bzw. an HDMI-Receiver von Sony genauso.
Aber grundsätzlich machte der LG ein paar Probleme. Das überschneidet sich wohl mit dem anderen Thread:
[0.3] kein Ton über HDMI bei Asrock 330 HT (alle Ausgänge unmuted)

Gruß,
Brougs78