eumex-devel Mailing List for Eumex x04PC
Status: Beta
Brought to you by:
biop0b
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(2) |
Feb
(12) |
Mar
(15) |
Apr
(24) |
May
(6) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2004 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(21) |
Sep
(17) |
Oct
(10) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: newsletter [a. Schiermeier-S. <newsletter@Schiermeier-Software.de> - 2009-02-11 02:42:54
|
Hallo Liste, ein wenig googlen brachte mir auf die Fragen von gestern einige Antworten und neue Fragen: es gibt einige Änderungen in den Kernel-Versionen ab ca. 2.6.26, deshalb funktioniert so einige erst nach folgenden Änderungen: 1.) Datei: emx_net.c und emx_user_list.c alt: #include <asm/semaphore.h> neu: #include <linux/semaphore.h> 2.) Datei: emx_user.c alt: class_device_create() neu: device_create() und alt: class_device_destroy() neu: device_destroy() 3.) Datei: emx_net.c in der Funktion 'emx_init()' steht: dev->hard_header_cache = NULL; Das hab ich stumpf auskommentiert, da es diese Funktion angeblich nicht mehr gibt (sagt der Kompiler) dann war der Kompiler zufrieden. Den Treiber laden konnte ich trotzdem nicht, beim zweiten Versuch ist mir der Rechner 'um die Ohren geflogen' will sagen: eingefroren. Da die ursprünglichen Entwickler nicht mehr aktiv sind, habe ich die Hoffnung, daß vielleicht jemand diese Nachricht liest, und mir einen Tipp geben kann, was bei mir falsch läuft. dmesg sagt das hier: ---<Zitat>--- eumex: Driver version: v0.2.1-cvs eumex: No eumex device connected. usbcore: registered new interface driver eumex ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:462 sysfs_add_one+0x4c/0x50() sysfs: duplicate filename '252:0' can not be created Modules linked in: eumex(+) appletalk ax25 ipx p8023 binfmt_misc radeon drm ppdev lp xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE xt_DSCP ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables ext3 jbd mbcache nls_utf8 nls_cp437 vfat fat nls_iso8859_15 ntfs nls_base dm_crypt visor usbserial fuse powernow_k8 freq_table ns558 rtc_cmos rtc_core gameport snd_intel8x0 rtc_lib snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy pcspkr psmouse serio_raw evdev snd_seq_oss snd_seq_midi snd_rawmidi k8temp snd_seq_midi_event snd_seq snd_timer snd_seq_device shpchp snd pci_hotplug soundcore snd_page_alloc parport_pc parport i2c_nforce2 button i2c_core reiserfs dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sd_mod sg sr_mod cdrom ata_generic floppy pata_amd pata_acpi sata_sil firewire_ohci firewire_core crc_itu_t r8169 mii libata scsi_mod ehci_hcd ohci_hcd usbcore ssb pcmcia pcmcia_core thermal processor fan Pid: 5279, comm: insmod Not tainted 2.6.28-0.slh.3-sidux-amd64 #1 Call Trace: [<ffffffff8024d45d>] warn_slowpath+0xcd/0x110 [<ffffffff8033b78d>] sysfs_addrm_finish+0x1d/0x260 [<ffffffff804eb735>] _spin_unlock+0x5/0x30 [<ffffffff8033b396>] __sysfs_add_one+0x16/0xd0 [<ffffffff8038cff4>] idr_get_empty_slot+0x114/0x2d0 [<ffffffff802d7b2b>] kmem_cache_alloc+0x8b/0xe0 [<ffffffff8033af50>] sysfs_ilookup_test+0x0/0x10 [<ffffffff8033b1fd>] sysfs_find_dirent+0x2d/0x40 [<ffffffff804eb735>] _spin_unlock+0x5/0x30 [<ffffffff8033b49c>] sysfs_add_one+0x4c/0x50 [<ffffffff8033c4bb>] sysfs_do_create_link+0xeb/0x170 [<ffffffff8041dc00>] device_add+0x230/0x630 [<ffffffff8038de14>] kobject_init+0x34/0xb0 [<ffffffff8041e11a>] device_create_vargs+0xfa/0x110 [<ffffffffa0053000>] usb_emx_init+0x0/0x78 [eumex] [<ffffffff8041e16a>] device_create+0x3a/0x50 [<ffffffff8038e352>] kset_register+0x52/0x60 [<ffffffff80420f48>] __class_register+0x158/0x1f0 [<ffffffff8042103f>] __class_create+0x5f/0xa0 [<ffffffffa0053000>] usb_emx_init+0x0/0x78 [eumex] [<ffffffffa0562897>] emx_user_register+0x57/0x100 [eumex] [<ffffffffa005302b>] usb_emx_init+0x2b/0x78 [eumex] [<ffffffff8020a042>] do_one_initcall+0x42/0x1c0 [<ffffffff80278d1f>] load_module+0x189f/0x1c40 [<ffffffff802e0d60>] cdev_del+0x0/0x20 [<ffffffff80279255>] sys_init_module+0xb5/0x1e0 [<ffffffff8021350a>] system_call_fastpath+0x16/0x1b ---[ end trace 9539cde1719f180b ]--- usbcore: deregistering interface driver eumex Eumex driver register char device status: -1 ---</Zitat>--- Die Anlage war nicht angeschlossen, wenn das der Fall ist, friert der Rechner ein. Den Treiber müßte ich doch auch ohne Anlage laden und ggf. entladen können, oder? uname -a: Linux Schiermeier 2.6.28-0.slh.3-sidux-amd64 #1 SMP PREEMPT Mon Dec 29 11:04:55 UTC 2008 x86_64 GNU/Linux Falls jemand ne Idee hat, was hier verkehrt ist, dann schreib doch mal. Ich werds weiter testen, ggf. auch mit Anlage dran. Bis demnächst! -- Gruss von Joerg Schiermeier =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joerg Schiermeier * staatl. gepr. Informatiker und EDV-Trainer Schiermeier-IT * IT-Beratung, Software-Entwicklung und Schulung Post: Postfach 10 24 28 * 33524 Bielefeld Büro: Friedrichstrasse 51 * 33615 Bielefeld fon(g): (0521) 521 88 66 * fax/sms: (0521) 521 88 67 VoIP: (0521) 44 69 008 * e.Mail(g): info@Schiermeier-Software.de =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
From: Marcus H. <mar...@he...> - 2008-11-16 12:52:59
|
Hallo zusammen, ich versuche krampfhaft meine irgendwann mal unter Windows konfigurierte Eumex 504 PC USB unter Ubuntu zum Laufen zu kriegen. Sie wird mit "lsusb" auch erkannt. Ist ja schon mal ein Anfang. Nur die Alternativ-Treiber lassen sich nicht installieren. Auszug aus der Liesmich.txt: Installation ============ Überprüfen, ob die benötigten Kernelmodule geladen sind ------------------------------------------------------- Überprüft zuerst mit "lsmod", ob der Kernel USB-Unterstützung bietet. Dazu müssen die Module usbcore sowie mindestens eines der Module uhci_hcd oder ohci_hcd geladen sein. Alternativ: Compiliere die USB-Unterstützung, zusammen mit dem passenden USB-Hostcontroller-Treiber in den Kernel ein. Wenn man vor hat, sich mit der Anlage z.B. ins Internet einzuwählen, wird zusätzlich ISDN4Linux benötigt. Dazu sollte überprüft werden, daß das isdn- Modul geladen ist und die Module capi, capifs und kernelcapi enladen sind, bzw. das die I4l-Unterstützung in den Kernel eincompiliert wurde. Compilieren und installieren ---------------------------- Nach dem Entpacken des Quelltextes mit tar -xvzf eumex-0.1.1.tar.gz bzw. mit tar -xvjf eumex-0.1.1.tar.bz2 kannst du mit cd eumex-0.1.1 in das Verzeichnis wecheln, in dem der Paketinhalt entpackt wurde und die übliche Standardinstallation wie folgt durchführen: ./configure make su make install Das sollte ausreichen, um den Treiber zu compilieren und installieren. Sollten die Kernelquellen nicht gefunden werden, kann man mit --with-kernel-dir= das passende Verzeichnis angeben. Danach sollten sich die Module mit "modprobe eumex" und optional "modprobe eumex_i4l" laden lassen. so funktioniert das aber leider nicht. Hat jemand Erfahrung damit? Freue mich über jeden Tip. Gruß Marcus |
From: Christoph H. <chr...@we...> - 2007-04-21 11:31:24
|
Meine sehr verehrten Herren, mit dieser eMail m=F6chte ich m=F6glichst alle, die sich schon mal mit de= r Treiberunterst=FCtzung von Eumex-Telefonanlagen besch=E4ftigt haben, erreichen. Wenn Sie also weitere Betroffene kennen, bitte weiterleiten! Es geht sich um folgendes: Ich besitze eine Eumex 5000 (oder Agfeo AC 14 Webphonie) und ich h=E4tte zu gerne einen Treiber f=FCr Linux. Nun erw=E4ge ich selbst ein Projekt b= ei Sourceforge o. =E4. zu starten, bin aber eher der Ingenieur als der Programmierer. Somit w=FCrde ich mich freuen, wenn von Ihrer Seite aus Interesse besteht, und Sie mich in Ihr Projekt aufnehmen. Falls kein Interesse im Rahmen des eigenen Projekts besteht bitte ich Sie aber doch, sich f=FCr weitere Fragen (vielleicht auch telefonisch) zu= r Verf=FCgung zu stellen. Beispielsweise w=FCrde mich interessieren, ob Ihr beim Reverse-Engineerin= g auch den Aufbau der Anlagen beachtet (unter http://sourceforge.net/forum/message.php?msg_id=3D2044278 nicht erw=E4hnt= ). Die Eumex 5000 hat beispielsweise USB-seitig einen *Philips PDIUSBD12 **Peripheral Controller mit 8-bit parallelem Bus **der mit einem AMD **Am188 ES* *16-bit Microcontroller* kommuniziert. Somit m=FCsste man doc= h mithilfe der erh=E4ltlichen Schnittstellen-Spezifikationen, Code-Beispiel= e und der Firmware schon viel erschlagen k=F6nnen ohne den USB-Port abzuh=F6ren, oder? Wie habt Ihr das gel=F6st, oder ist in den alten Tk-Anlagen keine so komfortable Elektronik verbaut? Viele Gr=FC=DFe Christoph Hackstein |
From: Michael H. <hu...@li...> - 2006-11-05 10:35:21
|
Hallo, vor kurzem bin ich (wieder) auf ISDN umgestiegen und habe meine alte Eumex 504 reaktiviert. An dieser Stelle erstmal vielen Dank an die Entwickler rund um http://eumex.sourceforge.net/ Die CVS-Version lies sich auf meinem Debian-System mit Kernel 2.6.16-2-686 mit einem sehr kleinen Patch (hängt an der Mail) problemlos kompilieren und in Betrieb nehmen: Eumex USB Driver v0.1.2-cvs [...] eumex: Found Eumex 504PC USB or EuraCom 140 USB. Danach kann ich mit "emxconf" die Konfiguration der Anlage auslesen, bearbeiten und zurückspielen. Wenn ich mich mit meinem Mobiltelefon selber anrufe, so erhalte ich auch erfreuliche Statusmeldungen im syslog: eumex_i4l: DRV->I4L: Incoming call: 1746396xxx to 6766xxx; eumex_i4l: Service indicator: 1 isdn_net: call from 1746396xxx -> 0 6766xxx ignored isdn_tty: call from 1746396xxx -> 6766xxx ignored eumex_i4l: Channel 0 freed because I4L rejected the incoming call Am meisten bin ich jetzt dran interessiert, Informationen über eingehende Anrufe z.B. per Pop-Up-Meldung angezeigt zu bekommen. Es ist wohl ohne weiteres möglich, so etwas mit dem "isdnlog" Paket zu realisieren, allerdings setzt "isdnlog" auf ein proprietäres(?) Interface des Hisax-Treibers auf, so dass es mit dem Eumex-I4L-Treiber nicht nutzbar ist. Ist das richtig? Falls nicht, kann mir jemand mitteilen, wie man "isdnlog" mit dem Eumex-I4L-Treiber zum laufen bekommt und hat für mich eine Beispielkonfiguration parat? Falls ja, gibt es "richtige" I4L-Applikationen, die die notwendigen Informationen mit dem I4L-API auslesen und dann zur Verfügung stellen? Bin auch für jeden Hinweise in Richtung I4L-Programmierung dankbar. CU Michael. |
From: Fabian M. <em...@tp...> - 2005-10-28 04:37:21
|
Hallo Leute! So, Kernel 2.6.14 ist jetzt offiziell drau=DFen, ich compiliere den Treiber dann gleich mal dagegen um zu sehen, ob sich nach dem rc2 noch was getan hat, was den Treiber betrifft. Vielleicht hat ja schon der eine oder andere davon gelesen, jedenfalls ist das ein extra f=FCr Kernelzwecke neu geschriebener C-Checker im Stil eines erweiterten indent. Das Programm vom git (http://kernel.org/git/) zu holen ist ja noch das kleinere Problem gewesen, wenn man das =FCbersetzt hat, gibt es diverse Beispielptogramme f=FCr die libsparse, nur kein sparse-Programm! Daf=FCr darf man erst mal im Netz rumsuchen um rauszufinden, da=DF man check nach sparse umbenennen mu=DF. N=E4heres siehe auch unter http://www.xenotime.net/linux/doc/sparse_howto.txt Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-10-26 20:29:42
|
Hallo Leute! Nachdem ich neulich das Protokoll schon von Hand neu zerlegt hatte und die wahre Bedeutung der 2. Sequenznummer herausgefunden habe, ist mir gestern mal wieder mein alter Ausdruck der X.75-Spec in die H=E4nde gefallen. Den hab ich dann mal in Ruhe und von vorn (hatte bisher in der Mitte und =FCberall mal etwas gelesen und zumindest herausgefunden, das er teilweise zutrifft) gelesen und siehe da, ich bin jetzt schlauer was das serielle Protokoll angeht. :-) Also das serielle Protokoll ist X.75 Single Link Procedure (SLP) im non-extended Mode (mod 8) mit 3E als Flags, der Bytesumme als FCS, ohne Adressfeld und mit 3 als h=F6chster Sequenznummer. FRMR scheint die Anlage scheinbar nicht zu kennen, aber ich provoziere da noch mal die entsprechenden Fehler, um es wirklich zu wissen. Der unumbered Frame C4 (Keep Alive) ist frei erfunden und dient scheinbar als Ersatz f=FCr das normalerweise geforderte synchrone Verhalten. Das Protokoll ist relativ simpel, wenn man erst mal alle Verweise etc. in der Spec aufgel=F6st hat. Es gibt 2 m=F6gliche Verbindungsarten, wovon aber jeweils nur eine aktiv sein kann, einmal mod 8, welcher durch SABM aktiviert wird und der extended Mode, der durch SABME aktiviert wird. SABME (also mod 128) kann die Anlage nicht, deshalb auch die entsprechende Meldung in der Firmware, von der ich mich bisher hab t=E4uschen und verwirren lassen. Wenn man das erst mal weis, kann man ja auch die Implementierungs- beschreibung zum gro=DFen Teil benutzen, denke ich, welche immerhin vorhanden ist. Werde mir mal bei Gelegenheit die neuste Version der Spec beschaffen, denn das Adressfeld macht imho nicht wirklich Sinn, vielleicht ist es ja auch dann rausgeflogen, gegen=FCber der Vorabversion 3/93 auf welche ich mich hier beziehe. Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-10-08 18:24:30
|
On Mon, 03 Oct 2005 19:40:14 +0200 Per Jessen <pe...@co...> wrote: > Fabian Melzow wrote: > > HTTP request sent, awaiting response... 404 Not Found > > 17:46:26 ERROR 404: Not Found. >=20 > Sorry - http://jessen.ch/files/configurator.jar.orig Nach meiner Grobanalyse (nicht decompiliert) habe ich da recht schnell festgestellt, das sie die Konfiguration =FCber HTTP machen, sprich es werden im Unterschied zum Konfigurator keine nativen Eumex-Kommandos benutzt. War zu erwarten nach den selbigen Verhalten beim=20 Testfeature "704 LAN Webinterface". Soll hei=DFen, das die Funktionen der Nachfolger zum Teil schon, zumindest= =20 ansatzweise, zum testen in den Vorg=E4ngern zu finden sind. Das=20 nicht dokumentierte Webinterface der 704 LAN ist wie das =FCberfl=FCsige STP eines davon. Zum Teil kommen die Sachen auch als Zusatzfunktionen im=20 Servicemen=FC daher wie z.B. beim Sinus 62. Gru=DF Fabian |
From: Per J. <pe...@co...> - 2005-10-03 17:34:20
|
Fabian Melzow wrote: > fabi@p0b:~$ wget http://jessen.ch/files/configuration.jar.orig > --17:46:26-- http://jessen.ch/files/configuration.jar.orig > =3D> `configuration.jar.orig' > Resolving jessen.ch... 217.8.216.11 > Connecting to jessen.ch|217.8.216.11|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 17:46:26 ERROR 404: Not Found. Sorry - http://jessen.ch/files/configurator.jar.orig /Per Jessen, Z=FCrich |
From: Fabian M. <em...@tp...> - 2005-10-03 17:04:50
|
On Mon, 03 Oct 2005 08:45:42 +0200 Per Jessen <pe...@co...> wrote: > Fabian Melzow wrote: >=20 > > Kannst du mir das Applet mal schicken, dann kann ich es mal noch > > genauer ansehen. >=20 > Du kannst's dir hier holen http://jessen.ch/files/configuration.jar.orig fabi@p0b:~$ wget http://jessen.ch/files/configuration.jar.orig --17:46:26-- http://jessen.ch/files/configuration.jar.orig =3D> `configuration.jar.orig' Resolving jessen.ch... 217.8.216.11 Connecting to jessen.ch|217.8.216.11|:80... connected. HTTP request sent, awaiting response... 404 Not Found 17:46:26 ERROR 404: Not Found. > Ich habe's aber schon teilweise "gefixxt" - Ich wollte mal sehen was ich da so =FCber die benutzen Kommandos und vielleicht noch anderes Interessantes raus holen kann. Das ist=20 auch leichter in der Firmware zu lokalisieren, wenn eine Vorlage hat. > und mit noch ein Paar kleine Tricks habe ich das auch zum laufen > gekriegt. Nur noch nicht vom topC503 aus ... wenn ich jetzt bloss > wusste wie ich das configurator.jar im TopC503 updaten koennte. Dazu mu=DF man das Applet innerhalb der Firmwaredatei ausfindig machen und austauschen. Die L=E4nge der Ersetzen Daten darf sich dabei nat=FCrlich nicht =E4ndern, d.h. wenn das Applet durch die =C4nderungen gr= =F6=DFer geworden ist, mu=DFt du noch was optimieren, damit es wieder pa=DFt. Wenn es kleiner ist, kann man ja F=FCllbytes am Ende einf=FCgen. Nat=FCrlich gibt es dann sicher noch den =FCblichen CRC32, wobei ich nicht = wei=DF, wo er sich in der Firmware genau befindet. Offset 0x2c sieht aber sehr verd=E4chtig danach aus. :-) Dort wurden scheinbar nur ein paar String= s, die Anlagen-ID, ein Timestamp, der Dateiname etc. am Anfang eingef=FCgt.=20 Genauer gesagt wurden einige Sachen nach vorne verlegt, was dann auch best=E4tigt, das man die Firmware (die 724 l=E4uft =FCbrigens auf dem Nucle= us RTOS), so wie sie ist, dort uploaden kann. Wie kommt man an den richtigen CRC32? Na ganz einfach: Man nehme eine normale, unver=E4nderte Firmware und lade sie hoch. Da schreibt man sich den freundlicherweise ausgegebenen CRC32 auf. Danach dann die Firmware mit dem falschen CRC-Wert hochladen und wenn sie abgelehnt wird, schreibt man sich den Sollwert auf und benutzt anschli=DFend seinen Lieblingshexeditor. Zuerst sucht man in der Orginaldatei nach dem richtigen Wert (32 bit, LE) und wenn man den dann hat, schreibt man sich den Offset auf und macht dann die neue Firmware an dieser Stelle entsprechend passend. Und man es falsch gemacht hat, kann man seine Anlagen hinterher in die M=FClltonne werfen oder man l=F6tet den Flash zum wiederherstellen aus, was wohl angeblich auch sch= on von Leuten gemacht wurde. Gru=DF Fabian |
From: Per J. <pe...@co...> - 2005-10-03 06:39:39
|
Fabian Melzow wrote: > Kannst du mir das Applet mal schicken, dann kann ich es mal noch > genauer ansehen. Du kannst's dir hier holen http://jessen.ch/files/configuration.jar.orig Ich habe's aber schon teilweise "gefixxt" - Anstatt: String s =3D "com.sun.java.swing.plaf.windows.WindowsLookAndFeel"; UIManager.setLookAndFeel(s); habe ich=20 UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); und mit noch ein Paar kleine Tricks habe ich das auch zum laufen gekriegt. Nur noch nicht vom topC503 aus ... wenn ich jetzt bloss wusste wie ich das configurator.jar im TopC503 updaten koennte. /Per Jessen, Z=FCrich |
From: Fabian M. <em...@tp...> - 2005-10-02 20:13:50
|
On Sat, 01 Oct 2005 16:44:45 +0200 Per Jessen <pe...@co...> wrote: > Es ist zwar kein Problem das Applet von Firefox aus zu starten, aber wie > gesagt kriege ich dann nur'ne leere Fenster. Wenn ich es aber mit > appletviewer starte, sehe ich: >=20 > javax.swing.UnsupportedLookAndFeelException: [The Microsoft Windows Look > and Feel - com.sun.java.swing.plaf.windows.WindowsLookAndFeel] not > supported on this platform >=20 > Naja. Haette ich mir wohl denken koennen ... So viel zur Plattformunabh=E4ngigkeit von Java... :-( War ja nicht anders zu erwarten, als das sie nur an Windows denken, bzw. plattformspezische Funktionen benutzen, damit der DAU sich auch zurecht findet. Ich frage mich dann nur, warum sie in diesem Fall nicht bei ihren 3 Konfigurationsprogrammen (95/98/NT) geblieben sind. *g* Kannst du mir das Applet mal schicken, dann kann ich es mal noch genauer ansehen. Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-10-02 18:55:16
|
On Fri, 30 Sep 2005 12:56:14 +0200 Per Jessen <pe...@co...> wrote: > Fabian Melzow wrote: >=20 > > Das freut uns. Hoffentlich kommen dort nicht auch ab und zu Pakete mit > > falscher Headerl=E4nge (Off-by-one), wie bei den 604/704 Anlagen. =20 >=20 > Leider doch: > eumex: frame2data: invalid frame header value for data length: is: 58 > bytes, but should be: 59 Naja, der Fehler wird im Treiber von korrigiert, in Version 0.1.0 gabs da auch noch eine entsprechende Meldung, jetzt kommt die nur noch bei aktiviertem Debugging, dadursch kann der syslogd die gleiche Meldung als Zahl hochz=E4hlen und das landet 250+ mal im syslog. > >> Ich moechte den C503 Konfiguration Manager auf eine andre Workstation > >> starten, was mir zur Zeit noch nicht gelungen ist. Anscheinend > >> braucht der C503 einen default Route das auf meine lokal Netz > >> (192.168.2.0) zeigt. > >=20 > > Nein, du mu=DFt nicht zwangsl=E4ufig die Defaultroute auf die Anlagen-IP > > setzen, es reicht die richtige Netzmaske f=FCr das Netz der Anlage zu > > setzen. >=20 > Aber wenn der C503 zum beispielt nicht ans 192.168.2.0 Netz > angeschlossen ist, braucht er doch eine default oder eine > Netz-spezifische Route (von 192.168.70 ins 192.168.2) oder? In der Konfiguration wie unter ja.=20 > > Soweit ich weis, benutzen sie ein Java-Applet, das =FCber den internen > > Webserver, verteilt wird zur Konfiguration, die Frage ist nur, ob du > > es vern=FCftig ans laufen bekommst und wor=FCber die Kommunikation mit = der > > Anlage erfolgt, sofern das nicht mit "Eumex-Protokoll =FCber TCP" gel= =F6st > > wurde, kommen da dann noch HTTP-Requests in Frage (sieht man ja schon > > in der Webinterface-Preview bei der 704 LAN... ;-)). >=20 > Wenn keine andere Anbindung als ueber ethernet-USB bestehen, geht's > einfach nicht anders - so weit ich's verstanden habe. Ob dann HTTP > oder das Eumex-Protokoll ueber TCP benutzt wird ist egal. Nein, das ist ein Unterschied! USB ist hier nur das Transportmedium f=FCr die Ethernetframes. Das Web-Interfcae der Eumex 704 LAN benutzt spezielle String-Variablen und normale HTTP POSTs. Der Windows-Ethernet- ISDN-Treiber benutzt aber eine normale TCP-Verbindung =FCber die die =FCblichen spezifischen "bin=E4ren" Eumexkommanos gesendet werden. > >> (Und forwarding ist enabled). > >=20 > > Wie, fungiert dort eine Kiste als Router oder was? >=20 > Jawohl. Ich versuche's mal zu erklaeren:=20 >=20 > C503 <---USB---> PC1 <---> ethernet <---> verschiedene andere PCs und > Servern. =20 >=20 > PC1 steckt also zwischen das C503 "Netzwerk" auf 192.168.70 und mein > B=FCro-Netzwerk auf 192.168.2 und routet zwischen die beide. Das sollte eigentlich keine Probleme machen, wenn das Forwarding auf PC1 aktiviert ist und du eine passende (Default)route auf die C503 gesetzt hast. Die evtl. n=F6tige Fragmentierung wegen der anderen MTU f=FCr PPPoE sollte= =20 eigentlich PC1 machen. Gru=DF Fabian |
From: Per J. <pe...@co...> - 2005-10-02 18:46:17
|
Per Jessen wrote: >> Soweit ich weis, benutzen sie ein Java-Applet, das =FCber den internen >> Webserver, verteilt wird zur Konfiguration, die Frage ist nur, ob du >> es vern=FCftig ans laufen bekommst und wor=FCber die Kommunikation mit >> der Anlage erfolgt, sofern das nicht mit "Eumex-Protokoll =FCber TCP" >> gel=F6st wurde, kommen da dann noch HTTP-Requests in Frage (sieht man >> ja schon in der Webinterface-Preview bei der 704 LAN... ;-)). >=20 > Wenn keine andere Anbindung als ueber ethernet-USB bestehen, geht's > einfach nicht anders - so weit ich's verstanden habe. Ob dann HTTP > oder das Eumex-Protokoll ueber TCP benutzt wird ist egal. Es ist zwar kein Problem das Applet von Firefox aus zu starten, aber wie gesagt kriege ich dann nur'ne leere Fenster. Wenn ich es aber mit appletviewer starte, sehe ich: javax.swing.UnsupportedLookAndFeelException: [The Microsoft Windows Look and Feel - com.sun.java.swing.plaf.windows.WindowsLookAndFeel] not supported on this platform Naja. Haette ich mir wohl denken koennen ... /Per Jessen, Z=FCrich |
From: Fabian M. <em...@tp...> - 2005-10-02 16:44:55
|
On Fri, 30 Sep 2005 12:56:14 +0200 Per Jessen <pe...@co...> wrote: > Fabian Melzow wrote: >=20 > > Das freut uns. Hoffentlich kommen dort nicht auch ab und zu Pakete mit > > falscher Headerl=E4nge (Off-by-one), wie bei den 604/704 Anlagen. =20 >=20 > Leider doch: > eumex: frame2data: invalid frame header value for data length: is: 58 > bytes, but should be: 59 Naja, der Fehler wird im Treiber von korrigiert, in Version 0.1.0 gabs da auch noch eine entsprechende Meldung, jetzt kommt die nur noch bei aktiviertem Debugging, dadursch kann der syslogd die gleiche Meldung als Zahl hochz=E4hlen und das landet 250+ mal im syslog. > >> Ich moechte den C503 Konfiguration Manager auf eine andre Workstation > >> starten, was mir zur Zeit noch nicht gelungen ist. Anscheinend > >> braucht der C503 einen default Route das auf meine lokal Netz > >> (192.168.2.0) zeigt. > >=20 > > Nein, du mu=DFt nicht zwangsl=E4ufig die Defaultroute auf die Anlagen-IP > > setzen, es reicht die richtige Netzmaske f=FCr das Netz der Anlage zu > > setzen. >=20 > Aber wenn der C503 zum beispielt nicht ans 192.168.2.0 Netz > angeschlossen ist, braucht er doch eine default oder eine > Netz-spezifische Route (von 192.168.70 ins 192.168.2) oder? In der Konfiguration wie unter ja.=20 > > Soweit ich weis, benutzen sie ein Java-Applet, das =FCber den internen > > Webserver, verteilt wird zur Konfiguration, die Frage ist nur, ob du > > es vern=FCftig ans laufen bekommst und wor=FCber die Kommunikation mit = der > > Anlage erfolgt, sofern das nicht mit "Eumex-Protokoll =FCber TCP" gel= =F6st > > wurde, kommen da dann noch HTTP-Requests in Frage (sieht man ja schon > > in der Webinterface-Preview bei der 704 LAN... ;-)). >=20 > Wenn keine andere Anbindung als ueber ethernet-USB bestehen, geht's > einfach nicht anders - so weit ich's verstanden habe. Ob dann HTTP > oder das Eumex-Protokoll ueber TCP benutzt wird ist egal. Nein, das ist ein Unterschied! USB ist hier nur das Transportmedium f=FCr die Ethernetframes. Das Web-Interfcae der Eumex 704 LAN benutzt spezielle String-Variablen und normale HTTP POSTs. Der Windows-Ethernet- ISDN-Treiber benutzt aber eine normale TCP-Verbindung =FCber die die =FCblichen spezifischen "bin=E4ren" Eumexkommanos gesendet werden. > >> (Und forwarding ist enabled). > >=20 > > Wie, fungiert dort eine Kiste als Router oder was? >=20 > Jawohl. Ich versuche's mal zu erklaeren:=20 >=20 > C503 <---USB---> PC1 <---> ethernet <---> verschiedene andere PCs und > Servern. =20 >=20 > PC1 steckt also zwischen das C503 "Netzwerk" auf 192.168.70 und mein > B=FCro-Netzwerk auf 192.168.2 und routet zwischen die beide. Das sollte eigentlich keine Probleme machen, wenn das Forwarding auf PC1 aktiviert ist und du eine passende (Default)route auf die C503 gesetzt hast. Die evtl. n=F6tige Fragmentierung wegen der anderen MTU f=FCr PPPoE sollte= =20 eigentlich PC1 machen. Gru=DF Fabian PS: So, noch mal, weil der SF Mailserver scheinbar ein Problem zu haben sch= eint. |
From: Per J. <pe...@co...> - 2005-09-30 10:51:07
|
Fabian Melzow wrote: > Das freut uns. Hoffentlich kommen dort nicht auch ab und zu Pakete mit > falscher Headerl=E4nge (Off-by-one), wie bei den 604/704 Anlagen. =20 Leider doch: eumex: frame2data: invalid frame header value for data length: is: 58 bytes, but should be: 59=20 >> Ich moechte den C503 Konfiguration Manager auf eine andre Workstation >> starten, was mir zur Zeit noch nicht gelungen ist. Anscheinend >> braucht der C503 einen default Route das auf meine lokal Netz >> (192.168.2.0) zeigt. >=20 > Nein, du mu=DFt nicht zwangsl=E4ufig die Defaultroute auf die Anlagen-I= P > setzen, es reicht die richtige Netzmaske f=FCr das Netz der Anlage zu > setzen. Aber wenn der C503 zum beispielt nicht ans 192.168.2.0 Netz angeschlossen ist, braucht er doch eine default oder eine Netz-spezifische Route (von 192.168.70 ins 192.168.2) oder? > Soweit ich weis, benutzen sie ein Java-Applet, das =FCber den internen > Webserver, verteilt wird zur Konfiguration, die Frage ist nur, ob du > es vern=FCftig ans laufen bekommst und wor=FCber die Kommunikation mit = der > Anlage erfolgt, sofern das nicht mit "Eumex-Protokoll =FCber TCP" gel=F6= st > wurde, kommen da dann noch HTTP-Requests in Frage (sieht man ja schon > in der Webinterface-Preview bei der 704 LAN... ;-)). Wenn keine andere Anbindung als ueber ethernet-USB bestehen, geht's einfach nicht anders - so weit ich's verstanden habe. Ob dann HTTP oder das Eumex-Protokoll ueber TCP benutzt wird ist egal. >> (Und forwarding ist enabled). >=20 > Wie, fungiert dort eine Kiste als Router oder was? Jawohl. Ich versuche's mal zu erklaeren:=20 C503 <---USB---> PC1 <---> ethernet <---> verschiedene andere PCs und Servern. =20 PC1 steckt also zwischen das C503 "Netzwerk" auf 192.168.70 und mein B=FCro-Netzwerk auf 192.168.2 und routet zwischen die beide. /Per Jessen, Z=FCrich |
From: Fabian M. <em...@tp...> - 2005-09-29 23:57:26
|
Hallo Leute! > > - mit emxconf ging nicht viel. Ja, mir f=E4llt gerade auf, das da imho nicht mal die eh nicht 100% voll- st=E4ndigen (bezogen auf die 704 LAN+) Routereinstellungen angezeigt werden, weil emxconf zur Zeit nur auf "EUMEX704" in der Anlagen ID checkt (vorher war es "EUMEX704\0"), hatte das ja schon f=FCr die 704 LAN ge=E4nd= ert, weil alte 704 DSL Anlagen benutzen "EUMEX704" neuere Firmware- versionen dann "EUMEX704DSL" und die Eumex 704 LAN "EUMEX704LAN". Naja, jedenfalls gibts es aus diesem Grund seit der vorletzten Version einen ioctl zur Abfrage der PID, denn die Firmwareversion braucht man bei der Konfiguration nur in Ausnahmef=E4llen (z.B. k=F6nnen alle 504er vor Version 1.14 kein SMS im Festnetz). Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-09-29 22:37:14
|
On Thu, 29 Sep 2005 13:00:27 +0200 "Per Jessen" <pe...@co...> wrote: Hallo Per! > bloss'ne kurze Statusbericht ueber eumex treiber 0.1.2 und meine Swisscom > Top C503. =20 F=FCr alle die es nicht wissen, das ist ein 1:1 Klone der Eumex 724. =20 > - Ethernet-over-USB funktioniert tipp-topp. Echt Klasse! Das freut uns. Hoffentlich kommen dort nicht auch ab und zu Pakete mit falscher Headerl=E4nge (Off-by-one), wie bei den 604/704 Anlagen. Das Interessante daran ist ja, das sie den Firmwarebug offenbar kennen (eine=20 Debugmeldung im Win-Treiber deutet darauf hin), aber nicht fixen, weil man ihn ja nicht sieht, also gibt es ihn auch nicht... ;-) > Ich moechte den C503 Konfiguration Manager auf eine andre Workstation sta= rten, was > mir zur Zeit noch nicht gelungen ist. Anscheinend braucht der C503 einen= default > Route das auf meine lokal Netz (192.168.2.0) zeigt. Nein, du mu=DFt nicht zwangsl=E4ufig die Defaultroute auf die Anlagen-IP se= tzen, es reicht die richtige Netzmaske f=FCr das Netz der Anlage zu setzen.=20 Soweit ich weis, benutzen sie ein Java-Applet, das =FCber den internen Webs= erver, verteilt wird zur Konfiguration, die Frage ist nur, ob du es vern=FCftig ans laufen bekommst und wor=FCber die Kommunikation mit der Anlage erfolgt, sof= ern das nicht mit "Eumex-Protokoll =FCber TCP" gel=F6st wurde, kommen da dann n= och HTTP-Requests in Frage (sieht man ja schon in der Webinterface-Preview bei = der 704 LAN... ;-)).=20 > Mindestens kann ich der C503 nur > von der lokalen Workstation aus pingen, aber nicht von eine andere Workst= ation im Netz. Stimmt die Netzmaske auf beiden Kisten und umfa=DFt das Gesamtnetz. Funktio= niert die Ermittlung der MAC-Adresse (arp -a) bzw. arping?=20 > (Und forwarding ist enabled).=20 Wie, fungiert dort eine Kiste als Router oder was? > Zweitens, wenn ich doch den Konfiguration Manager lokal=20 > startet, komme ich bis zum Java Fenster - aber danach bleibt es einfach l= eer. Ob dies jetzt=20 > mit der JVM irgendwas zu tun hat oder nicht ... mal schauen. Ja, Applets werden anders behandelt, f=FCr die Sun JVM z.B., mu=DFt du appl= etviewer benutzen um es au=DFerhalb des Browsers zu starten. > - mit emxconf ging nicht viel. Ja, das fehlen uns die n=F6tigen Daten, siehe Doku. emxconf mu=DF eh mal bei Gelegenheit etwas doller aufger=E4umt werden, weil die Daten f=FCr die 704 = LAN und Eumex 504 SE fehlen auch noch, aber beim Rest kann man nur einbauen, was man an Befehlen kennt. > - was ist mit emxflash und Eumex724 - meint ihr es muesste eigentlich geh= en oder? Prinzipiell mu=DFte das eigentlich schon gehen, aber nicht nicht mit der je= tztigen Version, weil die segfaultet zumindest zum Teil noch, was an der versuchten Firmware=FCberpr=FCfung und den falschen Annahmen, bei Fehlerkennung einer doppelten Firmware liegt. Ja, das wollte ich schon fixen, da=DF ist nur noch nicht ber=FCcksichtigt worden, weil ich bis mir bis vor kurzem nicht ganz s= icher, war ob die Eumex 724 =FCberhaupt noch mit dem Treiber l=E4uft. Zur Version = 0.1.2 hatte ich das dann aber so weit abgecheckt, das ich =FCberzeugt war, das sie und auch die Eumex 620 noch laufen m=FCssten. Nur f=FCr die Eumex 520 sieht= es schlecht aus imho, aber bisher hab ich dazu noch keinen Bericht bekommen. Gru=DF Fabian |
From: Per J. <pe...@co...> - 2005-09-29 11:12:35
|
Hallo=20zusammen, bloss'ne=20kurze=20Statusbericht=20ueber=20eumex=20treiber=200.1.2=20und=20= meine=20Swisscom Top=20C503.=20=20 -=20Ethernet-over-USB=20funktioniert=20tipp-topp.=20=20Echt=20Klasse! Ich=20muss=20noch=20has=20Hotplugging=20einrichten,=20aber=20sonst=20OK.=20= Ich=20moechte=20den=20C503=20Konfiguration=20Manager=20auf=20eine=20andre=20= Workstation=20starten,=20was mir=20zur=20Zeit=20noch=20nicht=20gelungen=20ist.=20=20Anscheinend=20brauc= ht=20der=20C503=20einen=20default Route=20das=20auf=20meine=20lokal=20Netz=20(192.168.2.0)=20zeigt.=20=20Min= destens=20kann=20ich=20der=20C503=20nur von=20der=20lokalen=20Workstation=20aus=20pingen,=20aber=20nicht=20von=20e= ine=20andere=20Workstation=20im=20Netz.=20 (Und=20forwarding=20ist=20enabled).=20=20Zweitens,=20wenn=20ich=20doch=20d= en=20Konfiguration=20Manager=20lokal=20 startet,=20komme=20ich=20bis=20zum=20Java=20Fenster=20-=20aber=20danach=20= bleibt=20es=20einfach=20leer.=20=20Ob=20dies=20jetzt=20 mit=20der=20JVM=20irgendwas=20zu=20tun=20hat=20oder=20nicht=20...=20mal=20= schauen. -=20mit=20emxconf=20ging=20nicht=20viel.=20=20 -=20was=20ist=20mit=20emxflash=20und=20Eumex724=20-=20meint=20ihr=20es=20m= uesste=20eigentlich=20gehen=20oder? ciao, Per=20Jessen,=20Zurich --=20 http://www.spamchek.ch/freetrial=20-=20managed=20anti-spam=20and=20anti-vi= rus=20solution.=20Lassen=20Sie=20sich=20=FCberzeugen=20-=2030=20Tage=20Kos= tenlos! |
From: Fabian M. <em...@tp...> - 2005-09-28 02:30:40
|
Hallo Leute! So, gerade gesehen das sie ne neue Firmware rausgebracht haben. Bei der ist das Rechenleistung fressende und =FCberfl=FCssige (weil momentan ist das Ding ja noch nicht mal nen richtiger Hub, ganz=20 zu schweigen eine Bridge) und nervige Spanning Tree Protocol (STP) ausgemacht. Die Eumex 300 ist =FCbrigens von AVM, da hatte ich mich geirrt. Entpacken der Firmware geht wie =FCblich mit wine und anschlie=DFend cabextract auf das Data.cab, das aus dem XP-Installer herausf=E4llt. Dann noch ein: for i in *; do mv $i `echo $i|sed -r -e "s/(.*F[0-9]+_)//"`; done um umbenennen machen und fertig. Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-09-23 15:12:42
|
On Thu, 22 Sep 2005 02:46:37 +0200 Fabian Melzow <em...@tp...> wrote: Hallo Leute! So, die 0.1.2 ist jetzt fertig. Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-09-22 00:46:50
|
Hallo Leute! So, gerade mal den Treiber gegen 2.6.14-rc2 gebaut und das ging nat=FCrlich nicht ohne kleinen Bugix, weil die USB-Api umgekrempelt wurde und es das URB_ASYNC_UNLINK-Flag nicht mehr gibt. Nach einem Blick in driver/usb/core/= urb.c hat sich das aber zum Gl=FCck nur als DAU-Stopper rausgestellt, denn der Co= de dort ist echt super dokumentiert (diesmal enst gemeint :-)) und das Flag ist sch= on ne Weile veraltet und wurde jetzt entfernt. Nat=FCrlich gabs die deprecated-Wa= rnung nur f=FCr die Leute, die synchrones Unlinken benutzt haben, denn die d=FCrf= en jetzt das neu geschaffene usb_kill_urb() benutzen. Also ist der Treiber jetzt=20 hoffentlich auch mit 2.6.14 lauff=E4hig. Zur Info: in 2.6.14 gibts hauts=E4= chlich neues Zeug f=FCr Protokollspielhinder DCCP (Datagram Congestion Control Protocol = =3D TCP ohne Retransmit =3D UDP mit =DCberlastungskontrolle) und man kann jetzt auc= h noch den TCP-Congestion-Scheduler w=E4hlen, dann ist noch das generische Userspa= ce- Interface =FCber Netlink-Sockets (dieser Sockettyp war in 2.4. schon mal de= precated, weil niemand "ip" und "tc" benutzen wollte, weil die FAQ dazu vor der manpa= ge da war... ;-)) neu. Gru=DF Fabian |
From: Fabian M. <em...@tp...> - 2005-09-21 21:42:23
|
On Wed, 21 Sep 2005 20:11:42 +0200 "M.K." <kun...@vr...> wrote: > Also blieben noch die Spinlocks =FCbrig. Dann habe ich mich an die Schrei= btasklets f=FCr die CMD-, B1- und B2-Daten an USB rangemacht. Diese haben u= rspr=FCnglich so ziemlich gleich ausgesehen, wie die Lesetasklets heute noc= h aussehen: Es gab eine Schleife, die nacheinander die Datens=E4tze aus der= Queue geholt hat und dann ans USB gesendet hat. Ich hoffe mal der sf-Mailman hat deine Mail nicht oben abgebissen. Hab mich schon gewundert, warum du beim schreiben ausgerechnet Einzelbetrie= b machst, weil das geht massiv auf den Datendurchsatz. > Da aber die Schreibfunktion des USB-Subsystem sofort zur=FCckkehrt, auch = wenn der URB noch gar nicht =FCbertragen wurde, gab es Probleme, weil die S= chleife sofort den n=E4chsten Datensatz senden wollte und das USB-Subsystem= streikte. Naja, da mu=DF dann eben der n=E4chste URB her. ;-) Gerade mal einem Blick = auf die URB-API geworfen. So lange Daten zum senden da sind, holt man einfach neue URBs mit= usb_alloc_urb und=20 GPF_ATOMIC und schickt die ab. Der Completion-Handler ist immer der Gleiche= und gibt die URBs einfach immer nur frei (+ evtl. Fehlermeldung). Das Problem ist nur den =DC= berblick dar=FCber zu behalten, was gerade an URBs "unterwegs" ist, weil man mu=DF die ja zur=FCc= kholen k=F6nnen, wenn der Treiber entladen wird. Soll hei=DFen, man braucht noch ne Liste (siehe linu= x/list.h) wo man die=20 Adressen der gerade verschickten URBs reinpackt, damit man die unlinken kan= n. > Also war der n=E4chste Gedanke, in der Schleife einen Spinlock einzubauen= , der die Schreibfunktion des USB-Subsystems besch=FCtzt: Vor dem Aufruf wi= rd der Spinlock besetzt. Kehrt die Funktion zur=FCck, bleibt die Schleife b= eim n=E4chsten Durchlauf an dem Spinlock h=E4ngen, bis dieser vom Completio= n Handler wieder freigegeben wird. Klingt doch logisch, oder? Klar. > Als ich das ausprobieren wollte, hab ich angefangen an meiner geistigen I= ntegrit=E4t zu=20 zweifeln. Wie auch immer ich das angestellt habe, der Spinlock hat nichts b= ewirkt.=20 Nach sehr vielen Tests hab ich dann gefunden, dass Spinlocks in Tasklets ke= ine Wirkung haben! Ist ja echt b=F6se! Das macht aber auch irgendwie Sinn, wenn ich so dr=FCbe= r nachdenke... > Obwohl der Spinlock 10 mal besetzt wird, l=E4uft das Tasklet durch, als o= b es ihn > nicht geben w=FCrde. Warum ist das so? Keine Ahnung! M=F6gliche Erkl=E4rung: Das haben die Kernelentwickler einfach deaktiviert,= weil, wozu noch ein Spinlock im Tasklet, wenn beim Aufruf des Tasklets schon einer aktiv is= t, damit das Tasklet nur einmal l=E4uft wohl auch auf SMP-Systemen. Ein Problem sind= die ganzen=20 Tasklet bla-aktiv-Variablen, die auch au=DFerhalb des Tasklets abgefragt we= rden. Das Problem ist, das die nicht atomar sind und es da b=F6se race condition-Fehl= er geben kann. z.B. Du checkst gerade au=DFerhalb des Tasklets die Variable mit if und der= Wert ist 0 also l=E4uft nicht, nur hat die das gerade aktive Tasklets noch nicht auf 1= gesetzt, weil er eben erst gestartet wurde. Das du au=DFerhalb denkst, das das Tasklet ni= cht l=E4uft, gibts du zum Beispiel dem laufenden Tasklet den beschriebenen Speicher unte= rm Arsch frei und das Tasklet ist schreibt wild in der Landschaft rum. :-( Ist eigentlich kien Problem das zu fixen (atomic_t benutzen), die Frage ist= nur, ob ich nicht wieder die H=E4lfte der Variablen =FCbersehe... Gru=DF Fabian |
From: M.K. <kun...@vr...> - 2005-09-21 18:10:25
|
> das diese Semaphore nicht freigegeben werden konnte. Weil jetzt ist al= les > prima bei mir. und > einen Blick auf die Tasklets geworfen... Huch, wo sind denn die ganzen= Spinlocks, > es sind trotz der vielen Tasklets, kaum welche zu sehen, ist ja echt W= under, das der > Treiber so gut funktioniert, weil ich schon diverse Variablen gefunden= habe, die Nix ist prima! Du willst wissen, wo die ganzen Spinlocks geblieben sind?= ?? Also: Vor langer Zeit, als der Treiber noch mit Threads arbeitete, haben Semap= hore und Spinlocks wunderbar kritische Bereiche gesch=FCtzt. Da war die = Welt noch in Ordnung. Als ich dann alles (so ziemlich alles) auf Tasklets umgestellt habe, sin= d die Semaphore auf der Strecke geblieben, weil sie in Tasklets nicht ei= ngesetzt werden d=FCrfen. Tasklets d=FCrfen ja nicht schlafen, was bei S= emaphoren bekanntlich der Fall ist. Also blieben noch die Spinlocks =FCb= rig. Dann habe ich mich an die Schreibtasklets f=FCr die CMD-, B1- und B= 2-Daten an USB rangemacht. Diese haben urspr=FCnglich so ziemlich gleich= ausgesehen, wie die Lesetasklets heute noch aussehen: Es gab eine Schle= ife, die nacheinander die Datens=E4tze aus der Queue geholt hat und dann= ans USB gesendet hat. Da aber die Schreibfunktion des USB-Subsystem sof= ort zur=FCckkehrt, auch wenn der URB noch gar nicht =FCbertragen wurde, = gab es Probleme, weil die Schleife sofort den n=E4chsten Datensatz sende= n wollte und das USB-Subsystem streikte. Also war der n=E4chste Gedanke,= in der Schleife einen Spinlock einzubauen, der die Schreibfunktion des = USB-Subsystems besch=FCtzt: Vor dem Aufruf wird der Spinlock besetzt. Ke= hrt die Funktion zur=FCck, bleibt die Schleife beim n=E4chsten Durchlauf= an dem Spinlock h=E4ngen, bis dieser vom Completion Handler wieder frei= gegeben wird. Klingt doch logisch, oder? Als ich das ausprobieren wollte= , hab ich angefangen an meiner geistigen Integrit=E4t zu zweifeln. Wie a= uch immer ich das angestellt habe, der Spinlock hat nichts bewirkt. Nach= sehr vielen Tests hab ich dann gefunden, dass Spinlocks in Tasklets kei= ne Wirkung haben! Probier's aus: Irgendwo in einem Tasklet, z.B. im CMD-Tasklet in unserem Treiber: spinlock deklarieren spinlock initialisieren ... int i; ... for (i =3D 0; i < 10; i++) { spinlock besetzen (wei=DF jetzt die Anweisungen nicht auswendig) printk("Test %d\n", i); } ... Obwohl der Spinlock 10 mal besetzt wird, l=E4uft das Tasklet durch, als = ob es ihn gar nicht geben w=FCrde. Warum ist das so? Keine Ahnung! Michael |
From: Fabian M. <em...@tp...> - 2005-09-21 13:48:44
|
On Wed, 21 Sep 2005 13:42:41 +0200 "M.K." <sir...@gm...> wrote: > das Problem mit dem h=E4ngenden rmmod hab ich auch schon gehabt,=20 > allerdings nur mit folgender Konfiguration: > Eumex504 und Suse9.1. Alles andere, also Eumex 604 oder 704 und/oder=20 > Suse9.2 oder Mandrake hat dieses Problem nicht gehabt. Deshalb habe ich=20 > es auf Suse geschoben. Diesen Bug hatte ich ja schon gefunden, das war lag an der Abmelde- reihenfolge in emx_exit(), da ist es ganz entscheidend, das usb_deregister() zum Schlu=DF gemacht wird, ist ja auch logisch, war aber zeitweise nicht so. > Jetzt, da es bei dir auch aufgetreten ist und du=20 > auch noch so hartkn=E4ckig nach einem Bug suchst, hab ich wieder einen=20 > Blick in den Treiber geworfen und siehe da: In emx_disconnect() wird=20 > nach dem Aufruf von emx_delete() ein Semaphor eines NULL-Zeigers=20 > freigegeben. Ich denke, das k=F6nnte der Bug sein, den du schon seit Tage= n=20 > suchst. Ja, das war er nat=FCrlich. Danke. :-) Und das rmmod da hing lag sicher dar= an, das diese Semaphore nicht freigegeben werden konnte. Weil jetzt ist alles prima bei mir. Gru=DF Fabian |
From: M.K. <sir...@gm...> - 2005-09-21 11:41:30
|
Hi Fabian, das Problem mit dem hängenden rmmod hab ich auch schon gehabt, allerdings nur mit folgender Konfiguration: Eumex504 und Suse9.1. Alles andere, also Eumex 604 oder 704 und/oder Suse9.2 oder Mandrake hat dieses Problem nicht gehabt. Deshalb habe ich es auf Suse geschoben. Jetzt, da es bei dir auch aufgetreten ist und du auch noch so hartknäckig nach einem Bug suchst, hab ich wieder einen Blick in den Treiber geworfen und siehe da: In emx_disconnect() wird nach dem Aufruf von emx_delete() ein Semaphor eines NULL-Zeigers freigegeben. Ich denke, das könnte der Bug sein, den du schon seit Tagen suchst. Ich habs schon im CVS korrigiert. Gruß Michael |