[gelöst]Probleme mit PCIe Paralellportkarte

andrax · 30 Aug. 2016

Hallo zusammen,

ich ärgere mich schon eine Weile rum und hoffe, dass Ihr mir den entscheidenden Tipp für die Lösung meines Problems geben könnt.
Ich baue mir gerade einen Rechner für eine CNC-Steuerung mit Linuxcnc auf.
Das System basiert auf Debian mit RTAI Kernel.
Da mein Mainboard kein Parallelport mehr hat, habe ich mir eine PCIe Parallelportkarte gekauft um die Steuersignale ausgeben zu können.
"InLine® Schnittstellenkarte, 1x parallel 25-pol, PCIe (PCI-Express)"
"76625C"
Leider habe ich mit der Karte Probleme.
Wenn ich den Rechner kalt starte, bekomme ich keinen Zugriff da die Adressen disabled sind.
Wenn ich aber ins Bios gehe und an den ACPI Einstellungen drehe geht es wieder.
ACPI APCI Support [disable] <> [enable]
ACPI 2.0 Support [enable] <> [disable]

Allerdings nur bis zum nächsten Kaltstart.
Dann beginnt das Spiel von vorne.

Hier noch mal die Ausgabe von

Code:

lspci -vv

Code:

02:00.0 Parallel controller: NetMos Technology Device 9900 (prog-if 03 [IEEE1284])
	Subsystem: Device a000:2000
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at dc00 [disabled] [size=8]
	Region 1: I/O ports at d880 [disabled] [size=8]
	Region 2: [virtual] Memory at feaff000 (32-bit, non-prefetchable) [size=4K]
	Region 5: [virtual] Memory at feafe000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

und unter Root

Code:

02:00.0 Parallel controller: NetMos Technology Device 9900 (prog-if 03 [IEEE1284])
	Subsystem: Device a000:2000
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at dc00 [disabled] [size=8]
	Region 1: I/O ports at d880 [disabled] [size=8]
	Region 2: [virtual] Memory at feaff000 (32-bit, non-prefetchable) [size=4K]
	Region 5: [virtual] Memory at feafe000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [78] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [80] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 <2us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
		VC1:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable- ID=0 ArbSelect=Fixed TC/VC=00
			Status:	NegoPending- InProgress-
	Capabilities: [800 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-

Der aktuell geladene Treiber ist parport_pc.

für Hilfe wäre ich äußerst Dankbar

LG

Andrax

josef-wien · 30 Aug. 2016

Ich habe keine Erfahrung mit solchen Karten, aber fangen wir mit einem Schuß ins Blaue an: Bringt die Boot-Option

Code:

parport_pc.io=0xdc00

etwas?

andrax schrieb:
Wenn ich aber ins Bios gehe und an den ACPI Einstellungen drehe geht es wieder.
ACPI APCI Support [disable] <> [enable]
ACPI 2.0 Support [enable] <> [disable]

Allerdings nur bis zum nächsten Kaltstart.

Bedeutet das, daß das BIOS diese Einstellungen nach einem Kaltstart vergessen hat? Oder heißt das, daß die Karte nach einem Warmstart auch ohne BIOS-Änderung funktioniert? Wie sieht es aus, wenn Du vor dem nächsten Warmstart diese Änderungen rückgängig machst?

Vergleiche das System-Log (dmesg oder Datei /var/log/messages bzw. journalctl -b) von jeweils einem funktionierenden und einem nicht funktionierenden Start. Mehr müssen andere Helfer beitragen.

andrax · 30 Aug. 2016

Hallo,

erst mal Danke für die Rückmeldung.
wo trage ich die Bootoption ein?

Bedeutet das, daß das BIOS diese Einstellungen nach einem Kaltstart vergessen hat? Oder heißt das, daß die Karte nach einem Warmstart auch ohne BIOS-Änderung funktioniert? Wie sieht es aus, wenn Du vor dem nächsten Warmstart diese Änderungen rückgängig machst?

Nach einem Kaltstart vergisst er alles und ich habe keinen Zugriff.
Nach einem Warmstart ist es egal was drin steht, der Zugriff ist dann immer möglich.
Es wird aber empfohlen ACPI auszuschalten, da es zu Problemen mit Linuxcnc kommen kann.

Ich hab noch was gefunden:

Code:

chmod 666 /dev/parport0

Könnte das was bringen ?

Die Logs schau ich mir nochmal an und stelle sie heute Abend ein.

LG

Andrax

abgdf · 30 Aug. 2016

Existiert bei Dir denn "/dev/parport" oder "/dev/parport0"?

Manchmal muß man lp loswerden (rmmod lp) und ppdev laden (modprobe ppdev).

https://www.murrayc.com/permalink/2005/12/24/wheres-my-parport0/

josef-wien · 30 Aug. 2016

andrax schrieb:
Nach einem Kaltstart vergisst er alles und ich habe keinen Zugriff.

Wenn die Uhrzeit nach einem Kaltstart stimmt, hat entweder Dein BIOS oder der CMOS-Speicher ein Leiden.

andrax schrieb:
Nach einem Warmstart ist es egal was drin steht, der Zugriff ist dann immer möglich.

Das sieht danach aus, daß (entweder das BIOS oder) die Karte bei einem Kaltstart viel zu lange braucht, um die Existenz der Karte kundzutun. Bei einem Warmstart geht es dann schneller, und die Karte wird erkannt. Unter diesem Umständen wird die Bootoption (was Du in Deinem Bootmenü machen mußt, kann man Dir ohne Informationen über den verwendeten Boot-Manager nicht sagen) wohl ebenso wenig helfen wie das System-Log, wenn beim Kaltstart die Frage

abgdf schrieb:
Existiert bei Dir denn "/dev/parport" oder "/dev/parport0"?

mit "nein" beantwortet wird.

andrax schrieb:
Ich hab noch was gefunden

Dann würde es nach einem Warmstart auch nicht funktionieren. Im übrigen wirst Du wohl der Gruppe lp zugeordnet sein und/oder entsprechende ACL-Berechtigungen haben.

andrax · 30 Aug. 2016

Sehr merkwürdig.

/dev/parport0 existiert nicht.
Hab es angelegt mit:

Code:

mknod parport0 char 6 0

Rechte drauf:

Code:

chmod 666 /dev/parport0

Module entfernt:
>lp
>parport
>parport_pc
ppdev geladen

Code:

modprobe ppdev

Rechner neu gestartet und alles beim alten.
/dev/parport0 wieder nicht da.
lp; parport; parport_pc wurden geladen
ppdev nicht geladen.
:/

Sehr merkwürdig

LG

andrax

josef-wien · 30 Aug. 2016

Der link ist über 10 Jahre alt. Diese Aktionen gelten nur für das laufende System, nach einem Neustart ist selbstverständlich alles beim alten.

andrax · 30 Aug. 2016

Hi,

dann schicke ich erst mal meine Systeminformationen:

Code:

System information report, generated by Sysinfo: 31.08.2016 14:47:24
http://sourceforge.net/projects/gsysinfo

SYSTEM INFORMATION
	Running Debian Linux, the 7.11 release.
	GNOME: unknown (unknown)
	Kernel version: 3.4-9-rtai-686-pae (#1 SMP PREEMPT Debian 3.4.55-4linuxcnc)
	GCC: 4.7 (i486-linux-gnu)
	Xorg: 1.12.4 (09 February 2015  10:12:47AM) (09 February 2015  10:12:47AM)
	Hostname: CNC
	Uptime: 0 days 0 h 58 min

CPU INFORMATION
	AuthenticAMD, AMD Phenom(tm) II X2 560 Processor
	Number of CPUs: 2
	CPU clock currently at 3314.840 MHz with 512 KB cache
	Numbering: family(16) model(4) stepping(3)
	Bogomips: 6629.68
	Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save

MEMORY INFORMATION
	Total memory: 3286 MB
	Total swap: 3136 MB

STORAGE INFORMATION

HARDWARE INFORMATION
MOTHERBOARD
	Host bridge
		Advanced Micro Devices [AMD] Family 10h Processor Link Control
		Subsystem: ASUSTeK Computer Inc. Device 8388
	PCI bridge(s)
		ASUSTeK Computer Inc. RS880 PCI to PCI bridge (int gfx) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 0) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 3) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 5) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode])
		ASUSTeK Computer Inc. RS880 PCI to PCI bridge (int gfx) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 0) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 3) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 5) (prog-if 00 [Normal decode])
		Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (prog-if 01 [Subtractive decode])
	ISA bridge
		Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller
		Subsystem: ASUSTeK Computer Inc. Device 8389
	IDE interface
		Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller (prog-if 8a [Master SecP PriP])
		Subsystem: ASUSTeK Computer Inc. Device 8389

GRAPHIC CARD
	VGA controller
		Advanced Micro Devices [AMD] nee ATI RS780L [Radeon HD 3000] (prog-if 00 [VGA controller])
		Subsystem: ASUSTeK Computer Inc. Device 8388

SOUND CARD
	Multimedia controller
		Advanced Micro Devices [AMD] nee ATI RS780 HDMI Audio [Radeon HD 3000-3300 Series]
		Subsystem: ASUSTeK Computer Inc. Device 8388

NETWORK
	Ethernet controller
		Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)
		Subsystem: ASUSTeK Computer Inc. Device 8505

Ich hab den Rechner erst vor 1 Monat neu aufgebaut.
Motherboard neu
CPU neu
Ram neu
PCIe LPT neu
Netzteil neu

Alt ist nur die Platte.
Und wie ich schon geschrieben habe, wird die Karte erkannt.
Nur bekomme ich keinen zugriff.
Wenn natürlich die Karte "lp" zugeordnet ist, ist es nicht verwunderlich das alle Befehle die an parport0 gehen,
dann im Nirvana verschwinden.

Aber wie kann ich das Probem lösen.
Für Linuxcnc brauche ich parport0 sonst geht nix.

LG

Andrax

abgdf · 30 Aug. 2016

josef-wien schrieb:
Der link ist über 10 Jahre alt.

Trotzdem scheint man damit voranzukommen.

andrax schrieb:
Sehr merkwürdig.
/dev/parport0 existiert nicht.
Hab es angelegt mit:

Code:

mknod parport0 char 6 0

Rechte drauf:

Code:

chmod 666 /dev/parport0

Module entfernt:
>lp
>parport
>parport_pc
ppdev geladen

Code:

modprobe ppdev

Rechner neu gestartet und alles beim alten.
/dev/parport0 wieder nicht da.

"mknod" scheint mir nicht der richtige Weg zu sein. Wenn man das richtige Modul mit "modprobe" lädt, sollte "/dev/parport0" automatisch angelegt werden.

Wenn Deine Befehle das bewirken, was Du möchtest, brauchst Du sie ja nicht bei jedem Systemstart neu einzutippen. Es genügt, wenn Du sie in "/etc/rc.d/boot.local" einträgst.

josef-wien · 30 Aug. 2016

lp ist eine Gruppe (die üblicherweise allen devices zugeordnet ist, die - auch historisch betrachtet - etwas mit der parallelen Schnittstelle zu tun haben).

Vergleiche das Ergebnis von

Code:

find /dev

von einem Warmstart und einem Kaltstart. Und sicherheitshalber auch noch:

Code:

lspci -nnk -s 02:00.0

Anonymous · 30 Aug. 2016

andrax schrieb:
"InLine® Schnittstellenkarte, 1x parallel 25-pol, PCIe (PCI-Express)"
"76625C"
Leider habe ich mit der Karte Probleme.

Der aktuell geladene Treiber ist parport_pc.

Was zeigt denn die Eingabe von:

Code:

sudo modinfo 99xx
sudo lsmod|grep 99xx

Für den Chip MCS9900 auf der Karte wird doch ein Linux Kernel-Treiber mitgeliefert.
https://www.intos.de/downloads/1_Treiber/13_Linux/76625C.zip

josef-wien · 31 Aug. 2016

Mit Unterstreichungs- und Leerzeile sehe ich in der Datei readme ganze 7 Zeilen hinsichtlich des parallelen Anschlusses (alles andere betrifft eine serielle Schnittstelle), und da steht in einer anderen Variante mein Schuß ins Blaue (dessen Ergebnis noch offen ist).

andrax · 31 Aug. 2016

Moin,

die Idee hatte ich schon.
Treiber 99xx runter geladen > make > make install
Brachte aber nichts.

Das Problem scheint aber nicht unbekannt zu sein:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NetMos

Die Befehle:

Code:

/sbin/insmod /lib/modules/mein Kernel/kernel/drivers/parport/parport_pc.ko
 /sbin/rmmod ppdev
 /sbin/rmmod lp
 /sbin/rmmod parport_pc

hatte ich probiert.
Komischerweise lies sich parport_pc.ko nicht laden, mit dem Fehler Datei nicht gefunden obwohl parport_pc.ko dort liegt.

Ich habe jetzt den Verdacht, dass das Problem bei der Karte liegt.
Der MCS9900 macht wohl Probleme.
Ich hab jetzt mal zu Sicherheit eine andere bestellt mit MCS9865.
http://www.produktinfo.conrad.com/d...de-MH_PARALLELE_PCI_KARTE_1_EX__DB25_PORT.pdf

Mal schaun was die sagt.

LG

Andrax

abgdf · 31 Aug. 2016

andrax schrieb:
Die Befehle:

Code:

/sbin/insmod /lib/modules/mein Kernel/kernel/drivers/parport/parport_pc.ko /sbin/rmmod ppdev /sbin/rmmod lp /sbin/rmmod parport_pc

hatte ich probiert.

"insmod" macht etwas Ähnliches wie "modprobe", nämlich ein Kernel-Modul laden. Dabei ist jedoch "modprobe" vorzuziehen.
"rmmod" koppelt ein Modul ab. "lsmod" zeigt die Module an. Dann gibt's noch "modinfo", das zeigt Infos über ein spezielles Modul.

Ich hab' hier auch so eine PCI-Parallelportkarte (SuSE 13.1). lp ist weg, parport_pc und ppdev sind geladen. Dazu braucht man aber anscheinend noch einen weiteren Treiber. In meinem Fall benutze ich die Karte, um dort über ein Interface einen Atari-Joystick von 1980 anzuschließen. Dafür wird der Treiber db9 verwendet (cooles Teil).
Damit will ich sagen, daß Du wahrscheinlich noch ein Modul brauchst, um der Karte mitzuteilen, was denn an dem Parallelport ist.

andrax · 31 Aug. 2016

Hallo,

habe das Problem gelöst und es läuft.

Code:

/sbin/insmod /lib/modules/3.4-9-rtai-686-pae/kernel/drivers/parport/parport_pc.ko

funktionierte erst als ich mit

Code:

cd ..

ins Urverzeichnis wechselte.

Dann habe ich die Befehle in einer anderen Reihenfolge eingegeben was zunächst nix brachte.
Noch kein Zugriff

Code:

 /sbin/rmmod ppdev
 /sbin/rmmod lp
 /sbin/rmmod parport_pc
 /sbin/insmod /lib/modules/3.4-9-rtai-686-pae/kernel/drivers/parport/parport_pc.ko

Erst als ich diese Reihenfolge in

Code:

/etc/rc.local

eingetragen habe, funktionierte es.

Jetzt habe ich zugriff auf die Ports.

@abgdf:
Hast du das auch Probiert ?

LG

Andrax

josef-wien · 31 Aug. 2016

andrax schrieb:
/sbin/insmod /lib/modules/3.4-9-rtai-686-pae/kernel/drivers/parport/parport_pc.ko

modprobe -r parport_pc bzw. modprobe parport_pc ist sinnvoller, eine Pfad-Angabe ist unnötig und kontraproduktiv.

andrax schrieb:
3.4-9-rtai-686-pae

Wenn Du den laufenden Kernel ansprichst, solltest Du $(uname -r) verwenden, sonst muß Du bei jedem Kernel-Update ändern. Im übrigen ist der longterm-3.4 mittlerweile bei 3.4.112 angelangt, Dir fehlen jede Menge Sicherheitsaktualisierungen.

abgdf · 31 Aug. 2016

andrax schrieb:
als ich mit

Code:

cd ..

ins Urverzeichnis wechselte.

"cd .." wechselt ins übergeordnete Verzeichnis von der relativen Position aus. Mit "cd /" kommt man ins Stammverzeichnis.

andrax schrieb:
Erst als ich diese Reihenfolge in

Code:

/etc/rc.local

eingetragen habe, funktionierte es.

Jetzt habe ich zugriff auf die Ports.

@abgdf:
Hast du das auch Probiert ?

Ähh, nee?! Ich hatte ja oben "/etc/boot.local" empfohlen. Vielleicht liegt's daran, daß die Skripte in /etc von root ausgeführt werden? Aber Du hast die insmod/modprobe-Befehle doch auch als root eingegeben, oder?
Daß es mit absolutem Pfad nicht gehen sollte, finde ich auch merkwürdig ...

Aber prima, daß es jetzt immerhin geht.

andrax · 31 Aug. 2016

Ja,

ich habe alle Befehle als root eingegeben.
Absolute Pfadangabe war notwendig, da sonst die Befehle mit "Datei nicht gefunden" quittiert wurden.
Ansonsten, mache ich mir wegen Kernelupdates keine Sorgen.
Der Rechner hängt offline an einer CNC-Fräse.

modprobe -r parport_pc bzw. modprobe parport_pc ist sinnvoller, eine Pfad-Angabe ist unnötig und kontraproduktiv.

Ähm nein !
Es geht hier explizit um den parport_pc.ko

Und der ließ sich nur mit der direkten Pfadangabe laden.

LG

Andrax

josef-wien · 31 Aug. 2016

andrax schrieb:
Ähm nein !

Doch.

andrax schrieb:
Es geht hier explizit um den parport_pc.ko

Module lädt man üblicherweise nicht umständlich mit dem Dateinamen (insmod /pfad/zu/parport_pc.ko), sondern einfach mit dem Modulnamen (modprobe parport_pc).

P. S. Das Entladen der Module ppdev und lp sehe ich ein. Der Sinn des danach folgenden Entladens und sofortigen Neuladens des Moduls parport_pc erschließt sich mir nicht.

andrax · 1 Sep. 2016

Moin,

P. S. Das Entladen der Module ppdev und lp sehe ich ein. Der Sinn des danach folgenden Entladens und sofortigen Neuladens des Moduls parport_pc erschließt sich mir nicht.

Mir auch nicht.
Hab übrigens gestern Abend den Eintrag im

Code:

/etc/rc.local

um

Code:

modprobe parport_pc

geändert und getestet.
Das Resultat:

Code:

Region 0: I/O ports at dc00 [disabled] [size=8]

Es scheint wohl doch einen Unterschied zwischen
parport_pc und parport_pc.ko zu geben.
Zumal beide Varianten im Verzeichnis liegen.

Wenn Du den laufenden Kernel ansprichst, solltest Du $(uname -r) verwenden, sonst muß Du bei jedem Kernel-Update ändern. Im übrigen ist der longterm-3.4 mittlerweile bei 3.4.112 angelangt, Dir fehlen jede Menge Sicherheitsaktualisierungen.

Ist so ne Sache.

1. Ja du hast Recht: System immer Aktuell halten.
2. Linuxcnc ist speziell auf den mitgelieferten Kernel angepasst, in den Aktualisierungen wurde daher auch bisher kein neuerer angeboten.
3. Bei mir läuft nicht nur parport sondern auch Ethercat und anderes Zeugs und zuküftig auch Mesa. Es war so schon schwierig, das alles zum
laufen zu bekommen, da belass ich lieber den laufenden Kernel und häng den Rechner vom Internet ab wenn alles läuft.
Gerade Ethercat war ein Krampf, hatte ständig mit freezes zu kämpfen.

Ansonsten:

VIELEN DANK FÜR EURE HILFE

Werd euer Forum Lobenswert erwähnen.

LG

Andrax

[gelöst]Probleme mit PCIe Paralellportkarte

Member

Ultimate Guru

Member

Guru

Ultimate Guru

Member

Ultimate Guru

Member

Guru

Ultimate Guru

Anonymous

Gast

Ultimate Guru

Member

Guru

Member

Ultimate Guru

Guru

Member

Ultimate Guru

Member