Kartenleser Reiner SCT pinpad + Kernel 2.6

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 09.06.2004 11:03:00

Ich habe mir von kernel.org 2.6.7-rc2 gezogen, dein patch applied nicht.
Nun, der USB-Maintainer hat's geschafft. :)
Sorry, für so blöde Tipps, aber hast du sich auch an alle obigen Schritte gehalten?
Zuerst ins kernel-Verzeichnis gehen, dann

Code: Alles auswählen

sigi@vortex:/usr/src/linux-2.6.7-rc2$ cat PfadZumPatch/DiePatchDatei.patch | patch -p1
patching file drivers/usb/serial/cyberjack.c
sigi@vortex:/usr/src/linux-2.6.7-rc2$
ausführen...
Was kommt für eine Fehlermeldung?

Falls das patchen wirklich nicht klappt (vielleicht muss man wg Datum/Zeit der Dateien noch ne andere Option vom patch setzen?), kannst du die Zeilen ja immer noch manuell eintippen. Es ist ja nicht viel, was geändert gehört.
Hmm, ich kann hier schlecht die ganze Datei posten. :roll:
Ohne patch kommt ohne karte IMMER dieses, unbegrenzt oft nacheinander..
cjT1SendCmd: -3
Das kommt bei meinem VIA KM266 auch - ohne patch.
Nimmt man das gepachte Modul, läuft alles wunderbar. Ob ne Karte drin ist, oder nicht, ist dem Kartenleser egal.
(Der nforce2 macht ungepacht auch beim ersten Versuch nicht auf)

-7 bedeutet, dass der Kartenleser nicht geöffnet werden kann.
-3 bedeutet, dass beim Auslesen was schief geht.
Deshalb gibt's ja den patch, der a) das Öffnen des Lesers patcht, damit -7 nicht mehr kommt, und b) den lokalen Buffer entfernt, damit kein -3 mehr kommt.
Wenn du die Änderungen irgendwie in deine cyberjack.c bekommst wird auch dein Leser funktionieren. ;)

usb/devices und lsusb -v sind bei mir übrigens gleich.

Schönen Gruß
shh

NACHTRAG:
Hmm,
1. Möglicherweise muss man cjtest nochmal neu übersetzen. Mach doch mal ein make clean && make in den ctapi-Verzeichnis.
2. Hast du vielleicht nen Karten-Dämon installiert, der irgendwas blockiert? Ich habe hier nichts weiter installiert; die ctapt-Treiter und Test-tools (v1.0.0) habe ich von der Reiner-homepage runtergeladen und entpackt.
3. Wenn du mir deine email-Adresse gibst, kann ich dir die gepatchte Datei schicken. :)

Benutzeravatar
lisan
Beiträge: 658
Registriert: 22.02.2003 19:05:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von lisan » 09.06.2004 20:26:59

Frisch ausgepackt und dann den patch versucht.
Den patch hab ich von dir hier abkopiert und ist mit diesem identisch.

Code: Alles auswählen

bart:/usr/src/linux-2.6.7-rc2# cat cyberjack-patch.diff |patch -p1
patching file drivers/usb/serial/cyberjack.c
Hunk #1 FAILED at 109.
Hunk #2 FAILED at 159.
Hunk #3 FAILED at 210.
Hunk #4 FAILED at 226.
4 out of 4 hunks FAILED -- saving rejects to file drivers/usb/serial/cyberjack.c.rej
bart:/usr/src/linux-2.6.7-rc2#
Bevor ich mir das jetzt angucke schick mir lieber gleich das file an arvidw at gmx.de :).

Interessanter weise geht moneyplex ein bischen.
Ich lege einen zugang an, bei der zweiten aufforderung zur pin eingabe haengt sich das gerat auf und die gruene led leuchtet.
Ich glaube er will was auf den chip schreiben ?
Gruss,
Arvid.

shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 09.06.2004 23:50:13

Tja sehr seltsam, dass es nicht geht. 8O
Aber ich habe ja auch erst das patch-Erstellen angefangen, es kann ja auch an dem patch-Format liegen. GH hat ihn aber mittlerweile beim -mm Zweig anfügen können, vielleicht findet er ja mal seinen Weg in den Standardkernel.
Ich hoffe nur, dass der bei anderen nichts kaputt macht. :roll:

Ich hab' dir mal die gepachte cyberjack.c geschickt. Ich hoffe du kriegst deinen Leser damit zum laufen. Auch ein fertig kompiliertes Modul, was du mal mit insmod probieren kannst.

Bei Moneyplex geht bei mir nach dem patch übrigens wieder "alles". (Bis auf Aktienhandel mit der Sparkasse)
Hoffentlich ist der Kernel-patch nicht ein Rückschritt, der nur wegen Moneyplex und den vielleicht veralteten TestModulen gemacht wird. Die Leute vom libchipcard sollen den cyberjack ja erst vor kurzem wieder zum Laufen bekommen haben:
http://www.libchipcard.de/
2004/06/04: Progress Report on Libchipcard2

The current CVS version of Libchipcard2 now works with CTAPI drivers for Kobil and Cyberjack readers ;-)
- was auch immer das genau heissen mag.

Schönen Gruß
shh

Benutzeravatar
lisan
Beiträge: 658
Registriert: 22.02.2003 19:05:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von lisan » 10.06.2004 08:29:38

Es funktioniert :).

Jetzt muss ich noch den ini-brief abgeben, dann kanns losgehen.

Danke dir.

shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 10.06.2004 12:35:15

Super! :P
Hab' gerade gesehen, dass der patch in v2.6.7-rc3-mm1 aufgenommen wurde. :mrgreen:
http://kerneltrap.org/node/view/3268

Gruß
shh

Benutzeravatar
rblock
Beiträge: 13
Registriert: 26.03.2004 18:19:24
Wohnort: Usingen
Kontaktdaten:

Beitrag von rblock » 21.06.2004 18:17:03

Ich möchte mich unverschämterweise einfach mal einklinken. :wink:

Ich habe heute Kernel 2.6.7 installiert und auch darauf geachtet, dass der Patch installiert ist. Allerdings funktioniert es immer noch nicht. Wenn ich gerade gebootet habe, kann ich mich in Moneyplex noch über die Karte anmelden, aber das war's dann auch schon. Kontostände kann ich schon nicht mehr laden, da ich dann nur die Meldung bekomme, dass das Gerät nicht gefunden wird. :(

Hier ein Auszug aus "dmesg" beim Boot:

Code: Alles auswählen

usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
drivers/usb/serial/usb-serial.c: USB Serial support registered for Reiner SCT Cyberjack USB card reader
cyberjack 4-1:1.0: Reiner SCT Cyberjack USB card reader converter detected
usb 4-1: Reiner SCT Cyberjack USB card reader converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
usbcore: registered new driver cyberjack
drivers/usb/serial/cyberjack.c: v1.0 Matthias Bruestle
drivers/usb/serial/cyberjack.c: REINER SCT cyberJack pinpad/e-com USB Chipcard Reader Driver
Hier die Meldung, wenn der Kartenleser angesprochen wird:

Code: Alles auswählen

Debug: sleeping function called from invalid context at arch/i386/lib/usercopy.c:623
in_atomic():1, irqs_disabled():1
 [<c011a797>] __might_sleep+0xb2/0xd3
 [<c0214b51>] copy_from_user+0x27/0x86
 [<f8d7b767>] cyberjack_write+0x419/0x4c5 [cyberjack]
 [<c0125372>] del_timer_sync+0x39/0x146
 [<f8d8c49c>] serial_write+0x8e/0xbf [usbserial]
 [<c0254f4a>] write_chan+0x1f2/0x21a
 [<c0118ef9>] default_wake_function+0x0/0x12
 [<c0118ef9>] default_wake_function+0x0/0x12
 [<c024f1f4>] tty_write+0x250/0x300
 [<c0254d58>] write_chan+0x0/0x21a
 [<c016bc36>] sys_select+0x23c/0x50b
 [<c024efa4>] tty_write+0x0/0x300
 [<c0157d83>] vfs_write+0xb0/0x119
 [<c0157e91>] sys_write+0x42/0x63
 [<c0105be7>] syscall_call+0x7/0xb
Hier ein kleiner Test:

Code: Alles auswählen

(0)root@rb-linux ctapi # ./cjtest
cjIoOpen: -7
(0)root@rb-linux ctapi # rmmod cyberjack
(0)root@rb-linux ctapi # insmod /usr/src/linux/drivers/usb/serial/cyberjack.ko
(0)root@rb-linux ctapi # ./cjtest
cjIoOpen: 0
cjT1SendCmd: 0
cjIoClose: 0
(0)root@rb-linux ctapi # ./cjtest
cjIoOpen: -7
Wie man sieht, kann man das Gerät genau einmal ansprechen. :(

"lspci" gibt folgendes aus:

Code: Alles auswählen

0000:00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02)
0000:00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02)
0000:00:03.0 PCI bridge: Intel Corp. 82875P Processor to PCI to CSA Bridge (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02)
0000:00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev c2)
0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02)
0000:00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AR [Radeon 9600]
0000:01:00.1 Display controller: ATI Technologies Inc RV350 AR [Radeon 9600] (Secondary)
0000:02:01.0 Ethernet controller: Intel Corp. 82547EI Gigabit Ethernet Controller (LOM)
0000:03:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46)
0000:03:0a.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 13)
0000:03:0b.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 01)
0000:03:0c.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
0000:03:0d.0 Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 01)
0000:04:08.0 USB Controller: NEC Corporation USB (rev 41)
0000:04:08.1 USB Controller: NEC Corporation USB (rev 41)
0000:04:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
0000:04:0b.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link)
"lsmod" fördert folgendes zutage:

Code: Alles auswählen

Module                  Size  Used by
cyberjack               9220  0
fglrx                 213316  7
nfsd                   90696  8
exportfs                5888  1 nfsd
lockd                  58440  2 nfsd
sunrpc                138212  2 nfsd,lockd
ohci_hcd               19460  0
aic7xxx               198104  0
ohci1394               32004  0
ieee1394              304180  1 ohci1394
radeonfb               59692  0
i2c_algo_bit            9224  1 radeonfb
i2c_core               19584  2 radeonfb,i2c_algo_bit
snd_intel8x0           30472  1
snd_ac97_codec         66052  1 snd_intel8x0
snd_pcm                87684  1 snd_intel8x0
snd_timer              22788  1 snd_pcm
snd_page_alloc          9224  2 snd_intel8x0,snd_pcm
snd_mpu401_uart         6656  1 snd_intel8x0
snd_rawmidi            21028  1 snd_mpu401_uart
snd_seq_device          7048  1 snd_rawmidi
snd                    49764  9 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore               8032  1 snd
shpchp                 97420  0
intel_mch_agp           8208  0
ntfs                   87372  3
usblp                  11520  0
capidrv                30260  1
isdn                   83232  1 capidrv
fcpci                 502808  2
capi                   15808  4
capifs                  4232  2 capi
kernelcapi             44544  3 capidrv,fcpci,capi
intel_agp              17180  1
e1000                  79492  0
sd_mod                 17024  0
usbmouse                4608  0
evdev                   7808  0
usbserial              23332  1 cyberjack
usb_storage            63552  0
scsi_mod               70712  3 aic7xxx,sd_mod,usb_storage
usbhid                 33728  0
"lsusb" für das Device ergibt:

Code: Alles auswählen

Bus 004 Device 005: ID 0c4b:0100
  Language IDs: none (cannot get min. string descriptor; got len=-1, error=32:Broken pipe)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 Interface
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        16
  idVendor           0x0c4b
  idProduct          0x0100
  bcdDevice            1.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      Remote Wakeup
    MaxPower               96mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
        wMaxPacketSize         16
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               1
  Language IDs: none (cannot get min. string descriptor; got len=-1, error=32:Broken pipe)
Würde ich mich etwas besser auskennen, würde ich den Source selbst ändern, aber ich möchte nicht einfach auf gut Glück dort herumwurschteln. :)

Wenn also jemand eine Idee hat und diese mir zur Lösung gehelfen könnte, wäre ich hocherfreut. ;)


Verzweifelte Grüße
Reiner

--
"Was immer du tun kannst oder erträumst zu können, beginne es jetzt."
von: Johann Wolfgang von Goethe (1749-1832)

Reiner Block
http://www.bisoft.de

shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 22.06.2004 12:13:45

In Kernel 2.6.7 ist der patch schon drin, da muss man eigentlich nichts mehr patchen.

Leider musste ich aber auch feststellen, dass es noch nicht 100%ig klappt.
Die Veränderungen haben halt wenigstens ansatzweise wieder Funktion gebracht.

Probier' mal folgende (zusätzliche) Änderungen:
1. Alle usb_clear_halt(...) Zeilen in der drivers/usb/serial/cyberjack.c auskommentieren. Also auch die restliche in cyberjack_open() und die drei in cyberjack_close().
2. Neu kompilieren: Ins Kernel-Verzeichnis gehen, dann 'make modules', dann kann man mit

Code: Alles auswählen

rmmod cyberjack && insmod drivers/usb/serial/cyberjack.ko
das neue Modul ausprobieren ausprobieren.
Für Leute, die lieber patchen wollen, hier ein "Auskommentier"-diff:

Code: Alles auswählen

--- cyberjack.c.orig	2004-06-22 12:00:19.000000000 +0200
+++ cyberjack.c	2004-06-22 12:01:43.000000000 +0200
@@ -157,8 +157,8 @@ static int  cyberjack_open (struct usb_s
 
 	dbg("%s - port %d", __FUNCTION__, port->number);
 
-	dbg("%s - usb_clear_halt", __FUNCTION__ );
-	usb_clear_halt(port->serial->dev, port->write_urb->pipe);
+//	dbg("%s - usb_clear_halt", __FUNCTION__ );
+//	usb_clear_halt(port->serial->dev, port->write_urb->pipe);
 
 	/* force low_latency on so that our tty_push actually forces
 	 * the data through, otherwise it is scheduled, and with high
@@ -196,10 +196,10 @@ static void cyberjack_close (struct usb_
 		usb_unlink_urb (port->write_urb);
 		usb_unlink_urb (port->read_urb);
 		usb_unlink_urb (port->interrupt_in_urb);
-		dbg("%s - usb_clear_halt", __FUNCTION__ );
-		usb_clear_halt(port->serial->dev, port->write_urb->pipe);
-		usb_clear_halt(port->serial->dev, port->read_urb->pipe);
-		usb_clear_halt(port->serial->dev, port->interrupt_in_urb->pipe);
+//		dbg("%s - usb_clear_halt", __FUNCTION__ );
+//		usb_clear_halt(port->serial->dev, port->write_urb->pipe);
+//		usb_clear_halt(port->serial->dev, port->read_urb->pipe);
+//		usb_clear_halt(port->serial->dev, port->interrupt_in_urb->pipe);
 	}
 }
Dann dürfte zumindest nicht mehr "so schnell" der -7 Fehler kommen.

Wenn der Kartenleser nicht mehr ansprechbar ist, kann man das i.a. richten durch:
Intel & VIA:
rmmod uhci_hcd && modprobe uhci_hcd
nforce2, AMD-chipsets:
rmmod ohci_hcd && modprobe ohci_hcd

Irgendwie scheint mit dem KartenLeser was grösseres im Busch zu sein, denn offenbar hängt sich das übergeordnete ohci_hcd/uhci_hcd mit der Zeit auf.
Witzigerweise auch, wenn man den Kartenleser gar nicht "richtig" benutzt.
Wenn man den Kartenleser öfters an & absteckt (es ist hotplug installiert), oder das Modul öfters läd und wieder entläd, merkt irgendwann der ohci_hcd das "Anstecken" nicht mehr und registriert das Gerät (/dev/ttyUSB0) nicht mehr.

Ich probier' damit schon länger rum, und irgendwie scheint die cyberjack.c nicht selber schuld zu sein. Harald Welte popelt damit auch rum und meint beim Abstecken wird usb_serial_disconnect() einmal zuviel aufgerufen, von irgendwoher...

Tja, wer mehr analysieren möchte, kann sich ja mit
modprobe usbserial debug=1
modprobe cyberjack debug=1
ein paar Meldungen in /var/log/messages setzen lassen.
Dann kann man dann genau sehen, was abläuft (schiefläuft?) und sich auch seine Änderungen anzeigen lassen.

Deine logs sehen übrigens "normal" aus, nur das "Debug: sleeping function called fr..." ist bei mir noch nicht aufgetaucht. Mehr kann ich damit leider auch nicht anfangen.

> Würde ich mich etwas besser auskennen, würde ich den Source selbst ändern, aber ich möchte nicht einfach auf gut Glück dort herumwurschteln.

Nur keine Hemmungen! Die cyberjack.c ist eigentlich recht klein, und ein bisschen am Kernel rumpopeln macht echt Spass! 8)

Benutzeravatar
rblock
Beiträge: 13
Registriert: 26.03.2004 18:19:24
Wohnort: Usingen
Kontaktdaten:

Beitrag von rblock » 22.06.2004 13:03:02

shh hat geschrieben:In Kernel 2.6.7 ist der patch schon drin, da muss man eigentlich nichts mehr patchen.
Hab' ich auch nicht, da ein cmp mir das verraten hatte. ;)
shh hat geschrieben:Leider musste ich aber auch feststellen, dass es noch nicht 100%ig klappt.
Die Veränderungen haben halt wenigstens ansatzweise wieder Funktion gebracht.
Leider nur ansatzweise, da man sich in Moneyplex höchstens noch über den Leser anmelden kann und er dann nicht mehr ansprechbar ist. :(
shh hat geschrieben:Probier' mal folgende (zusätzliche) Änderungen:
1. Alle usb_clear_halt(...) Zeilen in der drivers/usb/serial/cyberjack.c auskommentieren. Also auch die restliche in cyberjack_open() und die drei in cyberjack_close().
2. Neu kompilieren: Ins Kernel-Verzeichnis gehen, dann 'make modules', dann kann man mit

Code: Alles auswählen

rmmod cyberjack && insmod drivers/usb/serial/cyberjack.ko
das neue Modul ausprobieren ausprobieren.
Für Leute, die lieber patchen wollen, hier ein "Auskommentier"-diff:
Bah! Solche Kleinigkeiten macht man doch wohl von Hand, oder? ;)
shh hat geschrieben:Dann dürfte zumindest nicht mehr "so schnell" der -7 Fehler kommen.
Also ohne Neustart des Rechners hat sich nichts geändert.
shh hat geschrieben:Wenn der Kartenleser nicht mehr ansprechbar ist, kann man das i.a. richten durch:
Intel & VIA:
rmmod uhci_hcd && modprobe uhci_hcd
nforce2, AMD-chipsets:
rmmod ohci_hcd && modprobe ohci_hcd
Bei meinem NEC Chipsatz ist es auch der ohci_hcd, aber dies hat nichts genutzt.
shh hat geschrieben:Irgendwie scheint mit dem KartenLeser was grösseres im Busch zu sein, denn offenbar hängt sich das übergeordnete ohci_hcd/uhci_hcd mit der Zeit auf.
Witzigerweise auch, wenn man den Kartenleser gar nicht "richtig" benutzt.
Ich frage mich wirklich, ob ich das noch witzig finden soll oder nicht. ;) Aber ich vermute auch schlimmeres, allerdings ist es verwunderlich, dass alles andere einwandfrei funktioniert. Wobei ich meinen ForceFeedback eh nicht benutze und für den Scanner noch kein Treiber existiert. Ich wollte mir aber demnächst etwa Zeit dafür nehmen, da es für ein hochwertiges Gerät nicht so schwer sein soll diesen zu programmieren, da die Befehle komplexer aber einfacher sein sollen. :)
shh hat geschrieben:Wenn man den Kartenleser öfters an & absteckt (es ist hotplug installiert), oder das Modul öfters läd und wieder entläd, merkt irgendwann der ohci_hcd das "Anstecken" nicht mehr und registriert das Gerät (/dev/ttyUSB0) nicht mehr.
Man sollte ihn verprügeln dafür. ;)
shh hat geschrieben:Ich probier' damit schon länger rum, und irgendwie scheint die cyberjack.c nicht selber schuld zu sein. Harald Welte popelt damit auch rum und meint beim Abstecken wird usb_serial_disconnect() einmal zuviel aufgerufen, von irgendwoher...
Uaaaaahhhhh! Da er dies bestimmt über den Debug erfahren hat, lohnt es sich wohl kaum nochmals zu debuggen, wenn man dadurch nicht mehr in Erfahrung bringen kann.
shh hat geschrieben:Deine logs sehen übrigens "normal" aus, nur das "Debug: sleeping function called fr..." ist bei mir noch nicht aufgetaucht. Mehr kann ich damit leider auch nicht anfangen.
Es passt aber zum doppelten Aufruf von usb_serial_disconnect(), da dies das Teil in den Tiefschlaf versetzt, aus dem er nicht mehr erwacht. Vielleicht hilf ja ein Pussi von einem schönen Prinzen... ;)
shh hat geschrieben:Nur keine Hemmungen! Die cyberjack.c ist eigentlich recht klein, und ein bisschen am Kernel rumpopeln macht echt Spass! 8)
Wird mir wohl nichts anderes übrig bleiben. :) Und die Popel schicke ich dann Dir, ok? :lol:

BTW, ich hoffe ich werde nicht erschlagen, wenn man erfährt, dass ich gar kein Debian sondern Gentoo Linux verwende? ;)


Popelnde Grüße
Reiner

--
"Was immer du tun kannst oder erträumst zu können, beginne es jetzt."
von: Johann Wolfgang von Goethe (1749-1832)

Reiner Block
http://www.bisoft.de

shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 23.06.2004 10:13:00

shh>> Dann dürfte zumindest nicht mehr "so schnell" der -7 Fehler kommen.
rblock> Also ohne Neustart des Rechners hat sich nichts geändert.

Wenn man die module ohci_hcd, usbserial und cyberjack tauscht, müsste es eigentlich ohne Neustart gehen. Evtl. muss man hotplug nochmal neu starten.
Man kann das neue cyberjack.ko aber auch nach ins Modulverzeichnis des Kernels kopieren und neu starten...

rblock> Bei meinem NEC Chipsatz ist es auch der ohci_hcd, aber dies hat nichts genutzt.

Heisst das nach den Änderungen kann man den Leser auch nur einmal ansprechen, dann muss man neustarten? Hmm.
Bei mir ist's ja auch 2x ein ohci_hcd, der sich mit der Zeit aufhängt: ohci_hcd für nforce2 und Irongate AMD756.
Der uhci_hcd für Intel BX-Board (PIIX4) und VIA KM266 (southb. VIA82xxxxx), scheint nach dem patch (und den zusätzl. Änderungen) recht stabil zu laufen.

Hier mal einige postings zu den cyberjack-Änderungen:
http://marc.theaimsgroup.com/?l=linux-u ... erjack&q=b
insb. das hier:
http://marc.theaimsgroup.com/?l=linux-u ... 821382&w=2

Vermutlich muss man sich wirklich mal den ohci_hcd (oder evtl die usbserial) anschauen, um vielleicht was zu finden. Das wird dann aber wohl ein Grossprojekt.
8O

> Und die Popel schicke ich dann Dir, ok?

Ja, alle Popel an mich zurück. :D
Wäre ja gelacht, wenn immerhin schon doppelt so viele Entwickler daran nicht was bewirken können.

Benutzeravatar
rblock
Beiträge: 13
Registriert: 26.03.2004 18:19:24
Wohnort: Usingen
Kontaktdaten:

Beitrag von rblock » 23.06.2004 12:24:46

Nachdem mein System gestern nach einem Update nicht mehr laufen wollte und ich bis fünf (!) Uhr heute Morgen gebastelt habe. Habe ich es gerade auch geschaft KDE wieder zum Laufen zu bekommen. Irgend ein dämliches Update hatte unter /usr/kde/3.2/lib/kde/ und allen Unterverzeichnissen die Permissions aller *.la (und nicht die der *.so) auf "0640" gesetzt. Ist natürlich sehr sinnig... Habe nun alles wieder auf "0755" geändert und alles läuft wider. :D

Daher kann ich auch mitteilen, dass ich eine E-Mail von ReinerSCT bekommen habe mit einem Patch, der angeblich alle Probleme löst. Werde ihn mir mal eben ansehen... :)

Aha, der ist von Harald Welte...

Die README:

Code: Alles auswählen

This directory contains a number of fixes to make cyberjack.c work on
linux 2.6.x kernels.


cyberjack-1.01-2.6.4.patch:
	Patch applies to kernels 2.6.3 to 2.6.7-rc2 and updates the
	cyberjack.c driver to version 1.01.
	Use this patch if you have kernels 2.6.3 to 2.6.7-rc2

cyberjack-1.01-2.6.7.patch:
	Patch applies to kernel 2.6.7 and updates the cyberjack.c
	driver to version 1.01.  
	Use only this patch if you have kernel 2.6.7

cyberjack-dontoops-rmmod-2.6.7.patch
	Patch applies to any 2.6.3 to 2.6.7 kernels and fixes a problem
	in the generic usb serial layer to make it not crash once you try
	to manually unload (rmmod) the cyberjack.ko module.
Falls Du Ihn nicht bekommen hast, kann ich ihn Dir schicken. :) Werde es sofort mal ausprobieren.

Testende Grüße
Reiner

--
"Was immer du tun kannst oder erträumst zu können, beginne es jetzt."
von: Johann Wolfgang von Goethe (1749-1832)

Reiner Block
http://www.bisoft.de

shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 23.06.2004 18:27:08

So....
Haralds patch für die usb-serial.c scheint endlich Besserung zu bringen bzgl. der oopses und dem Einschlafen vom ohci_hcd nach mehrerem An/Abstecken.

Zusätzlich hat Harald Welte noch einiges an den Aufrufen in der cyberjack.c geändert.
Leider wird in seinen originalen patches der lokale Schreib-Buffer wieder eingeführt, war hier an meinen Rechnern Fehler in Verbindung mit dem cjtest Programm der Reiner-Treibersuite bringt. Ich habe den Teil mal bis auf weiteres revidiert, bzw so gelassen wie er im aktuellen Kernel ist.
Ob jetzt cjtest nur falsch programmiert ist (bzgl neuerer Kernelversionen) und ob der lokale Buffer wirklich nötig ist, weiss ich noch nicht. Ohne Buffer funktioniert's aber - zumindest bei mir.

Kleine Anleitung für Kernel 2.6.7:
1. Nach /usr/src/linux-2.6.7/drivers/usb/serial/ gehen.
2.

Code: Alles auswählen

cat usb-serial.patch | patch -b
ausführen.
3.

Code: Alles auswählen

cat cyberjack.patch | patch -b
ausführen.
4. Nach /usr/src/linux-2.6.7/ gehen und

Code: Alles auswählen

make modules
ausführen.
5. Die neuen Module aus /usr/src/linux-2.6.7/drivers/usb/serial/ ins Modull-Verzeichnis /lib/modules/.....) kopieren.
6. Neu starten, oder die Module manuell laden.

Aktuelle patches für Kernel 2.6.7:
Patch für /usr/src/linux-2.6.7/drivers/usb/serial/cyberjack.c
Abspeichern als cyberjack.patch oder hier runterladen: cyberjack.patch

Code: Alles auswählen

--- cyberjack.c.orig	2004-06-24 12:01:54.000000000 +0200
+++ cyberjack.c	2004-06-23 14:06:03.000000000 +0200
@@ -49,7 +49,7 @@
 /*
  * Version Information
  */
-#define DRIVER_VERSION "v1.0"
+#define DRIVER_VERSION "v1.01"
 #define DRIVER_AUTHOR "Matthias Bruestle"
 #define DRIVER_DESC "REINER SCT cyberJack pinpad/e-com USB Chipcard Reader Driver"
 
@@ -116,6 +116,7 @@ struct cyberjack_private {
 static int cyberjack_startup (struct usb_serial *serial)
 {
 	struct cyberjack_private *priv;
+	int i;
 
 	dbg("%s", __FUNCTION__);
 
@@ -133,6 +134,16 @@ static int cyberjack_startup (struct usb
 
 	init_waitqueue_head(&serial->port[0]->write_wait);
 
+	for (i = 0; i < serial->num_ports; ++i) {
+		int result;
+		serial->port[i]->interrupt_in_urb->dev = serial->dev;
+		result = usb_submit_urb(serial->port[i]->interrupt_in_urb, 
+					GFP_KERNEL);
+		if (result)
+			err(" usb_submit_urb(read int) failed");
+		dbg("%s - usb_submit_urb(int urb)", __FUNCTION__);
+	}
+
 	return( 0 );
 }
 
@@ -143,6 +154,7 @@ static void cyberjack_shutdown (struct u
 	dbg("%s", __FUNCTION__);
 
 	for (i=0; i < serial->num_ports; ++i) {
+		usb_unlink_urb (serial->port[i]->interrupt_in_urb);
 		/* My special items, the standard routines free my urbs */
 		kfree(usb_get_serial_port_data(serial->port[i]));
 		usb_set_serial_port_data(serial->port[i], NULL);
@@ -173,17 +185,6 @@ static int  cyberjack_open (struct usb_s
 	priv->wrsent = 0;
 	spin_unlock_irqrestore(&priv->lock, flags);
 
-	/* shutdown any bulk reads that might be going on */
-	usb_unlink_urb (port->write_urb);
-	usb_unlink_urb (port->read_urb);
-	usb_unlink_urb (port->interrupt_in_urb);
-
-	port->interrupt_in_urb->dev = port->serial->dev;
-	result = usb_submit_urb(port->interrupt_in_urb, GFP_KERNEL);
-	if (result)
-		err(" usb_submit_urb(read int) failed");
-	dbg("%s - usb_submit_urb(int urb)", __FUNCTION__);
-
 	return result;
 }
 
@@ -195,11 +196,6 @@ static void cyberjack_close (struct usb_
 		/* shutdown any bulk reads that might be going on */
 		usb_unlink_urb (port->write_urb);
 		usb_unlink_urb (port->read_urb);
-		usb_unlink_urb (port->interrupt_in_urb);
-		dbg("%s - usb_clear_halt", __FUNCTION__ );
-		usb_clear_halt(port->serial->dev, port->write_urb->pipe);
-		usb_clear_halt(port->serial->dev, port->read_urb->pipe);
-		usb_clear_halt(port->serial->dev, port->interrupt_in_urb->pipe);
 	}
 }
 
@@ -383,6 +379,10 @@ static void cyberjack_read_bulk_callback
 	usb_serial_debug_data (__FILE__, __FUNCTION__, urb->actual_length, data);
 
 	tty = port->tty;
+	if (!tty) {
+		dbg("%s - ignoring since device not open\n", __FUNCTION__);
+		return;
+	}
 	if (urb->actual_length) {
 		for (i = 0; i < urb->actual_length ; ++i) {
 			/* if we insert more than TTY_FLIPBUF_SIZE characters, we drop them. */


Patch für /usr/src/linux-2.6.7/drivers/usb/serial/usb-serial.c
Abspeichern als usb-serial.patch oder hier runterladen: usb-serial.patch

Code: Alles auswählen

--- usb-serial.c.orig	2004-06-24 12:02:20.000000000 +0200
+++ usb-serial.c	2004-06-23 13:40:23.000000000 +0200
@@ -1393,7 +1393,7 @@ void usb_serial_deregister(struct usb_se
 		serial = serial_table[i];
 		if ((serial != NULL) && (serial->type == device)) {
 			usb_driver_release_interface (&usb_serial_driver, serial->interface);
-			usb_serial_disconnect (serial->interface);
+//			usb_serial_disconnect (serial->interface);
 		}
 	}
 
BITTE MELDEN, wenn die patches bei euch immer noch nicht helfen!
Zuletzt geändert von shh am 24.06.2004 12:50:09, insgesamt 4-mal geändert.

Zoolook
Beiträge: 2
Registriert: 24.06.2004 08:15:26

Beitrag von Zoolook » 24.06.2004 08:53:27

shh hat geschrieben: BITTE MELDEN, wenn die patches bei euch immer noch nicht helfen!
Hi,

bin neu hier, und habe unter Gentoo (so bin ich auch auf diesen Thread gestoßen, aus einem Verweis aus dem Gentoo-Forum, durch rblock) auch das Problem, meinen neuen Cyberjack Pinpad USB (erst seit 2 Tagen von der Sparkasse geholt) mit einem 2.6.7-er Kernel nicht am Laufen bekommen zu können (Reader ist also nagelneu und funzt unter Windows).
Ich kann diese beiden letzten Patches nicht einspielen. Erstens glaube ich richtig erkannt zu haben, daß sie genau mit umgetauschten Namen gespeichert werden sollten, aber dann funktioniert weder

Code: Alles auswählen

cat usb-serial.patch | patch -bp1
noch

Code: Alles auswählen

patch -p0 < usb-serial.patch
(bei allen beiden Dateien). Beide Patches werden rejected. Wenn ich den Text aus Konqueror paste, haben alle Zeilen angefangen von der 2. noch ein Leerzeichen davor, aus Firefox nicht, aber trotzdem beschwert sich dann "patch" daß

Code: Alles auswählen

root@blues serial # root@blues serial # patch -p0 < /usb-serial.patch
patching file usb-serial.c
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 1393.
1 out of 1 hunk FAILED -- saving rejects to file usb-serial.c.rej
und auch wenn ich das dann versuche zu korrigieren, bleibt's ohne Erfolg. Und bei usb-serial kann man ja noch von Hand patchen, aber cyberjack.c würde ich nun nicht von hand verhunzen...

Mache ich etwas falsch? Noch zur Info, ich habe mehrmals die originalen Dateien cyberjack.c und usb-serial.c aus einem frisch runtergeladenen vanilla-Kernel 2.6.7 in meinem aktuellen Kernel-Quellverzeichnis überschrieben.

Würdest Du bitte die Patches als komprimierte Dateien irgendwo zum Download bereitstellen? Oder ich schicke Dir meine eMail-Addresse über die PN-Funktion dieses Forums, und dann könntest Du mir die Dateien als Anhang schicken..?

Schönen Gruß,
Lucian

shh
Beiträge: 140
Registriert: 16.06.2002 14:29:44

Beitrag von shh » 24.06.2004 12:40:20

> Erstens glaube ich richtig erkannt zu haben, daß sie genau mit umgetauschten Namen gespeichert werden sollten

Stimmt! Habe ich natürlich vertauscht. :roll:
Hab's gerade geändert.

Ich habe auch die anderen Patch-"Zitate" nochmal generiert und geändert.
Vielleicht geht's jetzt. Hmm, es scheint wirklich nicht zu funktionieren mit der Option -p1...
Einfach keine Option oder -b für 'n Backup an patch anhängen, dann müsste es klappen.
zB:

Code: Alles auswählen

cat usb-serial.patch | patch -b
[Grübel]Wie macht man ein diff, was dann mit dem üblichen patch -p1 funktioniert?
Ich habe zum diff'en diff -up cyberjack.c{.orig,} benutzt, wie in der Kernel-doku angegeben.

EDIT:
Cyberjack patches:
1. cyberjack.patch
2. usb-serial.patch

EDIT2:
Die Einschlaf-Probleme des ohci_hcd bestehen offenbar immernoch.
Immerhin, gibt's keine oopses mehr und die Allgemeinheit hat wenigstens ansatzweise Funktion.
Der uhci_hcd scheint aber stabiler zu laufen. Bis jetzt habe ich damit noch keine Probleme gehabt. :roll:

Zoolook
Beiträge: 2
Registriert: 24.06.2004 08:15:26

Beitrag von Zoolook » 25.06.2004 07:57:11

Hallo shh,
danke, Deine Patches konnte ich nun einspielen und es funktioniert! Zwar warte ich derzeit noch auf die PIN meiner neunen HBCI-Karte von der Bank, um dann mit dem Banking unter Linux loszulegen (will von der Windows T-Online-Banking-SW weg), aber die Reiner-SCT-tools scheinen zu funktionieren, auch kCardSetup und kMedCard.
Ich hatte aber noch folgendes Problem: da ich unter Gentoo devfs einsetze, fehlte bei mir ein symlink /dev/ttyUSB0 auf /dev/usb/tts/0 und alles funktionierte erst nachdem ich den manuell erstellt habe, hoffentlich ist er beim nächsten Reboot noch da ;-).
Schönen Gruß,
Lucian

Benutzeravatar
rblock
Beiträge: 13
Registriert: 26.03.2004 18:19:24
Wohnort: Usingen
Kontaktdaten:

Beitrag von rblock » 25.06.2004 10:41:35

Zoolook hat geschrieben:Ich hatte aber noch folgendes Problem: da ich unter Gentoo devfs einsetze, fehlte bei mir ein symlink /dev/ttyUSB0 auf /dev/usb/tts/0 und alles funktionierte erst nachdem ich den manuell erstellt habe, hoffentlich ist er beim nächsten Reboot noch da ;-).
Da devfs als obsolet gekennzeichnet ist, solltest Du auf udev umsteigen. Dies ist mit dieser Gentoo Anleitung ganz einfach. Zumindest ging es bei mir problemlos. ;)

Und unter /etc/udev/ findest Du dann eine udev.conf für die generellen Einstellunge und dann in den Unterverzeichnissen rules.d und permissions.d die Konfigurationsdateien für die entsprechenden Einstellungen. :)

HTH

Teilsonnige Grüße
Reiner

--
"Was immer du tun kannst oder erträumst zu können, beginne es jetzt."
von: Johann Wolfgang von Goethe (1749-1832)

Reiner Block
http://www.bisoft.de

Antworten