PPPoE mit NAT hängt bei Uploads
Hallo Liste, habe seit einiger Zeit ein Problem mit der Internetverbindung (ADSL) - diese hängt zwischenzeitlich immer wieder, wenn die Upload(!)-Bandbreite von PCs im LAN (Masquerading mit iptables/netfilter) hinter der Linux-Maschine (Debian unstable / 2.6.16) gefordert wird. Genauer: Die Linux-Maschine sendet Daten - Ping geht runter auf ~300ms (bei ADSL ohne QoS soweit ja leider normal), aber man kann trotzdem gleichzeitig weitere TCP-Verbindungen nutzen. Hier tritt das Problem nicht auf. Wenn nun aber PCs im LAN über diese Internetverbindung Daten senden, dann _bleibt_ der Ping bei den 40ms (!) und nach ein paar Sekunden (unterschiedlich) ist pppoe-Verbindung für eine kurze Zeitspanne nicht mehr nutzbar, d.h. es können über ppp0 weder Daten gesendet noch empfangen werden. Dieser Zustand hält ca. 3-6 Sekunden an, dann geht es weiter, wie wenn nichts gewesen wäre - mit dem wundersamen Ping von 40ms trotz des laufenden Uploads - bis es dann wieder hängt ... Die pppoe-Verbindung wird dabei durch rp-pppoe 3.8 hergestellt. Wenn nun aber mit Hilfe von rp-pppoe.so (pppd-Plugin) der Kernel-pppoe-Treiber genutzt wird anstatt der RoaringPenguin Software, dann äußert sich das Problem dahingehend, dass die PCs im Lan genau 32768 Bytes senden können und dann einfach mit dem Senden aufhören - mehr passiert dann nicht. Downloads funktionieren mit beiden pppoe-Implementationen auch mit NAT immer einwandfrei. MTU ist auf 1492 gestellt (auch niedrigere Werte sowohl für MTU als auch für MSS bereits probiert), MSS auf 1452 (wenn das rp-pppoe.so-Plugin genutzt wird, ist MSS-Clamping durch den Kernel aktiviert, ansonsten mittels rp-pppoe) Am Anschluss selbst kann es nicht liegen, da die Linux-Maschine ja problemlos Daten senden kann... mit einer FritzBox als NAT-Router tritt das Problem nicht auf - ebenso habe ich auch andere DSL-Modems getestet. Die Netfilter-Regeln habe ich seit einiger Zeit nicht geändert, ansonsten käme nur in Frage, dass seit einem neueren Kernel (= neues Netfilter?), rp-pppoe oder pppd (2.4.4b1) irgendetwas nicht mehr passt / umgestellt werden muss. Komme an dieser Stelle leider nicht mehr wirklich weiter; es wäre echt super, wenn jemand eine Idee hätte :-) Viele Grüße, Christoph
Re: PPPoE mit NAT hängt bei Uploads
Hallo Claus, (Kamp) verlangt eine MTU von 1460. Welchen Provider hast du denn, bzw. was gibt dieser als zu verwendenden MTU Wert an? als Provider nutze ich 1und1, die einen MTU von 1492 empfehlen. Habe bereits weniger (1400) ausprobiert, dann hatte es den Anschein, dass der Upload durch die Clients noch langsamer wurde bzw. mal ein paar Daten durchgekommen sind (~20k/s statt ~66k/s) und es wieder unterbrochen hat. Das Merkwürdige an der Sache ist ja, dass bei der Nutzung des Kernel-PPPoE nicht mehr als 32768 Bytes hochgeladen werden können - die Anzeige (z.B. in Filezilla) bleibt dann einfach stehen Zudem muss es irgendwie mit NAT/dem LAN zusammenhängen, denn die Linux-Maschine selbst hat überhaupt keine derartigen Probleme, wenn von dort aus der Upstream beansprucht wird. Weiterhin höchst interessant ist, dass in dem Fall, wenn von außen beispielsweise durch Putty ein SSH-Tunnel geöffnet wird und durch diesen Daten aus dem LAN übertragen werden (Upload bei pppoe) das Problem _auch_ auftritt - obwohl gar kein NAT stattfindet... Wenn mit rp-pppoe ein Upload aus dem LAN läuft und der Ping trotzdem so ist, wie wenn nichts laufen würde - naja, wie kann das funktionieren ? und wenn die Verbindung danach kurz hängt, holt er da möglicherweise irgendetwas nach, was kurz vorher nicht stattfand und die extreme Verbesserung des Pings bewirkt ? *rätsel* Viele Grüße, Christoph (Folgende Module sind geladen:) Module Size Used by ipt_TCPMSS 3776 1 xt_tcpmss 2272 1 pppoe 12896 0 pppox 3368 1 pppoe ppp_synctty 8256 0 ip_nat_ftp 3008 0 ip_conntrack_ftp7196 1 ip_nat_ftp ppp_deflate 5664 0 zlib_deflate 18496 1 ppp_deflate bsd_comp5408 0 zaphfc 13268 6 zaptel188480 17 zaphfc lp 10432 0 tun10560 1 ppp_async 9728 1 crc_ccitt 1952 2 zaptel,ppp_async ipv6 217664 20 ppp_generic25172 10 pppoe,pppox,ppp_synctty,ppp_deflate,bsd_comp,pp p_async slhc6240 1 ppp_generic ipt_MASQUERADE 3104 1 xt_tcpudp 2976 16 xt_state1888 1 iptable_nat 7524 1 ip_nat 15892 3 ip_nat_ftp,ipt_MASQUERADE,iptable_nat ip_conntrack 48792 6 ip_nat_ftp,ip_conntrack_ftp,ipt_MASQUERADE,xt_st ate,iptable_nat,ip_nat nfnetlink 5944 2 ip_nat,ip_conntrack iptable_filter 2752 1 ip_tables 11160 2 iptable_nat,iptable_filter x_tables 11332 7 ipt_TCPMSS,xt_tcpmss,ipt_MASQUERADE,xt_tcpudp,xt _state,iptable_nat,ip_tables capi 15496 10 capifs 5480 2 capi dm_mod 47892 0 psmouse34248 0 serio_raw 6436 0 evdev 8736 0 parport_pc 31472 1 pcspkr 2948 0 parport31720 2 lp,parport_pc floppy 55628 0 rtc11252 0 ide_cd 35328 0 cdrom 31888 1 ide_cd generic 4164 0 [permanent] sd_mod 16208 4 i2c_piix4 8080 0 fcpci 592728 3 kernelcapi 43616 2 capi,fcpci uhci_hcd 26640 0 e100 31044 0 mii 5056 1 e100 e1000 95796 0 i2c_core 19312 1 i2c_piix4 usbcore 110560 2 uhci_hcd piix8932 0 [permanent] ide_core 111440 3 ide_cd,generic,piix shpchp 39200 0 pci_hotplug24180 1 shpchp intel_agp 20860 1 agpgart29232 1 intel_agp thermal13000 0 processor 21376 1 thermal fan 4452 0 ext3 115880 2 jbd46932 1 ext3 mbcache 7652 1 ext3 3w_9xxx28960 3 scsi_mod 10 2 sd_mod,3w_9xxx
Re: PPPoE mit NAT hängt bei Uploads
Hallo Richard, habe jetzt anstatt linux-image-2.6.16-1-686 das neue Paket linux-image-2.6.16-2-686 installiert. nun läuft es sowohl mit rp-pppoe als auch mit kernel-pppoe problemlos durch; das Problem scheint gelöst tausend Dank für die Hilfe :-)) Viele Grüße, Christoph
PPP-Server
Hallo Liste, ich versuche einen PPP-Einwahlserver mit CAPI und dem PPPD aufzusetzen, was jedoch an der Authentifizierung zu scheitern scheint. Ich habe die Einstellungen für die Verbindungen in der Datei /etc/ppp/peers/dialin gespeichert: --- nodefaultroute 192.168.0.1:192.168.0.60 ms-dns 192.168.0.1 netmask 255.255.255.0 noipx proxyarp sync plugin capiplugin.so msn xx protocol hdlc --- sobald ich den pppd aber starten will, erscheint folgende Fehlermeldung: --- server:/etc/ppp/peers# pppd file /etc/ppp/peers/dialin Plugin capiplugin.so loaded. capiplugin: $Revision: 1.36 $ capiconn: 1.10 pppd: The remote system is required to authenticate itself pppd: but I couldn't find any suitable secret (password) for it to use to do so. pppd: (None of the available passwords would let it use an IP address.) --- Obwohl in der /etc/ppp/pap-secrets ein Benutzername/Kennwort gesetzt ist für die remote-IP: --- test * test 192.168.0.60 --- An was könnte das noch liegen ? Würde gern die Authentifikation der pap-secrets verwenden, oder was evtl. noch besser wäre, nur eine bestimmte linux-systemgruppe in der passwd zulassen. habe es auch mit passwd-authentifikation noch probiert (also login in der /etc/ppp/peers/dialin * * * in pap-secrets), da hatte es funktioniert, jedoch beendete sich der pppd beim [beenden der Verbindung durch die andere ppp-Seite]. Kann man den pppd permanent aktiv lassen, wenn in der /etc/ppp/peers/dialin persist steht ? Dann wäre noch die Frage, wie man das pppd in den Hintergrund schiebt und es beim logout trotzdem noch gestartet bleibt wie man es evtl. beim Systemstart starten kann wäre für ein wenig Hilfe sehr dankbar :-) Mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
mkinitrd kaputt ?
Hallo Liste, da ich auf Kernel 2.6.11.8 aktualisieren wollte, habe ich versucht eine neue initrd zu erstellen: Usage: /usr/sbin/mkinitrd [OPTION]... -o outfile [version] mkinitrd -o initrd.img-2.6.11.8 2.6.11.8 Obwohl die entsprechenden Module ordnungsgemäß unter /lib/modules/2.6.11.8 abgelegt sind, macht mkinitrd einfach nichts. Das outfile wird erstellt, ist aber auch nach 10min noch 0k groß und top zeigt an, dass mkinitrd keine CPU-Kapazität verbrauche, obwohl in der shell (auch nach Drücken von Enter) nur ein Absatz gemacht wird, aber keine neue Eingabemöglichkeit entsteht. mkinitrd scheint also noch zu laufen, aber nichts zu tun. Habe via apt-get die initrd-tools bereits deinstalliert und nochmals installiert, doch das Problem besteht weiter. Unter /etc/mkinitrd/modules ist auch ein Modul eingetragen (3w-9xxx), was in die initrd aufgenommen werden sollte, die mkinitrd.conf habe ich nicht verändert. Weder in der syslog noch in messages ist ein Hinweis zu finden. Was könnte man gegen diese Untätigkeit von mkinitrd tun ? mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Benutzerrechte / Apache
Hallo Liste, Es währe nett, wenn Du zukünftig Zeilen bei 72 Zeichen umbrechen könnet. kein problem...soweit auf outl00k verlass ist, sollte das jetzt gehen *g* 'apache' benötigt 0755 denn ~/public_html muß WORLD-READABLE sein. hmm - soweit ich das verstehe, läuft ja der apache unter debian normalerweise unter www-data/www-data. müsste es dann nicht davon abhängig sein, ob der benutzer www-data rx rechte hat oder nicht ? Wie waers mit einem chgrp www-data und 750 auf dem public_html und +x auf dem home? Wuerde das nicht reichen? naja, dann müsste ich die windows-nutzergruppe im samba groupmap auch auf www-data setzen. Die homedirs der unix-user sind gleichzeitig die homedirs der nutzer der samba-windows-domäne. alle nutzer sind momentan in der gruppe smbusers, welche dann im samba groupmap auf die windows-nutzer gemappt ist. da es auch samba freigaben gibt, die alle benutzer verwenden und bei denen über das s-bit geregelt ist, dass von samba erstellte dateien auch zu smbusers gehören, würde das ganze bei einer änderung der gruppe vielleicht etwas kompliziert werden ... Allerdings habe ich mir ein INIT script geschrieben das beim booten nachsiht, welcher $USER ein ~/public_html hat und dann symlinks nach /var/www/$USER anlegt. Alte nicht existierende Links werden automatisch entfernt. Alles was Du noch erlauben mußt ist, das 'apache' symlinks folgen darf. Im Apache ist direkt ~/ das homedir freigegeben (natürlich mit .htaccess schutz). Die Lösung mit den symlinks - ginge es vielleicht, den apache unter user www-data gruppe smbusers laufen zu lassen, in /var/www/benutzer1 einen link nach /home/benutzer1 anzulegen, mit eigentümer www-data, gruppe root, chmod 700, zu dem der apache ja dann zugang hätte (weil er ja unter user www-data läuft), die Benutzer aber nicht ? geht es, dass dann dass das homeverz. selbst weiterhin trotzdem mit chmod 700 läuft, der apache unabhängig davon über den symlink trotzdem in die verzeichnisse reinkommt ? Die Dateien in den homedirs dann aber mit chmod 750, sodass der apache, der ja unter gruppe smbusers läuft, leserechte hat ? Ist vielleicht eine etwas außergewöhnliche lösung, aber vielleicht funktioniert es ja - nur ob es wirklich sicher ist, weiß ich nicht *g* mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Benutzerrechte / Apache
Hallo Liste, ich versuche seit einiger Zeit, homedirectories mit jeweils dem chmod 700 im apache verfügbar zu machen. das problem, welches ich dabei habe, ist, dass die benutzer untereinander nicht in gegenseitige homedirs kommen sollen, also benutzer 1 darf keine leserechte im homedir von benutzer 2 haben, obwohl beide in derselben gruppe sind; deswegen eigentlich chmod 700. Nun muss der apache aber jaauch unter genau demselben benutzer laufen, um zugriff auf die dateien im jeweiligen homedir zu haben. also habe ich einfach mal SuExec ausprobiert, was aber nur für /var/www als SuExec-dir kompiliert ist (im debian paket), woraufhin ich einen symbolischen link von /var/www nach /home angelegt habe. Dann einen vHost mit DocRoot /var/www/benutzer1 und "user benutzer1" "group gruppe1". Dass SuExec mit symbolischen Links von Verzeichnissen funktioniert, habe ich mehrfach ergooglen können, denke, dass das schon so sein wird. - aber leider funktioniert es nicht. der Apache gibt immernoch "Permission denied" zurück, obwohl var, www und benutzer1 von benutzer1 les-und ausführbar sind. Ich vermute mal, dass SuExec nicht für den apache-prozess wirksam ist, sondern nur für die scripts, welche dieser ausführt - also würde suexec in diesem fall nicht allzuviel bringen. Gibt es denn eine möglichkeit, den apache _selbst_ zb bei bestimmten directorys oder vhosts unter einem anderen Benutzer auszuführen ? oder einen anderen lösungsweg noch ? ich komme jedenfalls nicht mehr weiter - wäre für etwas Hilfe sehr dankbar :-) mfg Christoph
Sarge/Win2k parallel auf Via sata-software-Raid 1 ?
Hallo Liste, da es für den vt6420 sata-raid controller von via nur treiber für kernel 2.4.x gibt, bleibt unter 2.6.x nichts anderes übrig, als den libata treiber / sata_via zu verwenden, was ja mit einer Festplatte auch kein Problem wäre. Ich habe 2 Festplatten im Raid 1 Verbund (werden unter Windows durch den orginal VIA Treiber nur als eine erkannt), aber sata_via erkennt beide Platten, also die Festplatten einzeln und nicht das Raid array. Wenn man nun das Kernel-Raid-1 verwendet, dürfte es ja eigentlich kein Problem sein, die Daten gleichzeitig auf beide Platten zu schreiben. Doch - und das ist mein Problem - würde das das Via-Raid-Array, das der Win-Treiber verwendet, zerstören ? Wenn der Rechner mal nicht ordentlich heruntergefahren wurde etc. kommt beim Booten immer die Controller Meldung zum neu-spiegeln, was ja vermutlich daran liegt, dass der Festplatteninhalt nicht identisch ist. Besteht diese Gefahr auch, wenn man mit Kernel Raid 1 auf die Platten schreibt ? Hat da jemand Erfahrungen ? mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Samba trennt Verbindung
Hallo Liste, 1. vielleicht liegt es an deinem Timer-Chip (dein Datum ist falsch!) lol, das kann tatsächlich sein *g* mein Datum ist öfters falsch, brauche ab und zu zu einem Datum den Wochentag, schaue im Kalender, stelle monat etc. passend ein um zu schauen und vergesse dann zurückzustellen ;-) mir ist da bisher noch kein zusammenhang aufgefallen, aber jetzt, als du es sagst, seit ich das letzte mal wieder das Datum korrigiert hatte, funktioniert es wieder, könnte tatsächlich passen vom korrekturzeitpunkt her *g* wäre da nie alleine daraufgekommen, dass das zusammenhängt - hätte ewig gerätselt, daher vielen Dank für deinen Tipp :-) mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Kernel emulieren
Hallo Liste, ich suche seit einger Zeit ein neueres Kernelmodul, als die alten 2.2.x Module um die Eumex PC 504 USB unter kernel 2.4 bzw 2.6 zu betreiben. Leider blieb meine Suche bisher erfolglos, was vermutlich daran liegt, dass es keinen aktuelleren Treiber gibt. Nun frage ich mich, ob es denn möglich ist, unter Linux 2.4.x bzw. 2.6.x einen alten Linux 2.2.x Kernel zu emulieren und damit dann den Treiber zu laden. Zugegeben, der Gedanke ist etwas bizarr, doch ist so etwas vielleicht doch möglich ? mfg Christoph ___ Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: mISDN Capi
hallo liste, Ja, tue ich auch für die misdn Kernel. Aber ich hatte grad noch eine grössere Suche im Netz bzgl. CAPI und da hab ich keine einzige Seite gefunden die bestätigte, dass Faxe schicken mit passiven Karten funktioniert... Mit den AVM Treibern sollte es auch mit passiven Karten funktionieren. http://www.avm.de/de/Service/AVM_Service_Portale/Linux/CAPI_Tools/CAPI4HylaF AX.html genau das versuche ich zum laufen zu bekommen, um capi kommt man dann nicht herum ;-) Deswegen solltest du 2 Dinge tun: 1. apt-get install kernel-package Das ist ein kleines Programm welches dir die Kernelkompilierung (und auch das erzeugen von Modulen zu einem bestehenden Kernel) wesentlich vereinfacht. Ausserdem erhälst du dabei ein Debianpaket welches du ohne rumkopieren installieren kannst und welches ebenso die Anpassungen für deinen Bootloader vornimmt. 2. apt-get install kernel-patch-misdn Das sind die Änderungen des mISDN Treibers für die CVS-Version vom 16.11. Damit und mit dem obigen könntest du ganz einfach einen Kernel bauen. Du hast dir ja kernel-source-2.6.8 installiert, demzufolge existiert ein tar.bz2 davon in /usr/src. Das packst du dort aus (vorhandenes Kernelverzeichnis löschen) und führst in dem Verzeichnis folgenden Befehl aus: fakeroot make-kpkg --revision Debian.1 --added-patches=misdn --config menuconfig kernel_image Näheres zu den Optionen erfährst du in der manpage zu make-kpkg. Das nimmt die Config des laufenden Kernels als Grundlage und du musst im Prinzip nur noch die mISDN-Treiber in der Konfig aktivieren. Dann erhälst du in /usr/src ein Debian-Paket welches du mittels dpkg -i installieren kannst. ok, vielen dank für die tipps - kannte den debian-way für kernekompilieren bisher nicht so gut, daher immer alles manuell gemacht - aber ich werds mal so probieren :-) mit Kernel 2.6.8 ff hatte ich auch keinen Erfolg. Eine mISDN-Applikation habe ich bisher nur mit Kernel-Versionen bis 2.6.7 zum Laufen gebracht. Allerdings schreibt Andreas Eversberg, dass er das Problem mit Kernel 2.6.8 gefixt hat. Ich habe das aber noch nicht ausprobiert. hatte vorher mit 2.6.8 und mISDN selbst auch probleme, aber auf der webseite gibts ja inzwischen das fix2, welches tatsächlich mit 2.6.8 funktioniert :-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
mISDN Capi
hallo liste, ich probiere bereits seit einigen Tagen, capi mit mISDN und hfc-s isdn karten unter debian sarge zum laufen zu bekommen. habe folgende Module dazu geladen: capi 17600 0 capifs 60242 capi mISDN_capi 84672 0 kernelcapi 44576 2 capi,mISDN_capi mISDN_core 65376 7 hfcpci,mISDN_dsp,mISDN_isac,mISDN_capi,l3udss1,mISDN_l2,mISDN_l1 mISDN_dsp 90784 0 mISDN_isac 2544 0 mISDN_capi 84672 0 kernelcapi44576 2 capi,mISDN_capi mISDN_l2 35328 0 mISDN_l1 9992 0 hfcpci26412 0 bevor ich den entsprechenden ordner mit den modulen umbenannt habe ( /lib/modules/2.6.8-1-386/kernel/drivers/isdn/hisax ), hatte er noch automatisch das hisax modul geladen. aber als kartentreiber verwende ich hfcpci.ko aus dem mISDN paket - daher braucht man den hisax-treiber nicht mehr oder ? weiterhin ist fraglich, was genau mISDN ersetzt. Im 2.4er kernel ging ja capi ohne mISDN, würde das bedeuten, dass mISDN das alte isdn4linux ( aka isdn.ko) ersetzt ? Zur verbindung zwischen capi.ko/capifs.ko und isdn.ko (isdn4linux) wurde ja bisher capidrv.ko verwendet. entspricht mISDN_capi.ko aus dem mISDN Paket capidrv.ko aus isdn4linux ? also braucht man capidrv.ko nicht mehr, wenn mISDN und damit mISDN_capi.ko verwendet wird ? (vorausgesetzt mISDN ersetzt ISDN4Linux). abgesehen vom modul-chaos funktioniert capi selbst natürlich nicht ;-) folgendes gibt capiinfo aus: capi not installed - No such device or address (6) und der pppd: Plugin userpass.so loaded. userpass: $Revision: 1.5 $ Plugin capiplugin.so loaded. capiplugin: $Revision: 1.36 $ capiconn: 1.10 capiplugin: CAPI_REGISTER failed - CAPI not installed (0x1009) [No such device or address (6)] die Module lade ich so: insmod -f /usr/local/pbx/modules/mISDN_core.ko debug=0x0 insmod -f /usr/local/pbx/modules/mISDN_l1.ko debug=0x0 insmod -f /usr/local/pbx/modules/mISDN_l2.ko debug=0x0 insmod -f /usr/local/pbx/modules/l3udss1.ko debug=0x0 insmod -f /usr/local/pbx/modules/kernelcapi.ko insmod -f /usr/local/pbx/modules/mISDN_capi.ko insmod -f /usr/local/pbx/modules/capifs.ko insmod -f /usr/local/pbx/modules/capi.ko insmod -f /usr/local/pbx/modules/mISDN_isac.ko insmod -f /usr/local/pbx/modules/mISDN_dsp.ko debug=0x0 options=0x0 insmod -f /usr/local/pbx/modules/hfcpci.ko protocol=0x2,0x12 layermask=0xf,0x3 debug=0x0 nachdem es einiges googeln belegt hatte, scheint es tatsächlich so zu sein, dass capiinit mit mISDN nicht funktioniert. Deswegen lade ich die Module manuell. capifs ist auch gemountet: mount -t capifs capifs /dev/capi die Mountpoints von capifs sehen so aus: ls -al | grep capi drwxr-xr-x 2 root root 0 2004-11-28 15:01 capi crw-rw 1 root dialout 68, 0 2004-11-27 16:41 capi20 crw-rw 1 root dialout 68, 1 2004-11-27 16:41 capi20.00 crw-rw 1 root dialout 68, 2 2004-11-27 16:41 capi20.01 crw-rw 1 root dialout 68, 3 2004-11-27 16:41 capi20.02 crw-rw 1 root dialout 68, 4 2004-11-27 16:41 capi20.03 crw-rw 1 root dialout 68, 5 2004-11-27 16:41 capi20.04 crw-rw 1 root dialout 68, 6 2004-11-27 16:41 capi20.05 crw-rw 1 root dialout 68, 7 2004-11-27 16:41 capi20.06 crw-rw 1 root dialout 68, 8 2004-11-27 16:41 capi20.07 crw-rw 1 root dialout 68, 9 2004-11-27 16:41 capi20.08 crw-rw 1 root dialout 68, 10 2004-11-27 16:41 capi20.09 crw-rw 1 root dialout 68, 11 2004-11-27 16:41 capi20.10 crw-rw 1 root dialout 68, 12 2004-11-27 16:41 capi20.11 crw-rw 1 root dialout 68, 13 2004-11-27 16:41 capi20.12 crw-rw 1 root dialout 68, 14 2004-11-27 16:41 capi20.13 crw-rw 1 root dialout 68, 15 2004-11-27 16:41 capi20.14 crw-rw 1 root dialout 68, 16 2004-11-27 16:41 capi20.15 crw-rw 1 root dialout 68, 17 2004-11-27 16:41 capi20.16 crw-rw 1 root dialout 68, 18 2004-11-27 16:41 capi20.17 crw-rw 1 root dialout 68, 19 2004-11-27 16:41 capi20.18 crw-rw 1 root dialout 68, 20 2004-11-27 16:41 capi20.19 Da ich 2 identische ISDN-Karten im Rechner habe ( eine TE-Modus, eine NT-Modus (externer/interner S0-Bus) ( für telefonanlage)), müsste ein CAPI modul (welches auch immer) capi, capifs, mISDN_capi etc. (weiß nicht, wie die zusammenhängen) ja wissen, welche Karte es verwenden soll. Wo kann man denn diese Einstellung finden ? :-) Hoffe jemand hat noch eine Idee, an was es liegen könnte bzw. Welches Modul welches benötigt, was isdn4linux mit mISDN zu tun hat, hisax und hfcpci und wie capi bzw mISDN_capi und capi selbst da mit rein passt - je länger ich gegoogelt habe, desto verwirrender wurde der zusammenhang ... ;-) mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
Samba trennt Verbindung
hallo liste, ich erfahre gerade ein höchst seltsames verhalten des Samba Servers. habe samba 3.0.7 und 2 Clients (win 2000) dranhängen. bei pc-01 (client 1) funktioniert das aufbauen der verbindung einwandfrei, so wie es sein sollte. pc-02 (client 2) hingegen baut zwar eine verbindung auf (netzlaufwerk verbinden), trennt sie jedoch nach 2 sec. wieder. klicke ich einen ordner an, baut er die verbindung kurz wieder auf und trennt wieder. so richtig trennen ist es aber doch nicht, denn sowohl sygate auf dem client als auch netstat auf dem server zeigen jede verbindung noch an, dh wenn ich mich durch 10 ordner klicke, sind 10 verbindungen offen, bei jedem klick wird es eine mehr. wenn ich allerdings eine verbindung von client 2 (der, welcher probleme macht) statt zum samba zu client 1 erstelle, tritt das verhalten nicht auf. client 1 samba OK client 2 samba nicht ok client 1 client 2 OK Beide rechner sind identisch konfguriert (bis auf die IP adresse halt), also gleiche einstellungen für wins, dns, lmhosts etc client 2 hat zwar noch eine DVB karte drin, doch deren netzwerkverbindungen sind eh getrennt. Das Problem trat plötzlich auf, gestern lief noch alles perfekt. habe bereits alle systeme mehrmals neugestartet. Kann das am Samba liegen, oder ist eher das Windows schuld, welches sich aber untereinander problemlos verbinden lässt, obwohl aber auch eine windows = samba verbindung von client 1 perfekt funktioniert ? so wirklich suchen lässt sich nach dem problem auch nicht, samba debug zeigt halt an, dass pc-02 verbindet, authorisiert und nommal verbindet, nommal autorisiert etc und ergebnisse von google co. sind in bezug auf samba neue verbindungen viele samba smb verbindungen auch nicht gerade brauchbar :-( hat da jemand evtl. einen Tipp ? :-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: mISDN Capi
Hallo Liste, Mir fehlt da l3udss1, aber der ist wohl auch geladen... genau, das hatte ich vergessen; ist aber geladen :-) Wieso umbenannt? Das Modul umbenennen sollte auch reichen z.B. in hisax.o. Richtig, hisax ersetzt hfcpci und umgekehrt. hmm habe jetzt einen neuen kernel, da auch den ordner umbenannt doch irgendwie lädt er es trotzdem - aber gut zu wissen, hisax brauche ich nimmer, werde es dann einfach löschen ... eine frage dazu noch: wie kann man verhindern, dass der Kernel diese Module lädt ? beispielsweise muss ich ja beim mISDN noch modulparameter angeben, dh entweder man versucht das in der modules.conf mit der options direktive oder lässt die module laden, macht dann rmmod und lädt sie dann wieder mit insmod/modprobe - irgendwie nicht sehr elegant mISDN+CAPI2.0 ersetzt in der Tat isdn4linux. ah okay, vielen dank - dann kann ich das auch löschen oder irgendwie den kernel dazu bekommen es nicht mehr zu laden ... Zur verbindung zwischen capi.ko/capifs.ko und isdn.ko (isdn4linux) wurde ja bisher capidrv.ko verwendet. So mann die isdnutils weiter nutzen möchte ja. hmm isdnutils brauche sie eigentlich nicht - brauche nur ein capi-device, für capi4hylafax und capi20proxy kann ich dann weglassen, das capidrv oder ? Fehlermeldungen beim Laden der Module? kamen eigentlich keine ließ sich alles laden. aber ich bin hier etwas weitergekommen. Um an die mISDN module zu kommen, hatte ich mit apt den kernel-source von 2.6.8-1-386 gezogen, mit std2kern von mISDN den source gepatcht und dann die Module kompiliert. habe aber dann aus dieser neu-kompilierung nur die mISDN module rauskopiert; die capi-module hatte ich aus den alten module-binaries, also die, welche bei der installation dabei waren. Diese ließen sich ja laden (ohne fehler), allerdings funktionierte CAPI ja dann nicht. Ich bin dann auf die Idee gekommen, dass das std2kern script evtl. auch was am CAPI-Treiber des Kernel Source was dreht, und diese änderung dann bewirkt, dass capi.ko nicht mehr versucht zu isdn4linux kontakt herzustellen sondern zu mISDN_capi. = ich versuchte mal das neu kompilierte capi.ko, welches ja dann (möglicherweise(!), nach meiner theorie ;-)) von mISDN std2kern gepatcht wurde zu laden. Ergebnis war dann Unresolved symbol -1 [blablub], jedenfalls ließ es sich nicht laden. Das könnte, dachte ich, daran liegen, dass noch das alte vmlinuz am laufen war. Zwar das capi.ko modul neu war, aber der alte kernel noch lief. habe dann das bzImage kompiliert und den neuen Kernel eingerichtet, initrd neu gemacht (module in initrd passten nimmer zum kernel) etc. und den neuen kernel gebootet. nun lassen sich alle neuen Module laden. Das mag vielleicht ne blöde Frage sein, aber wieso baust du mISDN nicht passend zu deinem Kernel und installierst es dann auch entsprechend unter /lib/modules/2.6.X.../ ? So sollte das doch IMHO gemacht werden. ok, habe ich ja jetzt mehr oder weniger so ;-) Wieso 2 Protokolle? AFAIK ist in Dtl nur 0x2 nutzbar (Euro-ISDN). hmm ich weiß jetzt nicht, ob das mit den protokollen zusammenhängt, aber eine Karte läuft im NT-Modus, dh mit gekreuztem ISDN-Kabel lassen sich ISDN-Endgeräte (telefone etc) daran anschließen und können dann über die pbx4linux ( http://isdn.jolly.de ) betrieben werden. Möglicherweise ist der NT-Modus das andere protokoll. nach einigem googeln hat sich das auch bestätigt, die 0x2 ist der TE-Modus für karte #1 die 0x12 der NT Modus für die 2te karte. Capi habe ich dann mehr oder weniger zum laufen zu bekommen, allerdings unter der einschränkung, dass entweder die PBX geht, oder CAPI. habe dazu noch den modulparameter layermask geändert: modprobe hfcpci protocol=0x12,0x2 layermask=0x3,0xf debug=0x0 also karte #1 ist im NT modus, nach jeweils dem komma kommt die zweite Karte, welche im TE Modus ist. Als ich nun das 0xf weggelassen habe, hat Capi die Karte #2 akzeptiert, also capiinfo vernünftige ausgaben geliefert, allerdings funktionierte die PBX nimmer. da ich nicht weiß, was standard ist, also übernommen wird, wenn das 0xf nicht dabeisteht, bin ich momentan nur soweit, dass entweder Capi oder die pbx geht, bräuchte einen Parameter, der beides ermöglicht, wenn das überhaupt ginge. habe zwar so etwas wie eine Dokumentation gefunden: http://home.foni.net/~jolly/download/hfc_multi-dsp-1.0.html doch nur für die Multi-karten, verwende ja die normalen hfc-s karten, obwohl die parameter (zumindest eingeschränkt) ähnlich sein sollten. Trotzdem werde ich daraus nicht schlau ;-) Doch tut es, wenn du die Module dahin tust wo sie hingehören, nach /lib/modules/`uname -r` habe die module jetzt einfach (debian-üblich) in /etc/modules eingetragen, parameter dazu zu dem /etc/modprobe.d/... und das capifs in die fstab. Ich bin hab grad kein mISDN am Laufen, werde aber wohl heute abend wieder nen neuen Kernel mit mISDN bauen, dann kann ich auch nochmal genauer nachvollziehen. ui, bin mal gespannt auf deine Ergebnisse :-) Andreas mfg christoph -- Haeufig
3ware Treiber - compiler error
hallo liste, ich versuche den 3ware 9000-series treiber zu kompilieren. kernelversion ist 2.4.18 (brauche den treiber für den installer) kernelsource liegt in /usr/src/linux, make dep und damit die modversions-datei ist vorhanden. folgender fehler tritt beim compilieren auf: make -f Makefile.oth gcc -c -D__KERNEL__ -DMODULE -Wall -Wno-sign-compare -fno-strict-aliasing -W strict-prototypes -O2 -fomit-frame-pointer -I. -I/usr/src/linux/drivers/sc si -I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h -o 3w-9xxx.o 3w-9xxx.c 3w-9xxx.c:2260: unknown field `highmem_io' specified in initializer 3w-9xxx.c:2260: duplicate initializer 3w-9xxx.c:2260: (near initialization for `driver_template.proc_name') make: *** [3w-9xxx.o] Error 1 ich habe nach dem ominösen highmem io in der datei gesucht, vim hat aber nichts gefunden hat jmd eine ahnung, warum das nicht funktioniert ? mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: 3ware Treiber - compiler error
hallo liste, weil es highmem_io in 2.4.18 nicht gibt. ah gut zu wissen, bei 3ware steht halt allgemein für kernel 2.4.x - meiner ansicht nach würde dann .18 auch dazugehören :-( ich habe es inzwischen mit sarge probiert, beim starten linux26 angegeben und er erkennt den controller alles funktioniert wunderbar bei der installation, nur von der festplatte booten macht probleme. habe herausgefunden, dass in der initrd das modul zwar drin ist, aber beim booten während der initrd einfach nicht geladen werden kann. also habe ich im installer das ash gestartet, die partition mit der installation gemountet, ein chroot gemacht und die initrd mit loop eingemountet. ärgerlicherweise lässt sich das nervige cramfs nur read-only mounten, was bedeutet, dass ich in der loadmodules datei in der initrd das modul einfach nicht eintragen kann. also einen neuen ordner erstellt, den inhalt der initrd reinkopiert, die loadmodules datei geändert und mit mkcramfs neu gepackt, ins bootverzeichnis kopiert, proc gemountet und lilo laufenlassen. soweit so gut, dachte ich, doch er fährt immer noch nicht hoch. es wird angezeigt, dass der mountpoint für proc nicht vorhanden sei, also kann real-root-dev aus der linuxrc-datei nicht geändert werden, was ja über proc gemacht wird. aber warum existiert der mountpoint nicht (mehr, mit der orginal-initrd kam der fehler nicht) ? ich habe die initrd einfach kopiert !? kann es sein, dass cp da was falsch macht ? habe irgendwo mal was gelesen, dass man mit tar und pipes kopieren kann/soll undwarum macht der debian-installer die sache eigentlich nicht automatisch ? denn wenn nicht, so wie es hier den anschein hat, dann bedeutet das, dass man es ohne bastlerei und hin-und-her mit initrds und ärger über cramfs etc. es nur auf ein ide-system installieren könnte, was ja eigentlich nicht sein kann oder ? es ist der debian installer (sarge) RC2 mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Debian und Capi im Netz
Hallo Liste, ich suche eine möglichkeit, eine ISDN-Karte in einem Rechner mit Debian im ganzen Netzwerk verfügbar zu machen, ähnlich der Capi im Netz funktion von KEN. Gibt es da bereits etwas ausgereiftes, was Mit Kernel 2.6, Capi 2.0 und mISDN funktioniert ? mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
pppd, defaultroute 10.64.64.64
Hallo Liste, ich habe ein Problem mit dem pppd von woody. Wenn die Internetverbindung (DSL) mit poff getrennt wird, und ich sie mit pon wieder aufbaue, dann bekomme ich die ip 10.64.64.64 und gateway 10.112.112.112 am ppp0 zugewiesen. Erst wenn 10.112.112.112 gepingt wird, dann wird eine funktionierende internet-ip zugewiesen. An einem anderen Rechner habe ich das Problem auch (weitgehend identische Konfiguration), nur muss an diesem noch route del default eingegeben werden, damit pings ins Internet funktionieren, obwohl dsl-provider vom pppd mit defaultroute konfiguriert ist. Habe für diese Verhaltensweisen bisher noch keine Erklärung gefunden... wäre sehr nett, wenn da jmd. was weiß ;-) mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Aktualisierendes Backup von Partitionen
Hallo Liste, Hmm, ftp-Upload duerfte ziemlich schwierig werden, jedenfalls hab ich noch nichts in der Richtung gesehen... Wenn du aber auf dem System genug Platz hast, koenntest du zuerst lokal ein Tar-Archiv anlegen und dann das per Skript hochladen. jo, oder direkt pipen, bspw. in ftp, wput oder lftp ... Alternativ ist natürlich eine Art Archivdatei auf dem ftp-server (bspw. tar), welche den chmod ja mitspeichert, doch die müsste dann bei jedem backup ja komplett übertragen werden Noe, sowas nennt man inkrementelles Backup. Das heisst du machst ein Vollbackup und dann speicherst du in deinem Tar Archiv nur noch die Aenderungen... hmm, das hört sich interessant an - wenn man also die alte tar-datei auf dem ftp hat und die neue lokal gespeichert ist - ein update also nur die bestandteile, welche von einer Datei geändert wurden zu übertragen geht meines wissens nicht via ftp. oder gibts da doch eine lösung ? :-) Also ich wuerde dir empfehlen backup2l zu nehmen. Nein, aber besser: scp. thx - ich werde mir mal die manpages anschauen :-) lass mal bitte Deinen ansatz sehen? insbesondere wegen ftp und rsync-schaltern wput -v -I= cat backup.tar ftp://user:pass@ftpserver/backup cat backup.tar | lftp -u user,pass ftpserver (funktionierte aber nicht so wirklich *g*) als hauptproblem gestaltet sich der nachfolgende FTP upload. möglich wäre evtl. auch, tar auf stdout umzulenken und das wiederum in ein ftpprogramm zu pipen, das probiere ich auch noch mal aus. Und wie sicherst Du zurück? *g* gute Frage, falls tatsächlich mal die festplatte aufgeben sollte, evtl. durch booten von cd/floppy/lan, mounten der (neuen) partition und simples entpacken .. sowas in der richtung ;-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Aktualisierendes Backup von Partitionen
Hallo Liste, ich suche eine Möglichkeit, gesamte Partitionen zu backuppen ( das geht ja mit dd und /dev/hdXY ), aber dabei nur die seit dem letzten Backup geänderten Dateien auch im Backup zu aktualisieren. Das ganze müsste auf einen FTP-Server jedesmal übertragen werden. Habe schon einiges probiert, (dd und wput ...), doch mit den geänderten Dateien habe ich noch Probleme. Gibt es da evtl. eine gute Lösung ? mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Aktualisierendes Backup von Partitionen
Hallo Liste, Gibt es einen Grund, warum du nicht auf eine rsync Loesung setzt? Eventuelle ACL's des Dateisystems? ich hab mal in die manpage von rsync geschaut - dort war auf die schnelle nur eine remote-Lsung via rsync-server rsync:// zu finden - kann rsync denn auch ftp-uploads durchfhren ? Bzgl. ACLs, ich verwende ext3 - also wenn die Dateien einzeln bertragen werden wrden (ftp), dann msste nach jeder Datei der chmod neu gesetzt werden. Alternativ ist natrlich eine Art Archivdatei auf dem ftp-server (bspw. tar), welche den chmod ja mitspeichert, doch die msste dann bei jedem backup ja komplett bertragen werden Brauchst Du nur jeweils den aktuellen Stand, oder mut Du die nderungen der letzten Tage haben? nunja, auf dem FTP-server sollten halt nach dem Backup alle Dateien auf aktuellem Stand sein. Wieviel, also ob jedesmal alles oder nur genderte/neue Dateien bertragen werden ist zwar prinzipiell egal, eleganter wre jedoch die Lsung, indem nur ein update geschieht mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ping: unknown protocol icmp
Hallo Liste, Walter Saner schrieb: Hast du dein System zerlegt? Denn wie du siehst, sind das Bestandteile *des* Kernstücks der Distribution. *g* mehr oder weniger zerlegt ;-) ich versuche ein minimales netzwerkfähiges Debian System innerhalb einer Ramdisk aufzusetzen, welches dann via PXE gebootet wird und Knoppix direkt vom Server über NFS verfügbar macht - es funktioniert jetzt mehr oder weniger, das perfekte Read-Only OS für einen Boot-on-LAN Clienten :-) wenn es wirklich zuverlässig funktioniert, also alle Probleme mit Netzwerkkartenmodulen, DHCP und Kernelversionen ausgeräumt sind, kann ich bei Interesse die Ramdisk gern via Mail versenden :-) mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ping: unknown protocol icmp
Hallo Liste, Walter Saner schrieb: Ist auch die notwendige Bibliothek vorhanden? Für die Methode files muss die als /lib/libnss_files.so.? verfügbar sein. | [EMAIL PROTECTED] ~ $ ls -lH /lib/libnss_files.so.? | -rw-r--r-- 1 root root 34520 2004-08-09 21:30 /lib/libnss_files.so.2 genau richtig *g* daran lag es; ich hab die bibliothek reinkopiert und es funktionierte ! Vielen Dank für deine Hilfe :-) mfg Christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
ping: unknown protocol icmp
Hallo Liste, ping scheint keine gnade zu kennen *g* trotz vorhandener /etc/protocols und /etc/services bekomme ich die Meldung: ping: unknown protocol icmp auch pump funktioniert nicht: Cannot reolve bootpc/udp service: Success vermutlich liegt es an getprotobyname() oder getservbyname() - doch die /etc/nsswitch.conf steht hier auch auf files. wenn ich via ifconfig eine feste ip zuweise, dann lässt sich der Rechner von woanders pingen, aber kann es nicht selbst tun :-( weiteres suchen ergab bei mir keine ergebnisse, daher erhoffe ich hier die ersehnte hilfe :-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Boot von RAID 5
Hallo Liste, Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key... sieht so aus, als ob das eine Meldung des Bios ist. Knoppix findet die Platten nicht, da womöglich nicht das entsprechende Modul vorhanden ist *vermutung* falls du es nicht bereits probiert hast, schau mal im Bios ob du die Boot-Sequenz auf den Controller einstellen kannst. mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Der Router verbindet dann die PIRQ1-4 mit den IRQ-Eingängen am PIC. Es gibt Chipsätze die können mehr als 4 Leitungen auf die Steckplätze verteilen, z.B. der SiS735. [...] Sie nimmt immer INTA#, es sei denn sie braucht mehrere INTs. INTA# ist von Steckplatz zu Steckplatz mit einem anderen PIRQ verbunden. Bei Slot1 und Slot5 sind jeweils INTA# mit PIRQ1 verbunden. Wenn in beiden eine Karte drinsteckt führt das unvermeidbar zum IRQ-Sharing. Das Bild erklärt im übrigen ziemlich gut warum das Vertauschen von Karten Sinn macht, oder? jo, tut es - jetzt wird mir sehr viel klar - vielen dank für die darstellung :-) Welche IRQ Nummer je PIRQ zugewiesen werden kann steht in den []-Klammern in der Ausgabe von dump_pirq. Theoretisch kann jedem PIRQ die gleiche IRQ Nummer zugewiesen werden - IRQ-Sharing. genau da müsste man ja eigentlich ansetzen können, also den Router etwas modden damit er die einstellungen nimmt, die der linux kernel haben will...? Die Begrenzte Anzahl ist in der PC Architektur begründet. Theoretisch sind 224 IRQ Nummern möglich, da aber nur zwei PICs eingebaut sind, sind es halt nur 16. Davon führen aus Sicht des PIC 11 Leitungen zum Router und zum ISA-Bus (parallel). IRQ2 und IRQ9 ist ein und derselbe IRQ. also PIC und IRQ-Router sind unterschiedliche Dinge: hardware - router - PIC - CPU oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen beiden funktioniert. Welche Interaktion meinst Du? nunja, wie, wenn die hardware mit dem router verbunden ist; die CPU als zentrale komponente daran angeschlossen ist - aber das hat sich ja inwischen geklärt - vom router führt für jeden routebaren IRQ eine Leitung zum PIC, also dessen IRQ Eingängen, welcher dann die IRQ-Verwaltung für die CPU übernimmt. http://de.wikipedia.org/wiki/Interruptcontroller hmm - also ist hardwaremäßig der pci steckplatz nicht fest verschaltet, der router hat prinzipiell die möglichkeit, den IRQ zuzuweisen, auch wenn das bios keine einstellungsmöglichkeiten bietet, programmierbar ist der router doch trotzdem Sicher, in einigen Fällen macht der kernel das sogar. muss dazu - der kernel APIC unterstützen - der kernel das mainboard apic unterstützen - nur das mainboard... - oder keiner apic unterstützen (... also es schon im normalen pci treiber enthalten ist...) ? Bei IOAPIC sind alle 24 Interrupts fest verdrahtet, ohne Router. Der alte PIC wird bei aktivierung der IO-APIC abgeschaltet. hmm 24 Interrupts ? gibt es da einen dritten PIC (+8) bzw. wer übernimmt dann die IRQ Verwaltung für die CPU wenn der alte pic abgeschalten ist ? oder bedeutet IOAPIC (=APIC ?), dass ein anderer PIC verbaut ist, der statt mit 8 dann mit 24 Interrupts zurechtkommt ? (sorry für die vielen fragen ... bin der ansicht, dass eine problemlösung nur sinnvoll oder sogar möglich ist, wenn man das problem auch wirklich versteht :-)) wäre es möglich, damit auch den IRQ router zu manipulieren ? Mit setpci soll es gehen... hmm ok - kann man da was kaputtmachen ? *g* [dump_pirq] - schaue ich mir später an. jo, vielen dank für deine Hilfe :-) Mit freundlichen Gruessen Bjoern Schmidt mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Der Router verbindet dann die PIRQ1-4 mit den IRQ-Eingängen am PIC. Es gibt Chipsätze die können mehr als 4 Leitungen auf die Steckplätze verteilen, z.B. der SiS735. [...] Sie nimmt immer INTA#, es sei denn sie braucht mehrere INTs. INTA# ist von Steckplatz zu Steckplatz mit einem anderen PIRQ verbunden. Bei Slot1 und Slot5 sind jeweils INTA# mit PIRQ1 verbunden. Wenn in beiden eine Karte drinsteckt führt das unvermeidbar zum IRQ-Sharing. Das Bild erklärt im übrigen ziemlich gut warum das Vertauschen von Karten Sinn macht, oder? jo, tut es - jetzt wird mir sehr viel klar - vielen dank für die darstellung :-) Welche IRQ Nummer je PIRQ zugewiesen werden kann steht in den []-Klammern in der Ausgabe von dump_pirq. Theoretisch kann jedem PIRQ die gleiche IRQ Nummer zugewiesen werden - IRQ-Sharing. genau da müsste man ja eigentlich ansetzen können, also den Router etwas modden damit er die einstellungen nimmt, die der linux kernel haben will...? Die Begrenzte Anzahl ist in der PC Architektur begründet. Theoretisch sind 224 IRQ Nummern möglich, da aber nur zwei PICs eingebaut sind, sind es halt nur 16. Davon führen aus Sicht des PIC 11 Leitungen zum Router und zum ISA-Bus (parallel). IRQ2 und IRQ9 ist ein und derselbe IRQ. also PIC und IRQ-Router sind unterschiedliche Dinge: hardware - router - PIC - CPU oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen beiden funktioniert. Welche Interaktion meinst Du? nunja, wie, wenn die hardware mit dem router verbunden ist; die CPU als zentrale komponente daran angeschlossen ist - aber das hat sich ja inwischen geklärt - vom router führt für jeden routebaren IRQ eine Leitung zum PIC, also dessen IRQ Eingängen, welcher dann die IRQ-Verwaltung für die CPU übernimmt. http://de.wikipedia.org/wiki/Interruptcontroller hmm - also ist hardwaremäßig der pci steckplatz nicht fest verschaltet, der router hat prinzipiell die möglichkeit, den IRQ zuzuweisen, auch wenn das bios keine einstellungsmöglichkeiten bietet, programmierbar ist der router doch trotzdem Sicher, in einigen Fällen macht der kernel das sogar. muss dazu - der kernel APIC unterstützen - der kernel das mainboard apic unterstützen - nur das mainboard... - oder keiner apic unterstützen (... also es schon im normalen pci treiber enthalten ist...) ? Bei IOAPIC sind alle 24 Interrupts fest verdrahtet, ohne Router. Der alte PIC wird bei aktivierung der IO-APIC abgeschaltet. hmm 24 Interrupts ? gibt es da einen dritten PIC (+8) bzw. wer übernimmt dann die IRQ Verwaltung für die CPU wenn der alte pic abgeschalten ist ? oder bedeutet IOAPIC (=APIC ?), dass ein anderer PIC verbaut ist, der statt mit 8 dann mit 24 Interrupts zurechtkommt ? (sorry für die vielen fragen ... bin der ansicht, dass eine problemlösung nur sinnvoll oder sogar möglich ist, wenn man das problem auch wirklich versteht :-)) wäre es möglich, damit auch den IRQ router zu manipulieren ? Mit setpci soll es gehen... hmm ok - kann man da was kaputtmachen ? *g* [dump_pirq] - schaue ich mir später an. jo, vielen dank für deine Hilfe :-) Mit freundlichen Gruessen Bjoern Schmidt mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Nun, passive Karten (weitverbreitet sind die AVM Fritz, deine HFCs wahrscheinlich auch) lassen einen großen Teil der Arbeit die CPU erledigen, was bei schwachen Rechnern bzw. starke Nutzung der CPU schon mal in die Hose gehen kann. Aktive Karten haben erweiterte Chips und damit Logik auf der Karte selbst, entlasten also die CPU, axo, thx für die info - also rein prinzipiell dürfte das eigentlich kein problem für die pentium2 cpu sein mit mehreren passiven karten zurechtzukommen, eine pentium1 cpu kam ja schon gut mit nur einer passiven karte aus nur wenn die karte korrekt initialisiert wird (mit optionalem routing-conflict), geht die pbx oder es kommt ein routing conflict und der alte mISDN-treiber wird verwendet, dann geht die pbx auch - bringt aber ein echo. Echo ist irgendeine Reaktion von pbx? ich vermute das echo hängt mit dem mISDN Treiber zusammen, also mit echo meine ich hier während eines telefonats über die anlage hört man sein eigenes, akustisches echo. es gab auf der mailingliste von pbx4linux bereits einen thread mit lösungsvorschlag, jedoch ist der für den alten Treiber gedacht und funktioniert zudem auch nicht... http://ischtar.koeln.ccc.de/pipermail/pbx4linux/2004-June/000258.html ...deswegen auch der versuch mit dem neuen mISDN treiber. Außer der Hersteller würde (meist für DOS/Windows) ein Konfig-Tool für die Karten anbieten: das wäre dann ein Hinweis, das *doch* Einstellungen möglich bzw. auch *nötig* sind. ich habe mal geschaut: http://www.colognechip.com/isdn/controllers/frame-software.htm da gibts nur treiber, aber hier verwende ich sowieso mISDN, da pbx4linux nur damit funktioniert (DSP). Nein, lass sie auf PCI/PnP. Ich meinte eher: manche BIOSe haben die Möglichkeit, im BIOS den PCI-Slots manuell die IRQs zuzuordnen. Heißt dann irgendwie wie: SLOT-A: auto/IRQx. Wenn du sowas hast, da meinte ich auf auto zurückzustellen. Oder halt per Funktionstaste das ganze BIOS auf Default zu stellen. ok, ich werde das mal machen, jeweils mit neuer und alter Bios Version. Doch, sollten sie. Die Debian-Kernel sind i.d.R. mit allen vorhandenen Treibern und Funktionen kompililiert. nunja, mISDN wird erst durch einen patch im kernel verfügbar, also es ist ein seperates paket für den kernel. http://home.foni.net/~jolly/download/ Ja, weil *beide* Karten sollten eigentlich (auch gleichzeitig) über Hisax-Module ladbar sein. Im ungünstigen Fall würde halt auch eine der beiden Karten nicht initialisiert werden, dann wären wir IMHO aber um eine Erkenntniss reicher (Kernel-unabhängiges Problem). ok, kommt auch noch auf die to-test liste *g* werde heute abend mal einen neuen 2.6.x debian und 2.4.x zusätzlich zum 2.4.18-bf2.4 ausprobieren. Ich weiß, wollte aber ein bißchen Heiterkeit in diesen Thread bringen. Aber da kann dir wahrscheinlich nur jemand helfen, der auch gleichzeitig vor Ort ist. *g* np, falls wirklich garnichts funktioniert, es keine möglichkeit gibt das zum laufen zu bekommen, hole ich mir noch weitere 15 Interrupts - sprich einen weiteren betagteren PC über ebay o.ä. und dann wird einer als telefonanlage und einer als lan-router im einsatz sein ;-) Der Kernel-PCI Treiber liest aus einem Register der PCI-Karte aus welchen Pin (INTn#) die Karte verwendet und mit welchem Pin (PIRQn) des Interrupt Routers dieser verbunden ist ok, damit ich das auch verstehe *g* man kann sich das so vorstellen, dass es gibt verschiedene informations-Leitungen vom gerät in richtung router gibt, welche eine karte verwenden kann ? router_ | _ | | _ | | ||| pci#1 | ||| pci#2 | ||| pci#3 |===|=||= pci#4 | ===|=|= pci#5 |__| also es bspw. so aussieht, wenn die karte in einem der steckplätze sich befindet, sie eine begrente auswahl hat, welche Leitung sie zum router verwendet ? Dann schaut er nach zu welchem IRQn des PIC der PIRQn geroutet wird (das kann man manchmal im BIOS einstellen). dh sobald eine leitung zwischen karte und router ausgehandelt ist, weißt der router dem steckplatz mit der dann zugehörigen leitung einen Interrupt zu (im Bios eingestellt), wobei ein IRQ router 8 interrupts vergeben kann an geräte ? würde das bedeuten, dass prinzipiell hier die begrenzte anzahl der interrupts nicht am router selbst liegt (man könnte ihn mittels weiteren pins für leitungen erweitern), sondern an unzureichend flexibel verschalteten leitungen zu den steckplätzen ? wie kann es dann sein, dass manche geräte immer nur einen bestimmten IRQ haben ? also wenn beispielsweise die uhr auf IRQ0 immer ist, kann das ja durchaus bedeuten, dass diese eine seperate leitung zum IRQ router hat, aber es würde nicht bedeuten, dass der router prinzipiell den IRQ nicht frei zuweisen kann, oder ? eine weitere Frage wäre, wie die CPU mit dem IRQ Router verbunden ist, also wie die Interaktion zwischen
Re: Debian Sarge System auf Soft-Raid-1
Hallo Liste Möchte gern ein Sarge System komplett auf einem Soft-raid-1 installieren. Im Installer kann ich es ja leider nicht während der installation machen. Kann mir jemand sagen wie ich das machen soll/kann. Finde keine gescheiten HowTo`s dazu. nun, was auf jeden Fall funktioniert, ist eine dritte platte einzubauen und dort das sarge zu installieren. von dort aus dann das Softraid aufsetzen (/etc/raidtab) und die komplette installation auf das array (md0) zu kopieren. Im Kernel sollte sw-raid 1 support einkompiliert sein, wenn du davon booten willst, also ggf. muss der Kernel neu kompiliert werden. Nach der Duplikation der Installation empfiehlt sich ein chroot auf das Duplikat, es müssen uU auch einstellungen deines Bootloaders angepasst werden. Zuletzt muss mit rdev das root device des Kernels auf /dev/md0 geändert werden, außer dein bootloader übergibt das entsprechend als startparameter. Falls du Lilo verwendest, nicht vergessen nach jeder änderung der konfigurationsdatei das programm erneut auszuführen. Ein Tutorial zu Raid gibts hier: http://wwwhomes.uni-bielefeld.de/schoppa/raid/woody-raid-howto.html ist zwar für woody, doch prinzipiell funktioniert es bei sarge genauso - der debian installer müsste das aber auch bald unterstützen. Lesenswert ist auch: http://www.pl-berichte.de/t_netzwerk/raid1.html mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Zu meinem Verständnis: für pbx brauchst du 2 ISDN-Karten? genau, eine im TE modus für den anschluss ans erste ntba, welches den externen s0-bus zur verfügung stellt. nr. 2 läuft im NT-Modus, also stellt dann einen internen s0-bus zur verfügung ans zweite, interne ntba, somit lässt sich allerlei interessantes realisieren, VoIP/H.323/email to fax/fax 2 email/anrufbeantworter auf email etc man kann eigentlich telefoninternet weitgehend kombinieren achja, normal über isdn telefonieren geht auch noch *g* Bzw: Funktionieren überhaupt zwei passive Karten gleichzeitig? Z.B. die AVM-Fritz-Treiber unterstützen für CAPI nur eine passive Karte, bei aktiven IMHO bis zu vier. nun, was ist der unterschied zwischen aktiven und passiven isdnkarten ? ich hatte mich an der dokumentation auf der pbx4linux-website orientiert, dort waren die karten als möglich beschrieben - es hat mit ihnen ja auch schon so funktioniert (nur mit audio-echos und altem mISDN halt ...) Das sind Meldungen aus der syslog bzw. kern.log ? Und zwar von 2.6.7. genau, aus der kern.log bei 2.6.7 - sie sind aber auch an der console selbst sichtbar. Und die Meldungen weiter unten zum Starten der ISDN-Karten sind aus dmesg des gleichen Kernels? Dann sind das Folgefehler vom Nicht-Initialisieren einer Karte. hmm - dh manchmal wird eine karte trotz routing-conflict intitialisiert und funktioniert, und manchmal (je nach karten/steckplatz konfiguration) kommt zwar die gleiche routing-conflict meldung, aber es kommen folgefehler und die karte geht nicht - paradox. Kann es sein das: eine Karte defekt ist? hmm, besten bzw. schlechtestenfalls hat eine beim umstecken den geist aufgegeben, ich werde es mal durch vertauschen der isdnkarten testen. Oder eine Karte nicht richtig im Slot sitzt? Um sicher zu gehen: Bitte noch mal nachstecken. eher unwahrscheinlich, aber ich werde das auch nochmals prüfen. Wenn pbx mit einer Karte möglich ist, dann bitte auch mal jeweils nur *eine* ISDN-Karte testen. Bzw. nur mit einer die Log beim Laden der Module beobachten. naja, das ist so - wenn ich die netzwerkkarten ausbaue und bestimmte steckplätze verwende (glaube 2 und 4) dann hatte ich eine karte ohne routing confict hinbekommen - dann funktionierte sie auch bei der pbx. Hier also die erste Karte: Sep 19 18:36:09 server kernel: HFC card cb663000 dch cb663090 bch1 cb66321c bch2 cb6633b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 11 for device :00:0a.0 Der Kernel-PCI-Treiber ordnet diesem Steckplatz den IRQ 11 zu (Björn: ist das richtig so?) angenommen das wäre so - warum tut der kernel-pci-treiber das ? Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0a.0, have irq 10, want irq 11 Vom BIOS oder Karte wurde aber IRQ 10 eingestellt. Richtig? (1.Karte BIOS-IRQ-Meldungen auf 10 ?) genau, sie ist auf IRQ 10 wie im bios - und hat mit dem alten mISDN treiber unter 2.6.7 auch funktioniert, trotz routing conflict. Sep 19 18:36:09 server kernel: HFC-PCI: defined at mem 0xcc80ae00 fifo 0xc9c28000(0x9c28000) IRQ 10 HZ 1000 Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 10 count 34 Daher läuft die Karte schlußendlich auch auf IRQ 10, also bios-gemäß. Erzeugt auch Interrupts (34). völlig richtig, nur die pbx lässt sich nicht starten. nur wenn die karte korrekt initialisiert wird (mit optionalem routing-conflict), geht die pbx oder es kommt ein routing conflict und der alte mISDN-treiber wird verwendet, dann geht die pbx auch - bringt aber ein echo. Sep 19 18:36:09 server kernel: HFC card c9d0c000 dch c9d0c090 bch1 c9d0c21c bch2 c9d0c3b4 Sep 19 18:36:09 server kernel: PCI: Found IRQ 12 for device :00:0b.0 Der Kernel-PCI-Treiber findet IRQ 12 für diesen Slot (kollidiert evtl. mit PS/2-Maus oder Tastatur) Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0b.0, have irq 11, want irq 12 Vom BIOS wurde die 2.Karte aber auf IRQ 11 gesetzt. Richtig? jo, genau wie bei der anderen ISDN-Karte, es kommt ein routing conflict, die karten wollen aus unverständlichen gründen auf einen anderen IRQ, können aber nicht. bei den netzwerkkarten und altem mISDN treiber ist das egal, aber der neue mISDN treiber scheint diesbezüglich empfindlich zu sein - was auch durchaus berechtigt ist. Sep 19 18:36:09 server kernel: init_card: entered Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 11 count 0 Sep 19 18:36:09 server kernel: HFC PCI: IRQ(11) getting no interrupts during init 1 Jetzt wird versucht die Karte bios-gemäß auf IRQ11 zu initialisieren, was aber (mehrmals) fehlschlägt (no interrupts count) und auch obige Fehlermeldung aus usercopy.c auslöst. klingt logisch, zudem das obige hier auch nur einmal auftritt, also eine karte trotz routing conflict erfolgreich initialisiert wurde - und dann bei der pbx doch wieder funktioniert. Also entweder kollidiert die
Re: irq routing conflict - einige varianten
Hallo Liste, Nee, Aufkleber sind nicht sinnvoll. ...wie beruhigend :D ;-) Die Nummer die ich meine ist meistens wie die Leiterbahnen in die Grundplatte eingeätzt und sieht dementsprechend aus. Sie hat immer das Format PCBx.x, bzw. PCB x.x jo, du hast recht - habe ganz unten links im eck auch eingeätzt die nr. 1.3 gefunden. meinst du, dass man keine version 1.4 aufspielen sollte, weil diese alle für die QF* ausführungen, nicht die QC* sind ? Nein, Du hast es noch nicht verstanden. Die PrintedCircuitBoard-Nummer PCB steht für die Version der Hardware, nicht für die des BIOS! Es gibt keine BIOS-Version 1.4 die Du aufspielen kannst, die BIOS Versionsnummern beginnen alle mit Q. aha, danke - das mit der PCB wusste ich nicht. lohnt sich dann überhaupt ein biosupdate ? angenommen es wird wirklich nur das an den bios-images verändert, was beim download auch erwähnt wird - dann bräuchte man doch keines oder ? Ansonsten probiere ich es mal mit QC617 Falls das nichts bringt, muss evtl. ein anderes mainboard her Mit freundlichen Gruessen Bjoern Schmidt mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Hm, das verstehe ich jetzt nicht. Treiber bzw. Module für nicht vorhandene Hanrdware sollte in einen selbstgebauten Kernel eh nicht sein. Wenn du Hardware deaktivierst für Hardware die du brauchst, hast du ein Problem. Wenn du aber kein Problem hast, brauchst du die Hardware nicht... hmm, naja, mein gedanke ist, im kernel soviel hardwareunterstützung wie möglich zu deaktivieren, um fehlerquellen auszuschließen. Immer noch mein Vorschlag: NICs ausbauen, ISDN-Karten zum Funktionieren bringen, NICs wieder einbauen. IMHO hast du erst dann ein wirkliches Problem, wenn z.B. die NIC/ISDN-Karten Kombination seperat funktioniert aber im Zusammenspiel nicht. Kannst du dazu eine definitive Aussage machen? Nun, ich habe nun einiges ausprobiert. Das Ausbauen der Netzwerkkarten hat nicht geholfen, die pbx startete nicht. Und noch mal ganz zurück an den Anfang. Warum kannst du nicht bei 2.6.7 bleiben wenn es da doch funktioniert? jo, das dachte ich mir jetzt auch, und habe wieder 2.6.7 draufgemacht. Zur Abwechslung gibts hier sogar auch mal ne andere Fehlermeldung Sep 19 18:12:51 server kernel: Debug: sleeping function called from invalid context at arch/i386/lib/usercopy.c:623 Sep 19 18:12:51 server kernel: in_atomic():1, irqs_disabled():1 Sep 19 18:12:51 server kernel: [c0116cd6] __might_sleep+0xaa/0xb4 Sep 19 18:12:51 server kernel: [c01c7dc6] copy_from_user+0x1e/0x68 Sep 19 18:12:51 server kernel: [cc90fd51] mISDN_write+0x1a1/0x814 [mISDN_core] Sep 19 18:12:51 server kernel: [c016152e] select_bits_free+0xa/0x10 Sep 19 18:12:51 server kernel: [c01619b5] sys_select+0x481/0x490 Sep 19 18:12:51 server kernel: [c014f67c] vfs_write+0xa0/0xd0 Sep 19 18:12:51 server kernel: [c014f729] sys_write+0x31/0x4c Sep 19 18:12:51 server kernel: [c0103e8f] syscall_call+0x7/0xb auch wenn ich keine wirkliche ahnung davon habe, habe ich diese ominöse might_sleep(); Funktion in usercopy.c einfach mal auskommentiertes hatte aber folgende wirkung: Sep 19 18:53:14 server kernel: Debug: sleeping function called from invalid context at arch/i386/lib/usercopy.c:597 Sep 19 18:53:14 server kernel: in_atomic():1, irqs_disabled():1 Sep 19 18:53:14 server kernel: [c0116cd6] __might_sleep+0xaa/0xb4 Sep 19 18:53:14 server kernel: [c01c7d75] copy_to_user+0x19/0x4c Sep 19 18:53:14 server kernel: [cc916a3c] mISDN_read+0x1b8/0x320 [mISDN_core] Sep 19 18:53:14 server kernel: [c014f4fc] vfs_read+0xa0/0xd0 Sep 19 18:53:14 server kernel: [c014f6dd] sys_read+0x31/0x4c Sep 19 18:53:14 server kernel: [c0103e8f] syscall_call+0x7/0xb also nun gefällt im eine andere zeile nicht. hier kommt man also nicht weiter - ich habe den ausgangszustand wiederhergestellt. Meine Vermutung zu der ganzen Sache ist folgende: der alte mISDN treiber kommt besser mit den ominösen irq-routing conflict meldungen zurecht, also startet; produziert aber ein echo. der neue scheint hier etwas genauer zu sein, also lässt die pbx nicht starten, nach umstecken der ISDN karten, hat die pbx sogar einmal gestartet, nur eine ISDNkarte lief nicht, war im programm rot markiert und die obigen fehlermeldungen erschienen nur noch halb so oft. Beim Laden der mISDN module erscheint das: Sep 19 18:36:09 server kernel: Modular ISDN Stack core $Revision: 1.23 $ Sep 19 18:36:09 server kernel: mISDNd: kernel daemon started Sep 19 18:36:09 server kernel: mISDNd: test event done Sep 19 18:36:09 server kernel: ISDN L1 driver version 1.11 Sep 19 18:36:09 server kernel: ISDN L2 driver version 1.19 Sep 19 18:36:09 server kernel: mISDN: DSS1 Rev. 1.26 Sep 19 18:36:09 server kernel: mISDN_dsp: Audio DSP Rev. 1.9 (debug=0x0) Sep 19 18:36:09 server kernel: HFC card cb663000 dch cb663090 bch1 cb66321c bch2 cb6633b4 Sep 19 18:36:09 server kernel: mISDN: HFC-PCI driver Rev. 1.38 Sep 19 18:36:09 server kernel: PCI: Found IRQ 11 for device :00:0a.0 Sep 19 18:36:09 server kernel: IRQ routing conflict for :00:0a.0, have irq 10, want irq 11 Sep 19 18:36:09 server kernel: mISDN: HFC-PCI card manufacturer: CCD/Billion/Asuscom card name: 2BD0 Sep 19 18:36:09 server kernel: HFC-PCI: defined at mem 0xcc80ae00 fifo 0xc9c28000(0x9c28000) IRQ 10 HZ 1000 Sep 19 18:36:09 server kernel: spin_lock_adr=cb66306c now(cc90b7b2) Sep 19 18:36:09 server kernel: busy_lock_adr=cb663070 now(cc90b7b2) Sep 19 18:36:09 server kernel: reset_hfcpci: entered Sep 19 18:36:09 server kernel: HFC_PCI: resetting HFC ChipId(30) Sep 19 18:36:09 server kernel: HFC-PCI status(4) before reset Sep 19 18:36:09 server kernel: HFC-PCI status(2) after reset Sep 19 18:36:09 server kernel: HFC-PCI status(4) after 5us Sep 19 18:36:09 server kernel: init_card: entered Sep 19 18:36:09 server kernel: inithfcpci: entered Sep 19 18:36:09 server kernel: HFC PCI: IRQ 10 count 34 Sep 19 18:36:09 server kernel: HFC card c9d0c000 dch c9d0c090 bch1 c9d0c21c bch2 c9d0c3b4 Sep 19 18:36:09 server kernel: mISDN: HFC-PCI driver Rev. 1.38 Sep 19 18:36:09 server kernel: PCI: Found IRQ 12 for device :00:0b.0 Sep 19
Re: irq routing conflict - einige varianten
Hallo Liste, IS funktioniert auch ohne ACPI, klar. gut, dann kann ich ACPI also abgeschaltet lassen Auf jedem gängigen PCI basierten System sind Shared Interrupts das normalste der Welt und lassen sich praktisch gar nicht vermeiden hmm ... dh der routing conflict beruht darauf, dass IRQs geshared werden und der Treiber eines der IRQ-sharenden Geräte nicht damit zurecht kommt ? oder welche Möglichkeit gibt es noch, dass ein routing conflict erscheint, wenn doch IRQ sharing eigentlich problemlos funktionieren müsste ? Ob ein Treiber shared interrupts NICHT unterstützt kannst Du schnell herausfinden, nämlich indem Du in seiner Quelldatei nach SA_SHIRQ grepst und es nicht findest. ich habe mit mal die 8139too.c , hfc_pci.c dmfe.c angeschaut - in allen kommt SA_SHIRQ vor, dh die Treiber unterstützen IRQ sharing. Ist es auch möglich, dass die Meldung routing conflict selbst ein Bug ist, also es eigentlich keinen routing conflict gibt ? aber warum war dann eine Karte mal auf IRQ 0 gewesen ? Da du bei dem PC ja auch eine etwas betagtere Hardware einsetzt (ich werkele hier z.B. auch noch mit meinem K62/350 rum, glücklich und zufrieden!) wäre es auch noch mal eine Überlegung, über ein BIOS-Update nachzudenken. Evtl. behebt ein Update eine mangelhafte BIOS-Implementation im Bereich PCI-Bus. ok, das ist auch eine idee - ich werde mal schauen ob ich irgendwo ein update finde :-) Oder es gibt bei mISDN ein Tool wie z.B. capiinfo bzw isdnctrl bei Hisax zum Überprüfung des Status. hmm eigentlich müsste capiinfo ja auch bei mISDN funktionieren - capi setzt ja auf dem hardwaretreiber für die isdnkarten auf soweit ich weiß, also müsste capiinfo = capi2.0 = mISDN eigentlich gehen ich habe mal mit apt-file search capiinfo ausfindig gemacht und versucht zu installieren: apt-get: Starting ISDN services: no ISDN cards configured! Please configure 'hisax' module with modconf [...] Starting ISDN active cards :ERROR: cannot load module kernelcapi das kann nun entweder heißen, dass das debian-package nicht für mISDN konzipiert ist, also auf hisax in verbindung mit 2.4 oder dass der versuch kernelcapi als modul deswegen fehlschlägt, weil ich es fest einkompiliert habe, also kein modul da ist. ich werde es nochmals als modul kompilieren. Bei Nicht-Funktionieren würde ich einen eigenen Thread zu mISDN aufmachen. Wenn es funktioniert, würde ich eine oder beide NICs wieder einbauen und dann schauen, ob es immer noch geht. ok, ich teste das mal alles durch, biosupdate, kartentauschen etc ;-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
Hallo Liste, Es *kann* doch einfach so sein: Zum Zeitpunkt, wo das BIOS die Hardware initialisiert, ist wesentlich weniger Hardware aktiv als zum Zeitpunkt, an dem das Betriebsystem die Hardware übernimmt. das wäre noch eine Möglichkeit ... ich deaktiviere in einem neuen Kernel mal soviel hardware wie möglich. Oder auf den Karten-Chips sind irgendwelche Voreinstellungen/Wünsche (setze mich bitte auf IRQ xyz, bei ISA-Karten gab es das mal). Das OS als Oberguru seiner Hardware ändert das jetzt und die Karte beschwert sich. Linux in seiner gnadenlosen Offenheit macht diese Beschwerde jetzt auch noch öffentlich ;-) hmm jo, wobei man auf den karten selbst nichts ändern kann, womöglich ist es doch das bios; ich probier heute nacht mal ein update (währenddessen kommt nur ein rechner ins Inet :-( )... ok, das ist auch eine idee - ich werde mal schauen ob ich irgendwo ein update finde :-) Da du den Hersteller/Bezeichnung deines Boards ja nicht kennst kannst ok, ich hab mal einiges ausprobiert und auch herausgefunden. das Mainboard ist ein FIC VB-601-V: http://www.fic.com.tw/product/motherboard/1stmainboard_detail.aspx?type=lega cymodel_id=15 die bios-update seite dafür ist leider etwas widersinnig - version 1.3 ist bspw. neuer als 2 der versionen 1.4, momentan ist das bios mit 1.3 bespielt, ich flashe mal die nach dem datum neuste 1.4er version. Vielleicht hast du ja auch mISDN bzw. capi-seitig noch nicht alles aktiviert im Kernel. Es muß doch zu mISDN in /usr/share/doc doch eine Readme geben, wo die Konfiguration beschrieben ist? hmm ich bin eigentlich (zumindest bei mISDN, bei VoIP gabs probleme, debian-lib zu alt ...) im rahmen des tutorials der pbx ( http://isdn.jolly.de ) vorgegangen, bei 2.6.7 hat es so funktioniert - bei 2.6.8 nicht ich gehe das tut nochmals schritt für schritt durch, falls das problem nicht mit den IRQs zusammenhängen sollte, mache ich evtl. einen seperaten thread dafür auf Was war das doch gleich für ein Board? Mach mal bitte ein dmidecode... hmm dmidecode ? ich habe über apt-file im paket ipmi-controlein dmidecode gefunden, installiert und aufgerufen. hier ist die ausgabe: server:~# dmidecode SMBIOS present. DMI 2.0 present. 32 structures occupying 2123 bytes. DMI table at 0x000F568E. Handle 0x DMI type 0, 19 bytes. BIOS Information Block Vendor American Megatrends, Inc. Version 0627 Release 11/18/98 BIOS base 0xF ROM size 192K Capabilities: Flags: 0x7FC9DE90 Handle 0x0001 DMI type 1, 25 bytes. System Information Block Vendor System Manufacturer Product System Name Version System Version Serial Number SYS-9876543210 Handle 0x0002 DMI type 2, 8 bytes. Board Information Block Vendor FIRST INTERNALTIONAL COMPUTER Product VB-601-V Version VER:1.3 Serial Number 1234567890 Handle 0x0003 DMI type 3, 13 bytes. Chassis Information Block Vendor System Manufacturer Product System Version Version System Version Serial Number SYS-00 Asset Tag ASS-9876543210 Handle 0x0004 DMI type 4, 32 bytes. Handle 0x0005 DMI type 5, 24 bytes. Handle 0x0006 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 1 Banks: 0 1 Type: Installed Size: 64Mbyte Enabled Size: 64Mbyte Handle 0x0007 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 2 Banks: 2 3 Type: Installed Size: 128Mbyte (Double sided) Enabled Size: 128Mbyte (Double sided) Handle 0x0008 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 3 Banks: 2 3 Type: UNKNOWN Installed Size: Not Installed Enabled Size: Not Installed Handle 0x0009 DMI type 6, 12 bytes. Memory Bank Socket: DIMM 4 Banks: 2 3 Type: UNKNOWN Installed Size: Not Installed Enabled Size: Not Installed Handle 0x000A DMI type 7, 19 bytes. Cache Socket: L1 Cache L1 Internal Cache: write-back L1 Cache Size: 32K L1 Cache Maximum: 32K L1 Cache Type: Synchronous Handle 0x000B DMI type 7, 19 bytes. Cache Socket: L2 Cache L2 Internal Cache: write-back L2 Cache Size: 512K L2 Cache Maximum: 512K L2 Cache Type: Synchronous Handle 0x000C DMI type 8, 9 bytes. Handle 0x000D DMI
OT - 9 polige mini-din buchse
Hallo Liste, ich weiß, es passt nicht ganz zum thema debian *g* aber ich habe hier einen ascom-pc dialer 2 der über eine Buchse für einen 9poligen stecker verfügt, welche bspw. miniDin/Svideo/PS/2buchsen (klein,rund) recht ähnlich sieht (9 pole statt 4 oder 8)und mit dem seriellen anschluss des PCs verbunden werden muss - nur habe ich kein kabel dazu. Ich habe solche stecker auch bei scannernan der durchlichteinheit und an tv-outs (für adapter dann) bei Grafikkartengesehen. leider half das stöbern in einigen onlineshops und weiteres suchen im Internetnicht weiter, ein passendes kabel bzw. zumindest den Namen des Steckers ausfindig zu machen. Ist das eine Art Sonderanfertigung bei jedem Gerät, oder gibt es dafür einen Standard bzw. hat jemand eine Idee, wo man ein passendes Kabel (zumindest stecker) herbekommen kann (preis egal)? mfg christoph
Re: irq routing conflict - einige varianten
Hallo Liste, Nimm nicht die 1.4er! NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT NICHT. hmm ok, habe es noch nicht getan *g* da du glücklicherweise so intensiv davor warnst, vermute ich, dass das möglicherweise eine art Bios-GAU gegeben hätte... Bitte. dann mal danke für die warnung ;-) PCB Ver. ist nicht die BIOS-Version, sondern die Version des Platinenlayouts. Du scheinst laut dmi Version 1.3 zu haben, aber ohne Garantie! Schau lieber aufs MB, da steht das auch drauf. ok, hab ich, folgendes erscheint mir evtl. sinnvoll: - aufkleber: QC614S2s - aufkleber: 1909 - aufkleber: VB-601-V meinst du, dass man keine version 1.4 aufspielen sollte, weil diese alle für die QF* ausführungen, nicht die QC* sind ? mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
IP Kernel Level autoconfiguration
Hallo Liste, ich hätte eine Frage zum DHCP-CLient-Bestandteil des Linux Kernels. Ich versuche woody diskless mittels PXE booten zu lassen. Dabei werden die Netzwerkkartenmodule nicht mit einkompiliert sondern (ähnlich wie bei Knoppix die scsi module) in der initrd geladen. der kernel ist mit ip kernel level autoconfiguration kompiliert. von pxelinux wird zusätzlich als boot-parameter ip=dhcp übergeben. meine frage hierbei ist nun, zu welchem zeitpunkt der kernel versucht einen dhcp-lease zu bekommen. da die netzwerkkartenmodule in der initrd geladen werden, muss dies entweder nach der initrd geschehen, oder, das ist das, was ich brauche, in der initrd initialisierbar sein. Also ich suche eine möglichkeit in der initrd den kernel anzuweisen _jetzt_ zu versuchen, sich eine IP zu holen. ist das irgendwie realisierbar ? oder wird, sobald ein neues netzwerkmodul geladen wird, automatisch der dhcp-client des kernels aktiviert ? wäre evtl. über /proc etwas zu erreichen ? mfg christoph ___ Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: irq routing conflict - einige varianten
hallo liste, Aber klar, kein Verdrücken ;-) einverstanden, also gehts hier weiter :-) Das *ist* APIC. ACPI (beachte die Buchstabenandordnung) ist für Power-Management zuständig. das war eigentlich das, was mich etwas durcheinander brachte, also ACPI _nur_ powermanagement Ich bin nicht der Hardware-Experte, aber IRQ-Sharing ist reine Sache des BIOSes bzw. des PCI-Busses. Unabhängig von A*PI*C hmm würde das dann bedeuten, dass, wenn das bios/pcibus die irqs nicht shared, das betriebssystem es auch nicht machen kann ? außer es kann mit APIC die interrupts neu verteilen und ggf. auch sharen, wenn es die hardware unterstützt ? Trotzdem gehört für mich die System.map zum jeweiligen Kernel. nun, das dachte ich mir auch des öfteren beim bf2.4 kernel, bei dem ja auch eine dabei ist. bei den selbstkompilierten weiß ich nicht, wo man die jeweilige datei herbekommt bzw. zu was sie überhaupt gut ist; der kernel und die module funktionieren ja auch so ;-) Die /etc/modules.conf fasst man nicht an. Das steht auch am Anfang der Datei. Diese wird jedesmal nach Modul-Änderung überschrieben. jo, das hatte ich gelesen - nur aus ratlosigkeit habe ich es halt in allen dateien probiert, welche irgendetwas mit module laden zu tun hatten. Debian-like ist: Module, die beim Starten gebraucht werden, werden in die /etc/modules eingetragen. Optionen zu den Modulen in die jeweiligen Files unter /etc/modutils. Der Befehl update-modules generiert dann die /etc/modules.conf. danke für die info, endlich fällt mal etwas licht ins dunkel, der bedeutung der restlichen mod* dateien ;-) Eine /etc/modprobe.conf habe ich hier nicht, ist aber vielleicht eine Spezialität des 2.6.x-er Kernels. jo, ab 2.5.x glaube ich wird die modules.conf nicht mehr verwendet, stattdessen die modprobe.conf, hat ein leicht abgewandeltes format (manpage), es gibt aber ein script, welches bei den module-init-tools für 2.6 mitgeliefert wird, generate-modprobe.conf oder ähnlich heißt es, welche die alte modules.conf konvertiert. statt modutils wird dann das verzeichnis modprobe.d (auch unter /etc ) verwendet Deshalb IMHO *local* APIC des Kernels. Da das dann eine einseitige Richtung ist könnte ich mir vorstellen, das es da zu Problemen kommen kann- okay, ist nun ja abgeschaltet - also eine fehlerquelle weniger Könnte das bedeuten, dass ACPI auch seitens des Bios doch verfügbar ist ? :-) wenn ja, beeinflusst das die Möglichkeit IRQ sharing zu aktivieren ? Keine wirkliche Ahnung. Schau ins Mainboard-Handbuch oder Datenblatt. IRQ-Sharing hat mit A*CP*I nichts zu tun. hmm ok, ich schau mal ob ich etwas handbuch-mäßiges auftreiben kann, hab die hardware von nem bekannten bekommen - keinerlei zubehör ;-) Nein, ist normal. Du hast halt prinzipiell nur eine beschränkte Anzahl freier IRQs, normalerweise 2/9, 5, 10, 11. [...] Abhelfen kann man, indem man evtl. nicht benötigte IRQs freimacht. Z.B. wenn man kein Modem/serielle Maus benutzt COM1/COM2 abschalten. Oder den LPT-Port, wenn kein Drucker dran ist. Keine PS/2 Maus/Tastur? Dann PS/2 abschalten. Keine Festplatte/CDRom am zweiten IDE-Controller (IRQ 15). Dann abschalten. Das Abschalten geschieht im BIOS. ok, ich versuche mal die abschalt-methode - falls das nicht zum erfolg führt, müsste man aber versuchen IRQ sharing zu aktivieren. wenn nun ACPI nichts mir IRQ-sharing zu tun hat, also auch dessen aktivierung im kernel nutzlos ist - wie aktiviert man IRQ-sharing dann ? Zu den irq-routing Meldungen: Meiner Meinung nach sind das keine Fehler- sondern Info/Warn-Meldungen. Wenn die Komponente am Ende mit den Werten wie sie /proc/interrupts ausgibt läuft, ist aller ok. Nur bei Nichtfunktionieren würde ich diese Warnungen beachten. nun, die netzwerkkarten gehen ja, nur die isdn karten funktionieren nicht - was aber auch an mISDN oder der pbx liegen kann, also in /proc/interrupts sind sie zu finden; module (zwar auch mit irq routing conflict) sind geladen. die pbx bringt während sie versucht zu starten nur folgende meldungen: server:~# pbx state ** PBX4Linux ** Version 2.5 (August 2004) debug_init: using stdout for debug log debug_init: using stderr for warning log debug_init: using stderr for error log debug_init: debug_mask = 1000 cannot request MGR_NEWENTITY from mISDN. Exitting due to software bug. wie gesagt, entweder in mISDN oder der pbx ist ein bug, oder die karten funktionieren tatsächlich nicht (obwohl sich die module laden lassen) falls es an mISDN/der pbx liegt, werde ich evtl. auch mal auf deren mailinglisten vorbeischauen ;-) Funktionieren dann beide Netzwerk-Karten? jo, beide gehen. ich baue dann die ISDN karten mal aus, und versuche es ohne routing conflict die module laden zu lassen :-) Und: siehst du mittlerweile mit modconf deine Module deines Kernels? leider nicht, das hängt mit der modprobe.conf von kernel 2.6 zusammen, das alte modconf kommt damit nicht zurecht - is ja auch nicht soo wichtig das modconf ;-) mfg vielen dank
Re: irq routing conflict - einige varianten
Hallo Liste, Eine Bitte vorweg: könntest du eventuell bei weiteren Mails großzügiger mit Absätzen umgehen und vielleicht auch Groß/Kleinschreibung benutzen? ok, ich versuche mein bestes ;-) Wie hast du den Kernel kompiliert? Debian-konform mit make-kpkg oder per Hand (mit make ...)? ich habe ihn über make kompiliert und dann die arch/i386/boot/bzImage als Kernelimage genommen, jeweils dann ins /boot Verzeichnis kopiert, mit lilo korrekt verknüpft und lilo dann auch ausgeführt. Die Module gewohnterweise mit make modules und danach make modules_install. Die Debian Variante mit make-kpkg scheint mir irgendwie unnötig kompliziert zu sein ;-) Hast du für Woddy auch die neuen module-init-tools, die für den 2.6.x Kernel benötigt werden, installiert (z.B. von www.backports.org)? genau, die module-init-tools von backports.org. APM und ACPI dienen beide dem Power-Management. ACPI findet sich in neueren PCs/BIOSen und bietet mehr Möglichkeiten. PnP betrifft die automatische Konfiguration von ISA-Karten, im Gegensatz zur Konfig mit Jumpern (PlugAndPlay oder PlugAndPray, wie man will...). Keine ISA-Karten, keine PnP-Unterstützung nötig. Vielen Dank für diese info :-) ich dachte bisher, dass das noch irgendetwas mit pci-Karten zu tun hat - werde ich nun abgeschalten (Kernel Image wieder etwas kompakter ...) APIC ist IMHO ein erweitertes Resourcen-Management, urspünglich dafür gedacht um Mehrprozessor-Systemen den geregelten Zugriff auf die Hardware(-IRQs) zu gewähren. Dabei werden die BIOS-seitig beschränkten IRQ/IO-Adressen logisch erweitert und umgeleitet (routing). Ist mittlerweile auch bei neueren Single-CPU-Systemen implementiert. hmm... also ich habe hier am Windows-PC mit neuem Asus SK8V im Gerätemanager IRQs bis 21, das wäre eine ersehnte Erklärung dafür, danke :-) Soweit ich das nun verstanden habe, bedeutet ACPI unter anderem, dass es beispielsweise egal ist, welche IRQs das Bios den Geräten zuordnet, das Betriebssystem kann dieses dann selbst ggf. anders erledigen, unabhängig vom Bios. Inwiefern steht APIC damit im Zusammenhang ? Also kann, wenn APIC verfügbar ist (ist ACPI hierbei erforderlich?), das Bios auch (also nur in der Tabelle während des Bootvorgangs) virtuelle IRQs 15 vergeben ? oder kann das IRQ 15 generell nur das Betriebssystem, also das Bios nicht ? bzw. ist aus Sicht des Betriebssystems nur ACPI nötig (also APIC optional) - oder umgekehrt - oder braucht man beides -um diese IRQs 15 vergeben zu können ? Abgesehen von APIC - funktioniert IRQ _sharing_ selbst andererseits nur, wenn ACPI vom Kernel unterstützt wird ? Falls ja, dann wäre ja der =IRQ sharing Bestandteil= von ACPI möglicherweise eine rein softwareseitige Erweiterung. Also es wäre kein spezielles Bios mit ACPI Unterstützung nötig, um wirklich nur IRQ sharing (im Gegensatz zu anderen Bestandteilen von ACPI, beispielsweise Standby-Modus, wo ja auch das Bios es unterstützen muss) nutzen zu können. Das wäre wirklich hilfreich, wenn man den Zusammenhang zwischen APIC und ACPI und deren Bestandteilen genau wüsste ;-) Ich bin mir nicht sicher ob dein PII (ist ein PII 350Mhz ?) schon MMX unterstützt. cat /proc/cpuinfo gibt dir bei Flags Auskunft darüber. Evtl. ist # CONFIG_MPENTIUMII is not set die bessere Wahl. Ist IMHO aber eher Nebensache. okay, habe ich eingestellt (hatte ursprünglich nur pentium MMX gewählt, um eine größere Kompatibilität des Kernels zu ermöglichen, aber aufgrund der zahlreichen Tuningmöglichkeiten, deren genaue Bedeutung ich jetzt erst im Nachhinein erfahren kann, scheint das keine gute Idee gewesen zu sein ) CONFIG_SMP=y Würde ich disablen. Gerade bei älteren Boards/CPUs kann aktivierte SMP-Untestützung Probleme bereiten. ok, ist deaktiviert (.. und das Kernelimage um einies kleiner ;-)) CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y Du schriebst, du hättest deinen Kernel ohne APIC kompiliert. Hier ist es aber noch ativiert ? Würde ich abschalten, da dein BIOS sowieso kein APIC kann, s.u. sorry, hatte einfach mal mit den Parametern irgendwie rumprobiert, da ich nicht genau wusste, was genau sie eigentlich bewirken, also deaktiviert ist es inzwischen :-) Ist ok, dein BIOS ist IMHO nicht ACPI-fähig. hmm... bedeutet das, dass auch kein IRQ sharing möglich ist ? CONFIG_ACPI_BOOT=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set Must du einschalten, wenn du (APM)-Powermanagement für Festplatten und Abschalten benutzen wilst. okay, vielen dank - zumindest beim herunterfahren schaltet er die Festplatte inzwischen ab und der Rechner schaltet sich auch automatisch ab - also auch das scheint wohl ein Bestandteil von APM zu sein. # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_MSI is not set
Re: irq routing conflict - einige varianten
hallo liste, Versuch mal am lilo(grub boot-prompt den Parameter pci=biosirq sorry, hat leider nichts bewirkt, es kommt weiterhin ein irq routing conflict Auch die anderen Parameter zu pci,apic,acpi sind für dich von Interesse. Siehe Dokumentation zu deinem Kernel, kernel-parameters.txt acpi=noirq habe ich mal probiert, der kernel zeigt sich jedoch auch davon unbeeindruckt. um ganz sicher zu gehen, habe ich den kernel nochmals komplett ohne acpi kompiliert, das problem tritt jedoch weiterhin auf. warum will der linux kernel andere irqs zuordnen, bringt einen routing conflict, obwohl die karten mit den bios-irqs dann funktionieren ? da ich die de4x5-karte ausgebaut habe, muss ja das modul nicht mehr geladen werden, der kernel 2.6.8.1 probiert es aber beim booten immer, also habe ich einfach die .ko datei gelöscht, nun kommt (voraussehbar) not found. da modconf nicht funktioniert (leere liste,update-modules bringt nichts, warum auch immer) habe ich selbst in /etc/modprobe.conf (welche auf /lib/modules/modprobe.conf verweist (include)) geschaut, ob hier ein verweis auf de4x5 zu finden war - fehlanzeige. nun stellt sich die frage, warum der kernel de4x5 weiterhin laden will - gibt es da noch weitere dateien ? (ich verwende keine initrd) bei der realtek karte ist genau das gegenteil der fall. ich muss das modul immer mit insmod kompletter pfad zu 8139too.ko laden, modprobe 8139too kann man zwar eingeben, doch es passiert nichts, laut lsmod wird das modul nicht geladen, es kommt aber auch kein fehler bei modprobe. weiterhin bringt ein eintrag in der modprobe.conf nichts, also install rtl8139 /bin/true wird auch keine beachtung geschenkt. beim laden von mISDN kommen übrigens auch die routing-probleme, die karten funktionieren aber. da hier acpi, apm, apic (ist das dasselbe wie acpi ?) und pnp involviert zu sein scheinen, stellt sich die frage, ob man das hier überhaupt braucht - mir reicht ein minimales system, das die vom bios zugewiesenen irqs verwendet, braucht also kein irq sharing zu machen, braucht keine acpi-features zu unterstützten, braucht nicht automatisch auszugehen, lediglich am automatischen abschalten der festplatte nach inaktivität bin ich interessiert. weiterhin ist mir auch bei anderen systemen aufgefallen, dass der kernel manchmal automatisch bemerkt, wenn neue hardware eingebaut wurde und dann das passende modul lädt, wenn es denn vorhanden ist. warum ist das hier mit der realtek karte nicht so ? ich habe mal teile aus der kern.log und meine kernelkonfiguration angehängt, vielleicht hilft das weiter. falls ein debuggen im rahmen von emails hier nicht möglich ist, könnte ich auch das root-passwort mit ssh zugang(nicht auf der liste direkt*g*) zur verfügung stellen. mfg christoph /proc/interrupts: CPU0 0: 1401797 XT-PIC timer 1: 656 XT-PIC i8042 2: 0 XT-PIC cascade 9: 35 XT-PIC HFC PCI 10: 1 XT-PIC HFC PCI 11: 113 XT-PIC eth0 12: 72 XT-PIC eth1 14: 5374 XT-PIC ide0 15: 16 XT-PIC ide1 NMI: 0 LOC: 1401769 ERR: 2 MIS: 0 /usr/src/linux/.config # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set CONFIG_M586MMX=y # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y
irq routing conflict - einige varianten
Hallo Liste, ich habe ein problem mit 2 pci netzwerkkarten in einem rechner mit woody als OS bekomme beim laden eines moduls einen irq routing conlict - ich habe schon einiges an steckplatz-vertauschen durchprobiert, jedoch komme ich einfach nicht weiter. das system ist so aufgebaut: AGP - IRQ9 RivaTNT === PCI 1 - IRQ9-- leer -- === PCI 2 - IRQ10 --- ISDN #1 --- (HFC-S, mISDN) === PCI 3 - IRQ11 --- ISDN #2 --- (HFC-S, mISDN) === PCI 4 - IRQ12 --- LAN #1 --- (Davicom DM9102AF, modul: tulip/dmfe ) === PCI 5 - IRQ9 LAN #2 (digital 21143-PD/davicom DM9101F (2 chips drauf, aber ein RJ45-port), modul: tulip/de4x5 ) das sind die interrupts, wie sie das bios den pci steckplätzen anfangs zuteilt (in der pci-tabelle sichtbar während des bootvorgangs) und welche karten anfangs in welchem steckplatz waren - was mit kernel 2.6.7 (und 2.4.18) auch funktioniert hat. da aber bei pbx4linux 2.4 ein unangenehmes echo beim telefonieren auftrat das t-com sinus telefon sich hingegen dem siemes oft aufhängte beim auflegen (batterie raus, rein) entschied ich mich, die neue pbx4linux 2.5 mit neuerem mISDN Treiber und neuem kernel 2.6.8.1 zu installieren - in der hoffung, dass die probleme behoben sind. Also kernel-source geladen, konfiguriert, kompiliert und gebootet - aber er hängt bei autoconfiguring network devices, kein vorankommen mehr, strg+c hilft auch nicht. Ich schaute also in der kern.log nach, und sah, dass LAN#2 einige meldungen brachte beim modul-laden - using Mii-controller, if the device won't work mail to etc nunja, die netzwerkkarte funktionierte nicht (wahrscheinlich deswegen der hänger bei autoconfiguring ...)- also baute ich sie aus - und das booten mit 2.6.8.1 klappte. daraufhin baute ich die karte wieder ein, und testete mit dem debian 2.4.18-bf24 kernel, dieser bootete und ich konnte beide karten wieder verwenden - wie auch beim 2.6.7 (obwohl die mii-meldung weiterhin kam), beim 2.6.8.1 geht es jedoch nicht. da die karte auf IRQ 9 lag (pci 5), schaltete ich im bios einfach assign irq to vga ab - aber es änderte nichts an diesem sachverhalt. das wäre schon etwas, was mich brennend interessieren würde - wie ist sowas denn möglich - bug in 2.6.8.1 ? Als ich die kern.log durchschaute, war auch ein irq routing conflict von LAN#1 erkennbar - das gerät lief, wie auch vom bios angezeigt, auf IRQ12 - aber der kernel meinte (kern.log) wants IRQ 9 - diese meldung erschien bei allen kernelversionen, war mir bis dahin aber nicht aufgefallen, weil die karte problemlos funktionierte - trotz angezeigtem irq routing conflict. im bios ist plug play aware OS auf no gestellt - ich weiß zwar nicht, was das bewirkt und ob die einstellung generell bei linux korrekt ist, nur bei dieser konfiguration korrekt ist bzw. es überhaupt bei linux so eingestellt sein sollte - ich hatte nur etwas von der einstellung im zusammenhang mit pci karten, irq problemen und plug play gelesen - vielleicht ist sie also hier relevant. das mainboard hat zwar isa steckplätze, jedoch ist bei jedem interrupt pci/pnp eingestellt. nun, da die karte LAN#1 auf IRQ9 wollte (warum auch immer) baute ich sie in PCI 5 ein (LAN#2 ausgebaut) - sie (LAN#1) war zwar nun auf IRQ9, aber es gab wieder einen routing conflict; sie wollte nun interessanterweise auf IRQ11. Also habe ich ISDN#2 ausgebaut (PCI 3)und dort die netzwerkkarte rein - hier hat dann das modul ohne probleme geladen - auf irq 11, problem (anscheinend) gelöst. lan #2 funktionierte bei 2.6.8.1 aber weiterhin nicht. also probierte ich als LAN#2 eine rtl8139D auf PCI#5 aus. zunächste einmal kernel 2.6.8.1 gebootet - bei diesem jedoch hatte ich die gesamte kategorie für pci/onboard netzwerkkarten NICHT mit einkompiliert, also auch die darin enhaltenen realtek-module waren nicht verfügbar, da vorher beides karten waren (dmfe, de4x5), die in der tulip kategorie bei menuconfig zu finden sind, also NICHT unter pci/onboard netzwerkkarten, aber trotzdem unter ethernet 10/100mbit. der kernel kannte also die rtl8139d karte nicht. doch - man kann es schon fast ahnen *g* - LAN#1 wurde zwar nun ohne routing conflict geladen, war jedoch auf IRQ 0 (?!?) und funktionierte nicht (egal ob im bios assign irq to vga an oder aus war). also die neue LAN#2 (rtl8139d) in den PCI 4 statt PCI 5 und nochmals gebootet (2.6.8.1) - wieder ein irq routing conflict, LAN#1 war auf irq 11 und wollte jetzt auf (*würfel*...) irq 10, also zu ISDN#1. ISDN#2 war während dieser versuche ausgebaut. da mir das probieren nun echt zuviel wird, die karten vom bios zwar sauber angeordnet werden zu den IRQs, aber unter linux auf einmal was anderes machen wollen, denke ich, dass abgesehen vom probieren ein logisches vorgehen sinnvoll wäre. da es aber bei mir zuviele unbekannten gibt - wie, - was acpi mit interrupts verteilen zu tun hat - was es bewirkt, PNP im kernel zu aktivieren - welche einstellung im plug play aware OS wann korrekt ist - wie und wann bzw. ob linux IRQ sharing unterstützt (braucht man acpi,
Raid Arrays verbinden
Hallo Liste, ich habe vor einen samba-fileserver mit debian 3.0 einzurichten,welcher auf einem Netzlaufwerk ~800GB Speicher bietet. Um auch beim Ausfall einerfestplatte datensicherheit gewährleisten zu können, kommt also noch Raid 1/5/10 ins spiel. möglich wären also 4 400GB festplatten, jeweils 2 davon im raid1 verbund, damit man 800GB zur Verfügung hat. Das Problem dabei ist nun, dass ich nicht weiß, wie sich 2 400gbraid1-arrays zu einer 800gb "partition" "zusammenschalten" lassen, also man beispielsweise eine partition mit 800GB in /files einhängen kann und die dateien in diesem ordner dann automatisch auf die 2 arrays verteilt werden gibt es da entsprechende tools, eine möglichkeit über den linuxkernel etwas zu machen oder muss ein derartiges "zusammenfügen" von arrays auf hardwarebasis (mit einem bestimmten raid controller?) geschehen ? es müssten auch nicht unbedingt jeweils 2 400gb festplatten sein, nur alsraid1-setupist es beispielsweise eine sinnvolle lösung. bei kleineren (also auch mehr als 4) festplattenwäre evtl. dann wie auch bei späteren erweiterungen der speicherkapazitätraid5 sinnvoller als raid1. nun, lange rede, kurzer sinn *g* - gibt es zur zusammenführung von mehreren arrays die ein oder andere lösung bzw. welche konfiguration wäre sinnvoll (pata/sata/scsi) ? mfg christoph klein
Re: Raid Arrays verbinden
hallo liste, zunächst einmal ein danke für viele interessante ratschläge :-) Wie erstellst Du denn die RAID Arrays? Software oder Hardware-RAID? nun, das ist momentan eigentlich noch offen, aber ein hardware-raid scheint doch um einiges schneller zu sein ;-) Für deinen Fall: beide Arrays erstellen, dort ein PV drauf und die beiden dann in eine VG. Darin dann genau ein LV mit Dateisystem erstellen. Vielen dank für deine ausführlichen erläuterungen und den link, LVM ist genau das, was ich gesucht habe - danke :-) Wenn Du Software-RAID benutzt, dann kannst Du auch gleich RAID-5 nehmen und hast auch weniger Verschnitt (bei 4 Platten a 400G solltest Du rund 1,2T Kapazität bekommen). hört sich gut an, soweit ich das nun verstehe, ist software-raid 5 in verbindung mit LVM auf jeden fall eine mögliche lösung. Wenn du es dir leisten kannst, ist SCSI sicher das beste. hmm also ich habe mich mal umgeschaut, die größte (aktuelle) SCSI-Festplatte, die ich gefunden habe, ist diese hier: http://www.geizhals.at/deutschland/a99871.html davon 3 oder 4 stück - nun ja *g*, sicher ist die lebensdauer der platten höher, was auch durchaus sehr wünschenswert ist, doch beim 3-4 fachen preis kann man auch (mind.(garantie)) 2-3mal ide/sata platten austauschen *g* gibt es denn noch weitere entscheidende fakten, welche für scsi festplatten sprechen - also die mehrausgabe rentabel machen ? Wenn Du noch nichts geplant hast und noch die freie Wahl (auch in Hinsicht auf etwas Buget), würde ich Dir zu vier großen PATA oder SATA Platten in Verbindung mit einem 3ware RAID-Controller raten. Die werden von Haus aus von Linux unterstützt und Du bekommst ein echtes Hardware RAID-5 (bei den 4 Port Controllern, es gibt sie bis zu 12 Ports). jo, das wäre dann vermutlich die beste lösung, aus preis/leistungs-sicht scheint sie auch erschwinglich zu sein :-) die linux unterstützung, dh. sogar der woody-standard-kernel (wegen der installation...) unterstützt über das 3w- modul die (neueren) 3ware s-ata controller ? Nimm einen 3Ware 3w75xx mit 4 Kanälen und hänge die 4 Platten dran... Dann haste 1200 GBytes und um den Rest kümmert sich der Controller. dh mit dem controller könnte man auch ohne LVM ohne weitere software-tools ein raid5 array, das den ausfall einer festplatte überlebt, gleichzeitig ~1200gbyte speicher bietet und dem betriebssystem als _eine_ festplatte, welche sich herkömmlich partitionieren lässt, erscheint, erstellen ? SATA. Da Du von 400 GByte sprichst, meinste sicher die SATA platten von IBM/HITACHI... Die sind tierisch schnell... genau, an die hatte ich gedacht ;-) zu den 3ware controllern, hätte noch 2 fragen... beide, die mir sinnvoll erscheinen http://www.geizhals.at/deutschland/a100695.html http://www.geizhals.at/deutschland/a100697.html sind 64bit pcisind diese dann auch in einem herkömmlichen pci steckplatz (32bit?) nutzbar ? oder, falls nicht, würde mit einem 3ware controller auch ein mainboard mit 64bit-pci einhergehen müssen. bei tyan beispielsweise gibt's die boards aber erst ab den dual-cpu modellen mit 64bit-pci steckplätzen. nun stellt sich die frage, ob 2 opteron cpus für einen reinen fileserver auch lohnenswert sind, bzw. sich 64bit-pci selbst rentiert... falls die controller auch in einem 32bit-pci steckplatz funktionieren, würde ich zu einem asus a8v deluxe tendieren (sockel 939), 1024mb Ram (samba prozesse) und einer athlon 64 cpu, um die 3500+ - oder ist selbst das noch überdimensioniert ? ich habe noch keine erfahrungen mit hardware-raid, also inwieweit der controller die cpu entlastet die zweite frage wäre, ob es denn, im falle des 8x controllers, möglich ist, ein bestehendes raid 5 array des 3ware controllers mit 4 platten nachträglich um einige festplatten zu erweitern/vergrößern (vergleichbar mit LVM) ? nochmals vielen dank für eure hilfe :-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Alternative zu cloop
Hallo Jörg, zunächst vielen dank für die antwort :-) extract_compressed_fs bzw. create_compressed_fs kommen ohne die cloop-Module aus. Allerdings gibt es zwei verschiedene Versionen davon. Eine Version ist für = cloop-1.x, das andere für cloop-2.x. hmm.. also ich habe extract_compressed_fs übers apt als woody paket installiert wenn ich beispielsweise knoppix 3.4 entpacken will, erscheint folgende fehlermeldung: server:~# extract_compressed_fs KNOPPIX 29715 blocks of size 65536. Preamble: #!/bin/sh #V2.0 Format modprobe cloop file=$0 mount -r -t iso9660 /dev/cloop $1 exit $? Size 237864 for block 0 (offset 0) too big anscheinend versucht es das cloop-modul zu laden, was dann aber fehlschlägt und folglich das entpacken nicht funktioniert. möglicherweise kommt eine andere version von extract_compressed_fs ohne das modul aus, jedoch weiß ich nicht, wo man ein solches herbekommt ... (möglichst als binary :-)) Mach mal ein modinfo cloop, dann solltest Du sehen woran es liegen könnte. das cloop.o aus der initrd für kernel 2.6 von knoppix wurde laut modinfo mit gcc 2.95 kompiliert. möglichweise erkennt es mein kernel deswegen als ungültig weil der kernel selbst mit gcc-3.0 kompiliert wurde. sowohl das knoppix cloop.o als auch mein kernel wurden mit cputype 386 kompiliert. vermutlich muss also kernel und modul mit dem gleichen kompiler in der gleichen version kompiliert werden, damit sich das modul laden lässt, es der kernel akzeptiert... - aber nur eine vermutung :-) Das cloop-Modul aus dem 2.6er Kernel ist für die cloop-2.x Images gebaut. hmm... im sourcecode meines 2.6.7 kernels war das cloop glaube ich nicht dabei, nach einem updatedb und locate cloop | grep usr/src/linux gab es keine ergebnisse, dh entweder ist es doch dabei (unter anderem namen) oder ... Die alten Images (z.B. v. Knoppix) gehen damit nicht. meinst du das cloop aus der knoppix 3.4 initrd für 2.6, wobei dann aber das knoppix 3.4 selbst ein cloop 2.x-image (also ein neues) sein müsste oder trotz des kernel 2.6 bei knoppix 3.4 ein altes cloop verwendet wurde, um auch das alte image laden zu können, falls es denn ein altes wäre ;-) Wenn ich mich recht entsinne, benötigst Du die Module deflate, zlib_deflate und zlib_inflate danke für den hinweis, ich werden hinsichtlich dieser module mal schauen, ob sie entweder im kernel selbst sind oder kompiliert zur verfügung stehen :-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Alternative zu cloop
Hallo Liste, da ich es seit einigen wochen nicht hinbekomme, das paket cloop-src mit kernel 2.6.7 zu kompilieren ( /usr/src/linux/conf.vars kann nicht gefunden werden etc... habe es inzwischen aufgegeben *g*) suche ich eine alternative ein mit cloop erstelltes fs zu entpacken. das im paket cloop-utils enthaltene extract_compressed_fs scheint leider auch das cloop.o modul im kernel geladen zu benötigen. also habe ich, da das kompilieren nach der vorgehensweise, wie in der README des pakets beschrieben wurde, nicht funktionierte, versucht, das bereits kompilierte cloop.o aus der knoppix 3.4 kernel 2.6 initrd (aka miniroot) zu laden = invalid module format (warum eigentlich, welche anforderungen muss ein modul erfüllen, damit es nicht ungültig ist ?)... wie auch immer, alles was ich versucht habe funktioniert nicht - suche daher eine komplett andere möglichkeit; möglichst unter vermeidung von kompilieren oder modulen... oder natürlich jemand hat ein modul, das ohne wochenlanges hickhack lädt ;-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Woody + mISDN als Samba-Faxdrucker
hallo liste, ich versuche einen faxserver auf einem woody-rechner zum laufen zu kriegen. der kernel ist 2.6.7 und als Modul für die ISDN Karten (HFC-S) wird mISDN verwendet, was auch mit der pbx schon funktioniert. zusätzlich soll über den samba eine art faxdrucker verfügbar gemacht werden, also man druckt was mit den windows-clients auf dem drucker und es wird als fax versandt. nach einigem googlen bin ich auf hylafax gestoßen, jedoch weiß ich nicht ob das zum einen mit kernel 2.6 und mISDN funktioniert und zum anderen ob man den faxserver als samba-freigabe verfügbar machen kann. gibt es denn für die mISDN/samba umgebung unter woody eine passende lösung ? mfg christoph klein -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
debian, sk98lin, kernel 2.6 und FullDuplex
Hallo Liste, nachdem ich letztens sarge testing installiert hatte, stellte ich fest, dass die onboard Netzwerkkarte nur im Halbduplexmodus läuft. Dafür zuständig ist das Modul sk98lin (unter kernel 2.6.3), welches beim booten automatisch geladen wird, also ich habe nichts mit insmod, modprobe etc machen müssen, es hat von anfang an "funktioniert". um nun den FullDuplex modus zu setzen gibt es ja bei Modulen die möglichkeit bei deren ladevorgang mit zb insmod einige parameter zu bestimmen, welche unter anderem auch die duplex-sache regeln. http://www.zevils.com/cgi-bin/man/man2html?sk98lin+4 zu finden hier als "DupCap_A=Full" da aber insmod nicht direkt verwendet wird, sondern das modul beim booten geladen wird, müsste doch zu diesem zeitpunkt auch der entsprechende parameter übergeben werden; Nach einigem suchen in /etc/modutils/* , also von der /etc/modules.conf wurde abgeraten, da diese beim bootvorgang scheinbar wieder überschrieben wird. ich habe also eine datei angelegt /etc/modutils/network in der folgendes steht: alias eth0 sk98lin options sk98lin DupCap_A=Full nun zeigt sich das Modul davon aber unbeeindruckt, beim booten wird weiterhin "Duplex Mode: Half" angezeigt. weilich dabei auch nicht mehr weiter weiß, hoffe ich, dass hier in der Liste vielleicht noch jemand einen Tipp parat hat :-) mfg christoph
Re: debian, sk98lin, kernel 2.6 und FullDuplex
Hallo Liste, das Problem ist nun gelöst, FullDuplex funktioniert. Ich habe die Zeilen alias eth0 sk98lin options sk98lin DupCap_A=Full in die /etc/modprobe.d/aliases eingetragen - auch wenn das letzte kein alias ist; es scheint egal zu sein in welcher datei es steht, solange sie im modprobe.d verzeichnis ist ;-) Vielen Dank für die schnelle Hilfe :-) mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Ich finde meine HD nicht mehr (2.6.8-rc1)
hallo, ich würde dir zur sicherheit den normalen ata-treiber empfehlen, wenn der erstmal funktioniert kannst du weiter gehen und die libata genauer anschauen. für den ata treiber folgendes aktivieren (einkompilieren): Device drivers = ATA / ATAPI / MFM / RLL support * Generic / default IDE chipset support * Generic PCI IDE chipset support * Generic PCI Bus-master DMA support * PCI IDE Chipset support es ist gut möglich, dass es dann funktioniert - falls nicht die via-spezifischen komponenten auch noch einkompilieren. natürlich sollte zb ext2/3 einkompiliert sein bzw. alle kernelkomponenten die zum erfolgreichen mounten der root partition/lesen der dateien erforderlich sind. mfg christoph -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
NFS Root - Diskless Clients
hi leute ich habe ein ziemlich nerviges problem mit meinen diskless clients. der bootvorgang läuft über pxe (intels pro 100/s karten), es wird über pxelinux der kernel geladen. eigentlich sollte der dann das root file system per nfs einbinden, was jedoch nicht funktioniert - das ganze endet mit folgender fehlermeldung: VFS: Cannot open root device nfs or 00:ff Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on 00:ff als kernel verwende ich den 2.4.18-bf also bf24 bei clientimage und server. möglichkeiten warum es nicht funktioniert wären, dass dieser kernel kein nfs-client verhalten unterstützt, was ich aber nicht herausfinden kann; steht ja nirgends *g* oder ? eine weitere möglichkeit ist der fehlende netzwerkkarten-treiber - informationen ob der kernel das eepro100 - modul fest einkompiliert hat habe ich bisher auch nirgends gefunden - also einfach so mal probiert über pxelinux das modul einzuladen: default -datei (pxelinux konfiguration): prompt 1 timeout 1000 label linux kernel rootfs/vmlinuz append init=/sbin/init ip=dhcp root=/dev/nfs nfsroot=192.168.0.1:/usr/local/tftpboot/rootfs vga=0x318 insmod=eepro100 es stellte sich dann die frage woher denn der kernel das modul bekommt, habe es also mal ins tftp-root (/usr/local/tftpboot/) kopiert - funktionierte aber nicht. habe daraufhin etwas über initrd gelesen und es dann auch ausprobiert, bin auf das programm mkinitrd gekommen, jedoch hat das auch etwas unsinn getrieben: im verzeichnis /usr/local/tftpboot/rootfs/ habe ich über debootstrap und basedebs.tar eine komplett neue installation angelegt; via chroot dann auf dem server geladen und mit base-config alles konfiguriert. nun habe ich mkinitrd ausprobiert - im chroot-system bringt es: /usr/sbin/mkinitrd: /192.168.0.1:: Unknown root device Please refer to the manual page. habe /dev/nfs in der chroot-umgebung (also dem client-linux) mit mknod /dev/nfs b 0 255 aber bereits erstellt. = das mkinitrd kommt nicht mit dem nfs-root klar. habe es dann in der original-serverumgebung (also ohne chroot) installiert und ausprobiert, jedoch kommen dann die scsi-treiber für den server usw. auch mit in das image - dem mkinitrd scheint egal zu sein, was ich in die /etc/mkinitrd/modules für module eintrage - die werden immer _zusätzlich_ zu den modulen mit ins image kopiert wie die, die der server verwendet, was wenig bringt, da es ja ein initrd für die clients werden soll - habe es deswegen auch mit mkinitrd gelassen. gibt es denn noch eine möglichkeit kernelmodule während des bootvorgangs einzubinden ohne dass bereits ein rootfs gemountet ist ? unklar ist mir auch wie das mit initrd funktionieren kann, denn das würde ja als rootfs gemountet werden - wird das dann wieder ausgehängt, damit das wirkliche rootfs über NFS gemountet werden kann ??? weil 2 mal gleichzeitig ein / zu mounten geht glaube ich nicht ... das alles setzt natürlich vorraus, dass es an der netzwerkkarte also deren modul liegt. hätte es aber schon gerne dynamisch als modul eingebunden, also nicht fest einkompiliert, da ich anonsten den kernel für die verschiedenen netzwerkkarten an den verschiedenen clients jeweils neu kompilieren müsste - auf dem server mit einer pentium 1 cpu wäre das etwas nerven-und zeitraubend - mal davon abgesehen, dass kernel selbst kompilieren bei mir sowieso noch nie richtig funktioniert hat - aber das is ein anderes thema *g* zusammenfassend: der rootfs-mount fehler kann entweder an der fehlenden netzwerkkartenunterstützung seitens des kernels liegen (kann den client NICHT anpingen), wenn ja, welche möglichkeiten gibt es das betreffende modul möglichst ohne (oder auch mit mkinitrd, wenn es nur irgendwie mal funktioniert) mkinitrd einzubinden oder es liegt an der fehlenden nfs-unterstützung des bf24-kernels und ob diese auch als modul mit eventuell weiteren möglichkeiten eingebunden werden kann - oder beides schon einkompiliert ist und nur einfach so nicht funktioniert *g* also sich die frage stellt, wo man die einkompilierten module unter Umständen nachschauen kann. hoffe, dass mir da jemand helfen kann - schon mal vielen dank im vorraus :-) mfg christoph Mit schönen Grüßen von Yahoo! Mail - http://mail.yahoo.de -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
