sebastian_ml@xxxxxxx(Sebastian) 28.05.05 15:14 >> _______________________________________________ >> vdr mailing list >> vdr@xxxxxxxxxxx >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Why do you quote this siganture(and all text)? >No, VDR is running fine on i686 nptlonly here. Maybe it's because your >whole box is compiled for 64bit and VDR doesn't like _that_ yet? Multitasking systems (not thread save) "degree of suffering" depends strongly on the involved hardware. Generally it can't be predicted if a higher/faster CPU is worser than a slower. But (very) mostly a faster CPU will spill up all unclean codings... Too new "threads" will spill them up, but mostly the innocent new thread will be flamed. (Example: Product works in the labor flawlesly, in the manufacturing area too, but fails at the first customer. Workarround? Wire "DTR" to "asserted" so the software thinks a V24-terminal is connected, as it was in the labor and the test area... Because of the long sleeps during the serial output, the dead locking/amok running/racing/eating all CPU tasks releases their CPU slice often enough so the other workers can deliver the data, the amok thread is waiting for.. IOW: the product worked without V24 too, but in extrem slowmotion, but there are timing checks built in (First programmers always ignored law: Never trust any code! Second programmers always ignored law: Never trust any parameters or data!), so the box dies with "timeout". Because of these "superflous" redundant time checks (we don't make any errors, so verifying parameters is waste of run and programmig time) the problem became obvious very early (actually still too late, but who is perfect?) Rainer
