eiskernel 2.0.11 (Status 'testing') verfügbar - 2.6er Kernel für eisfair-1
Thomas Bork
es ist eine Entwickler-Version 2.0.11 von eiskernel verfügbar. Intern
wird hierfür der Kernel 2.6.32.44 verwendet.
Diese Kernel-Pakete lassen sich *nur auf Systemen mit schon laufendem
2.6er Kernel* installieren, damit es keine Probleme mit geänderten
Device-Namen der Treiber im 2.6er Kernel gibt und man deswegen nach dem
Update von einem Kernel 2.4 mit einem nicht mehr startenden System
konfrontiert wird.
Diese können nicht völlig ausgeschlossen werden, obwohl in der
Kernel-Konfiguration eine nahezu identische Konfiguration gewählt wurde
und obwohl die Kernel-Update-Pakete wie bei Kernel 2.4 lediglich auf
IDE- und normale SCSI-/SATA-Treiber setzen (libata-PATA-Treiber liegen
zwar modularisiert vor, sind aber nicht fest einkompiliert und werden
beim Kernel-Update auch nicht eingesetzt).
Änderungen zum vorherigen eiskernel 2.0.10:
===========================================
- Update 2.6.32.43 -> 2.6.32.44
Dieses Paket bei http://pack-eis.de:
====================================
NON-SMP: http://www.pack-eis.de/index.php?p=11417
SMP : http://www.pack-eis.de/index.php?p=11418
Gleichzeitig wird wie gewohnt auch das Paket kernel-dev (Version 1.0.11)
mit den Quellen passend zu diesem Kernel freigegeben.
Dieses Paket bei http://pack-eis.de:
====================================
http://www.pack-eis.de/index.php?p=11419
Der Kernel 2.6.32.44:
=====================
http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=shortlog;h=refs/tags/v2.6.32.44
Die vorangegangenen Versionen der 2.6er eiskernel-1-Pakete enthielten:
======================================================================
2.0.10: 2.6.32.43
2.0.9 : 2.6.32.42
2.0.8 : 2.6.32.41
2.0.7 : 2.6.32.39
2.0.6 : 2.6.32.38
2.0.5 : 2.6.32.36
2.0.4 : 2.6.32.35
2.0.3 : 2.6.32.33
2.0.2 : 2.6.32.32
2.0.1 : 2.6.32.30
2.0.0 : 2.6.32.29
Weiterhin viel Spass mit eisfair!
Das Posting geht parallel an spline.eisfair.dev und spline.eisfair.
Produktive Rückmeldungen bitte an spline.eisfair.dev.
--
der tom
[eisfair-team]
Stefan Welte
Am 15.08.2011 21:33, schrieb Thomas Bork:
> es ist eine Entwickler-Version 2.0.11 von eiskernel verfügbar. Intern wird hierfür der Kernel
> 2.6.32.44 verwendet.
>
> Diese Kernel-Pakete lassen sich *nur auf Systemen mit schon laufendem 2.6er Kernel*
> installieren, damit es keine Probleme mit geänderten Device-Namen der Treiber im 2.6er Kernel
> gibt und man deswegen nach dem Update von einem Kernel 2.4 mit einem nicht mehr startenden
> System konfrontiert wird.
Per old-eis sollte die Kiste dann doch immernoch tadellos starten, oder nicht?
Ebenfalls zwei eis1 mit eiskernel 1.26.0 auf 2.0.10 bzw. 2.0.11 gebracht.
Probleme:
Nachdem ich per cat /proc/cmdline nach einmaligem lilo-boot erfuhr, daß das root-device dem
kernel als anderer parameter (root=806 statt root=/dev/sda6) übergeben wird, klappte auch mein
boot per grub wieder anstatt in einem panic zu enden (Anmerkung: root=/dev/sda6 steht trotzdem
in der lilo.conf). -> gelöst
ICEcube-Paket (raid-Überwachung) funktioniert nicht mehr, kein PIEPton mehr.
-> ungelöst
Asterisk fehlen min. die zaptel, zaphfc, qozap und cwain module.
-> ungelöst
"
Loading SCSI modules
insmod: can't read 'cdrom': Is a directory
insmod: can't read 'sr_mod': No such file or directory
insmod: can't read 'isofs': No such file or directory
insmod: can't read 'st': No such file or directory
loading cdrom drivers ...
"
-> ungelöst
Haufenweise insmod Fehler beim Start des routing-Pakets, obwohl die ip_tables,... Module später
korrekt geladen sind/scheinen.
-> ungelöst
Die PS2-Tastatur reagiert nicht mehr, nach Ab- und Wiedereinstöpseln geht sie wieder.
-> ungelöst, aber partiell: nur bei boot per grub, mit lilo ist es ok
Kein Problem:
An /tmp sind bei mir keine Rechte verbogen, alles ok (1777).
Die Kiste fährt hoch und arbeitet ansonsten wie gewohnt, danke Tom.
Gruß,
Stefan
Thomas Bork
> Per old-eis sollte die Kiste dann doch immernoch tadellos starten, oder nicht?
Wenn lilo.conf noch passt und die Modul-Verzeichnisse andere Namen haben
- ja.
> Ebenfalls zwei eis1 mit eiskernel 1.26.0 auf 2.0.10 bzw. 2.0.11 gebracht.
> Probleme:
> Nachdem ich per cat /proc/cmdline nach einmaligem lilo-boot erfuhr, daß das root-device dem
> kernel als anderer parameter (root=806 statt root=/dev/sda6) übergeben wird, klappte auch mein
> boot per grub wieder anstatt in einem panic zu enden (Anmerkung: root=/dev/sda6 steht trotzdem
> in der lilo.conf). -> gelöst
Mir ist nicht klar, wozu Du grub benötigst, welches für eisfair-1 weder
mitgebracht noch unterstützt wird.
> ICEcube-Paket (raid-Überwachung) funktioniert nicht mehr, kein PIEPton mehr.
> -> ungelöst
Sicher hat noch niemand ICEcube für den Kernel 2.6 angepasst.
> Asterisk fehlen min. die zaptel, zaphfc, qozap und cwain module.
> -> ungelöst
Das gilt auch für Asterisk.
> "
> Loading SCSI modules
> insmod: can't read 'cdrom': Is a directory
> insmod: can't read 'sr_mod': No such file or directory
> insmod: can't read 'isofs': No such file or directory
> insmod: can't read 'st': No such file or directory
> loading cdrom drivers ...
> "
> -> ungelöst
Wann tritt das auf? Hast Du in der base Modulnamen angegeben, die so
nicht mehr existieren? Eventuell muss man da auch noch mal nachsehen, ob
statt insmod nicht besser modprobe verwendet werden sollte.
> Haufenweise insmod Fehler beim Start des routing-Pakets, obwohl die ip_tables,... Module später
> korrekt geladen sind/scheinen.
> -> ungelöst
Welche Fehlermeldungen genau?
--
der tom
[eisfair-team]
Stefan Welte
> Am 15.08.2011 22:25, schrieb Stefan Welte:
>> Ebenfalls zwei eis1 mit eiskernel 1.26.0 auf 2.0.10 bzw. 2.0.11 gebracht.
>> Probleme:
>> Nachdem ich per cat /proc/cmdline nach einmaligem lilo-boot erfuhr, daß das root-device dem
>> kernel als anderer parameter (root=806 statt root=/dev/sda6) übergeben wird, klappte auch mein
>> boot per grub wieder anstatt in einem panic zu enden (Anmerkung: root=/dev/sda6 steht trotzdem
>> in der lilo.conf). -> gelöst
>
> Mir ist nicht klar, wozu Du grub benötigst, welches für eisfair-1 weder mitgebracht noch
> unterstützt wird.
editieren kann bei grub, bei lilo nicht.
Zudem kann ich grml-small (das in /grml liegt) starten, um zum Beispiel ein Backup meines eis zu
machen; oder memtest, oder oder.... Würde evtl. auch per lilo gehen, aber ich bin halt mit grub
"groß" geworden.
>> "
>> Loading SCSI modules
>> insmod: can't read 'cdrom': Is a directory
>> insmod: can't read 'sr_mod': No such file or directory
>> insmod: can't read 'isofs': No such file or directory
>> insmod: can't read 'st': No such file or directory
>> loading cdrom drivers ...
>> "
>> -> ungelöst
>
> Wann tritt das auf?
INIT: Entering runlevel: 2
Running /etc/init.d/rc
Switching from runlevel N to 2
Loading 245-char ...
Loading Unicode mapping table...
Loading /lib/kdb/...
setting up hostname ...
loading kernel modules with modprobe ...
loop: module loaded
Loading SCSI modules
insmod: can't read 'cdrom': Is a directory
insmod: can't read 'sr_mod': No such file or directory
insmod: can't read 'isofs': No such file or directory
insmod: can't read 'st': No such file or directory
loading cdrom drivers ...
...
> Hast Du in der base Modulnamen angegeben, die so nicht mehr existieren?
Nein, nur loop und das lädt fehlermedlungsfrei.
Kann nicht sagen, woher "Loading SCSI modules" stammt, aber die Kiste habe ich imho vom 2.2-er
Kernel und irgendwann von IDE auf später SCSI upgegradet. Evtl. stammt das noch daher irgendwie.
Eigene Skripte diesbzgl. kann ich aber ausschließen. "Loading SCSI modules" ist original von
eisfair.
Beim 1.26.0-kernel kommt:
...
Loading SCSI modules
Using /lib/modules/2.4.35-wt1-SMP/kernel/drivers/cdrom/cdrom.o
Using /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/sr_mod.o
Using /lib/modules/2.4.35-wt1-SMP/kernel/drivers/fs/isofs/isofs.o
Using /lib/modules/2.4.35-wt1-SMP/kernel/drivers/scsi/st.o
Loading cdrom drivers ...
...
>> Haufenweise insmod Fehler beim Start des routing-Pakets, obwohl die ip_tables,... Module später
>> korrekt geladen sind/scheinen.
>> -> ungelöst
>
> Welche Fehlermeldungen genau?
...
activating routing ...
insmod: can't read 'ip_tables': No such file or directory
insmod: can't read 'ip_conntrack': No such file or directory
insmod: can't read 'iptable_filter': No such file or directory
insmod: can't read 'iptable_nat': No such file or directory
insmod: can't read 'ipt_state': No such file or directory
insmod: can't read 'ipt_MASQUERADE': No such file or directory
insmod: can't read 'ipt_REJECT': No such file or directory
ip_tables: (C) 2000-2006 Netfilter Core Team --- hier scheint ein modul korrekt geladen!?
nf_conntrackversion 0.5.0 (3988 buckets, 15952 max) --- hier scheint ein modul korrekt geladen!?
insmod: can't read 'ip_conntrack_ftp': No such file or directory
insmod: can't read 'ip_nat_ftp': No such file or directory
setting up resolv.conf ...
...
Beim 1.26.0-kernel kommt:
...
Using /lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
...
Entweder ich habe geträumt, aber ich meine, daß bei der Installation des neuen Kernel auch das
routing-Paket upgedadet worden ist; zumindest habe ich irgendwas mit einer Änderung von knuffel
2010 gelesen. Jetzt ist laut setup-Packages aber routing 1.0.2 unstable installiert von 2005.
*grübel*
Habe das Gefühl, daß es mit damit zu tun hat, daß die Module nun .ko statt .o vom Typ sind;
sollte aber beim laden eigentlich egal sein. *grübel*
Gruß,
Stefan
Holger Bruenjes
> Habe das Gefühl, daß es mit damit zu tun hat, daß die Module nun .ko statt .o vom Typ sind;
> sollte aber beim laden eigentlich egal sein. *grübel*
Mach doch nochmal ein 'depmod -a'
oder ein grep auf modules.dep
grep ip_tables /lib/modules/2.6.32-eisfair-1/modules.dep
Holger
Stefan Welte
sowohl vor, als auch nach
$ depmod -a
sieht es so aus:
$ grep ip_tables /lib/modules/2.6.32-eisfair-1/modules.dep
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/iptable_filter.ko:
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/ip_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/netfilter/x_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/iptable_nat.ko:
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/ip_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/nf_nat.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/netfilter/x_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/netfilter/nf_conntrack.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/iptable_raw.ko:
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/ip_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/netfilter/x_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/iptable_mangle.ko:
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/ip_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/netfilter/x_tables.ko
/lib/modules/2.6.32-eisfair-1/kernel/net/ipv4/netfilter/ip_tables.ko:
/lib/modules/2.6.32-eisfair-1/kernel/net/netfilter/x_tables.ko
wenn ich das für die 1.26.0-SMP-Module mache, ist die Liste länger:
$ grep ip_tables /lib/modules/2.4.35-wt1-SMP/modules.dep
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_DSCP.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_ECN.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_LOG.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_MARK.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o \
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_REDIRECT.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o \
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_REJECT.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_TCPMSS.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_TOS.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_ULOG.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_ah.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_conntrack.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o \
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_dscp.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_ecn.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_esp.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_geoip.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_helper.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o \
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_length.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_limit.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_mac.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_mark.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_multiport.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_owner.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_pkttype.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_recent.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_state.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o \
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_tcpmss.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_tos.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_ttl.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ipt_unclean.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/iptable_filter.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/iptable_mangle.o:
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.35-wt1-SMP/kernel/net/ipv4/netfilter/ip_tables.o
Es ist ja auch nicht so, daß keine ip* -Module geladen werden:
$ lsmod|grep ip
ipv6 174316 20
ipt_REJECT 1585 1
ipt_MASQUERADE 1114 1
iptable_nat 2694 1
nf_nat 10175 2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4 7486 5 iptable_nat,nf_nat
nf_conntrack 35141 5 ipt_MASQUERADE,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
nf_defrag_ipv4 803 1 nf_conntrack_ipv4
iptable_filter 1026 1
ip_tables 6695 2 iptable_nat,iptable_filter
x_tables 7986 6 ipt_REJECT,ipt_MASQUERADE,xt_tcpudp,xt_state,iptable_nat,ip_tables
Es sind halt Fehlermeldung, die anscheinend das routing-Paket erzeugt beim Start.
Gruß,
Stefan
Olaf Jaehrling
--- Original-Nachricht ---
Absender: Stefan Welte
Datum: 15.08.2011 22:25
>
>
> Asterisk fehlen min. die zaptel, zaphfc, qozap und cwain module.
> -> ungelöst
>
Wird es vermutlich auch nicht für den 2.6-er Kernel geben, da sich die
zaphfc-Module nicht mehr kompilieren lassen und dahdi nur mit
original-Karten läuft. Alle Versuche meinerseits und auch von
Heinz-Peter sind bisher ins Leere gelaufen. Wenn sich da mal was ändern
sollte, wird es auch wieder den * für eisfair-1/-2 und dem 2.6-er Kernel
geben.
Gruß
Olaf
Stefan Welte
Durch googelei habe ich dazu nix gefunden.
Liegt das am 2.6er kernel oder an asterisk 1.6 bzw. 1.8?
Kennst du diese Seiten:
http://niki.hammler.info/wiki/Der_steinige_Weg_nach_zaphfc
http://verfaction.de/zaphfc
Da hat jemand zaphfc mit 2.6-er kernel gebaut, so wie es scheint.
Stefan
Holger Bruenjes
> Es sind halt Fehlermeldung, die anscheinend das routing-Paket erzeugt beim Start.
OK, das Paket wurde auch noch nicht ueberprueft mit dem 2.6er Kernel.
Holger
Holger Bruenjes
Am 2011-08-16 08:52, schrieb Thomas Bork:
>> "
>> Loading SCSI modules
>> insmod: can't read 'cdrom': Is a directory
>> insmod: can't read 'sr_mod': No such file or directory
>> insmod: can't read 'isofs': No such file or directory
>> insmod: can't read 'st': No such file or directory
>> loading cdrom drivers ...
>> "
>> -> ungelöst
>
> Wann tritt das auf? Hast Du in der base Modulnamen angegeben, die so
> nicht mehr existieren? Eventuell muss man da auch noch mal nachsehen, ob
> statt insmod nicht besser modprobe verwendet werden sollte.
Das ist bisher noch nicht aufgefallen, :-( das wird in
'/etc/init.d/ide' geladen, zumindest teilweise.
insmod schlaegt fehl
da muessen wir jetzt modprobe nutzen
Holger
Thomas Bork
> Das ist bisher noch nicht aufgefallen, :-( das wird in '/etc/init.d/ide'
> geladen, zumindest teilweise.
> insmod schlaegt fehl
> da muessen wir jetzt modprobe nutzen
Je nach Kernel-Version...
--
der tom
[eisfair-team]
Holger Bruenjes
> Je nach Kernel-Version...
joo
Holger
Thomas Bork
> joo
Etwa wie in /etc/init.d/modules.
Wobei ide-cd im Kernel 2.6 aber ide-cd_mod heisst...
--
der tom
[eisfair-team]
Holger Bruenjes
> Etwa wie in /etc/init.d/modules.
etwa ;-)
> Wobei ide-cd im Kernel 2.6 aber ide-cd_mod heisst..
joo, wobei ide-cd ein alias ist, wuerde auch funktionieren,
modinfo ide-cd_mod
guck es Dir an, dann siehst Du was ich gemacht habe ;-)
Holger
Thomas Bork
>>> Loading SCSI modules
>>> insmod: can't read 'cdrom': Is a directory
>>> insmod: can't read 'sr_mod': No such file or directory
>>> insmod: can't read 'isofs': No such file or directory
>>> insmod: can't read 'st': No such file or directory
>>> loading cdrom drivers ...
[...]
> Das ist bisher noch nicht aufgefallen, :-( das wird in '/etc/init.d/ide'
> geladen, zumindest teilweise.
Siehe oben:
Die Fehlermeldungen erscheinen schon, _bevor_ /etc/init.d/ide geladen wird.
Keine Ahnung, woher die stammen. Ein Kernel-Update erzeugt eine korrekte
initrd mit SCSI/SATA-Ladebefehlen.
Die Meldungen stammen daher entweder aus einer selbst zurechtgefummelten
initrd oder einem init-Skript, welches nicht von uns stammt.
> insmod schlaegt fehl
> da muessen wir jetzt modprobe nutzen
Trotzdem muss /etc/init.d/ide angepasst werden - das ist aber nicht der
Grund für obige Meldungen...
--
der tom
[eisfair-team]
Holger Bruenjes
> Die Meldungen stammen daher entweder aus einer selbst zurechtgefummelten
> initrd oder einem init-Skript, welches nicht von uns stammt.
joo, insmod will mit dem Kernel-2.6.irgendwann eine komplette
Aufrufzeile.
> Trotzdem muss /etc/init.d/ide angepasst werden - das ist aber nicht der
> Grund für obige Meldungen...
joo, [x] done
Holger
Stefan Welte
> Am 16.08.2011 18:53, schrieb Holger Bruenjes:
>
>>>> Loading SCSI modules
>>>> insmod: can't read 'cdrom': Is a directory
>>>> insmod: can't read 'sr_mod': No such file or directory
>>>> insmod: can't read 'isofs': No such file or directory
>>>> insmod: can't read 'st': No such file or directory
>>>> loading cdrom drivers ...
> [...]
>> Das ist bisher noch nicht aufgefallen, :-( das wird in '/etc/init.d/ide'
>> geladen, zumindest teilweise.
>
> Siehe oben:
> Die Fehlermeldungen erscheinen schon, _bevor_ /etc/init.d/ide geladen wird.
> Keine Ahnung, woher die stammen. Ein Kernel-Update erzeugt eine korrekte initrd mit
> SCSI/SATA-Ladebefehlen.
>
> Die Meldungen stammen daher entweder aus einer selbst zurechtgefummelten initrd oder einem
> init-Skript, welches nicht von uns stammt.
Nope, habs gefunden.
$ cd /etc
$ la rc2.d/S01scsi
lrwxrwxrwx 1 root root 14 22. Aug 2009 rc2.d/S01scsi -> ../init.d/scsi
$ la init.d/scsi
-rwxrwxr-x 1 root root 972 25. Jun 2002 init.d/scsi
$ cat init.d/scsi
#! /bin/sh
DRV=aic7xxx
case $1
in
start)
echo "Loading SCSI modules"
f=`echo /proc/scsi/*` # SCSI already in kernel?
if [ "$f" = "/proc/scsi/*" ] # no...
then
/sbin/insmod scsi_mod # load SCSI-lowlevel driver
/sbin/insmod $DRV # load adapter specific driver
/sbin/insmod sd_mod # load disk driver
fi
/sbin/insmod cdrom # load generic cdrom driver
/sbin/insmod sr_mod # load scsi cdrom driver
/sbin/insmod isofs # load isofs
/sbin/insmod st # load tape driver
;;
stop)
echo "Unloading SCSI modules"
/sbin/rmmod st 2>/dev/null # unload tape driver
/sbin/rmmod isofs 2>/dev/null # unload isofs
/sbin/rmmod sr_mod 2>/dev/null # unload scsi cdrom driver
/sbin/rmmod cdrom 2>/dev/null # unload generic cdrom driver
/sbin/rmmod sd_mod 2>/dev/null # unload disk driver
/sbin/rmmod $DRV 2>/dev/null # unload adapter specific driver
/sbin/rmmod scsi_mod 2>/dev/null # unload SCSI-lowlevel driver
;;
esac
exit 0
Gruß,
Stefan
Thomas Bork
> Nope, habs gefunden.
Wieso nope?
> $ cat init.d/scsi
> #! /bin/sh
>
> DRV=aic7xxx
Sag ich doch, stammt nicht von uns...
--
der tom
[eisfair-team]
Stefan Welte
> Am 17.08.2011 00:12, schrieb Stefan Welte:
>
>> Nope, habs gefunden.
>
> Wieso nope?
Wegen dem Dateidatum!
2002 war ich noch nicht fähig, solch eine Datei zu erstellen! :-)
Von wem (Person) die genau stammt kann ich nicht sagen, aber sie ist von eisfair (installer,
update,weißdergeier,...).
Oder wer könnte mir das fiese Ding untergeschoben haben?
Stefan
Stefan Heidrich
> es ist eine Entwickler-Version 2.0.11 von eiskernel verfügbar.
Updatze auf 7 Maschinen ohne erkennbare Probleme. Dankeschön!
Viele Grüße
Stefan
Thomas Bork
> Von wem (Person) die genau stammt kann ich nicht sagen, aber sie ist von eisfair (installer,
> update,weißdergeier,...).
Nö, denn sie findet sich nicht in meinen Referenz-Systemen der
Kernel-Versionen 2.4 und 2.6, aus denen die eisfair-1-Installer
generiert werden.
Per Update kann sie auch nicht auf das System gekommen sein, denn die
Referenz-Systeme bekommen jeweils die aktuellen base-Versionen
aufgespielt, so dass es immer einen konsistenten Zustand zwischen
gewachsenen Systemen und per Installer aufgesetzten Systemen geben sollte.
> Oder wer könnte mir das fiese Ding untergeschoben haben?
Stammt eventuell aus der Zeit des Kernel 2.2.x, bei der eine
SCSI-Unterstützung noch etwas anders aussah.
Aber niemand ausser Dir hat diese Datei auf das System gebracht...
--
der tom
[eisfair-team]
Stefan Heidrich
> es ist eine Entwickler-Version 2.0.11 von eiskernel verfügbar.
noch ein Nachtrag. Mir ist nämlich aufgefallen dass der 2.6er-Kernel im
Gegensatz zum 2.4er Speicher wieder frei gibt und das will ich ausdrücklich
positiv anmerken.
Zur genaueren Erklärung: Alle Kernel-Versionen 2.4.x haben Speicher, der
einmal belegt war (hauptsächlich durch Cache) nicht mehr frei gegeben bzw.
konnte man da den Mechanismus nicht nachvollziehen.
Beim neuen Kernel fällt mir auf, dass bei starker Plattenbelastung (z.B.
beim Backup) der Cache ansteigt, aber nach getaner Arbeit auch wieder frei
gegeben wird. Insbesondere bei der grafischen Aufbereitung sieht man das
sehr deutlich: http://www.fam-heidrich.net/eisgraph/day.html
Viele Grüße
Stefan
Fabian Törner
Am 15.08.2011 21:33, schrieb Thomas Bork:
> es ist eine Entwickler-Version 2.0.11 von eiskernel verfügbar. Intern
> wird hierfür der Kernel 2.6.32.44 verwendet.
[...]
irgendwo hakt es bei cpufreq:
--- [messages.log] ---
Aug 3 16:19:49 eis kernel: freq_table: exports duplicate symbol
cpufreq_frequency_get_table (owned by kernel)
Aug 3 16:19:49 eis kernel: powernow-k8: Found 1 AMD Athlon(tm) 64
Processor 3500+ processors (1 cpu cores) (version 2.20.00)
Aug 3 16:19:49 eis kernel: powernow-k8: 0 : fid 0xe (2200 MHz), vid 0x6
Aug 3 16:19:50 eis kernel: powernow-k8: 1 : fid 0xc (2000 MHz), vid 0x8
Aug 3 16:19:50 eis kernel: powernow-k8: 2 : fid 0xa (1800 MHz), vid 0xa
Aug 3 16:19:50 eis kernel: powernow-k8: 3 : fid 0x2 (1000 MHz), vid 0x12
Aug 3 16:19:50 eis kernel: Marking TSC unstable due to cpufreq changes
Aug 3 16:19:50 eis kernel: Switching to clocksource acpi_pm
Aug 3 16:19:50 eis cpufreqd: pmu_init : /proc/pmu/info:
No such file or directory
Aug 3 16:19:50 eis cpufreqd: apm_init : /proc/apm: No
such file or directory
Aug 3 16:19:50 eis cpufreqd: acpi_battery_init : error,
acpi_battery module not compiled or inserted (/proc/acpi/battery/: No
such file or directory)?
Aug 3 16:19:51 eis cpufreqd: acpi_battery_init : exiting.
[...]
Aug 21 12:47:45 eis cpufreqd: cpufreqd_set_profile : Couldn't set
profile "lo_boost" set for cpu0
Aug 21 12:56:55 eis kernel: freq_table: exports duplicate symbol
cpufreq_frequency_get_table (owned by kernel)
Aug 21 12:56:55 eis cpufreqd: pmu_init : /proc/pmu/info:
No such file or directory
Aug 21 12:56:55 eis cpufreqd: apm_init : /proc/apm: No
such file or directory
Aug 21 12:56:55 eis cpufreqd: acpi_battery_init : error,
acpi_battery module not compiled or inserted (/proc/acpi/battery/: No
such file or directory)?
Aug 21 12:56:55 eis cpufreqd: acpi_battery_init : exiting.
Aug 21 12:56:55 eis cpufreqd: cpufreqd_set_profile : Couldn't set
profile "lo_boost" set for cpu0
Aug 21 13:03:31 eis cpufreqd: init_configuration :
/usr/etc/cpufreqd.conf: No such file or directory
Aug 21 13:03:31 eis cpufreqd: main : Unable to parse
config file: /usr/etc/cpufreqd.conf
--- [/messages.log] ---
was bisher bis zum erneuten Reboot funktioniert hat:
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1.80 GHz and 2.20 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.20 GHz (asserted by call to hardware).
eis # cpufreqd-set Low_Boost
No cpufreqd socket found
eis # cpufreqd-get
No cpufreqd socket found
eis # /etc/init.d/cpufreqd restart
dort werden dann auch das ein oder andere Modul nachgeladen.
eis # /etc/init.d/cpufreqd restart
Stopping Cpufreqd...
unloading governors ...
FATAL: Module powernow_k8 is in use.
unloading governor ...
FATAL: Module cpufreq_performance not found.
set Cpufreq to max ...
/etc/init.d/cpufreqd: line 106:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: Permission denied
eis # /etc/init.d/cpufreqd restart
Stopping Cpufreqd...
cpufreqdd is not running
Starting cpufreqd...
loading cpu driver ...
Danach sieht es dann so aus:
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1000 MHz and 1000 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
wie gesagt, das funktioniert dann (hoch und runter takten) bis zum
erneuten Reboot.
> Produktive Rückmeldungen bitte an spline.eisfair.dev.
Das Update verlief wie sonst auch ohne Probleme.
Super, vielen Dank & viele Grüße
Fabian
Thomas Bork
> irgendwo hakt es bei cpufreq:
> --- [messages.log] ---
> Aug 3 16:19:49 eis kernel: freq_table: exports duplicate symbol
Da fehlt mir mal wieder eine aussagekrï¿œftige Beschreibung:
Treten die Meldungen direkt nach Update des Kernels und der Module aber
vor einem Reboot auf oder wie ist das gemeint?
> was bisher bis zum erneuten Reboot funktioniert hat:
Siehe oben, wann genau wird weshalb rebootet?
Fï¿œr alle anderen:
cpufreqd hat niemand von Euch auf dem Rechner.
> eis # /etc/init.d/cpufreqd restart
> Stopping Cpufreqd...
> unloading governors ...
> FATAL: Module powernow_k8 is in use.
> unloading governor ...
> FATAL: Module cpufreq_performance not found.
Kein Wunder, ist fest im Kernel drin und im Moment default.
> Danach sieht es dann so aus:
> eis # cpufreq-info
> cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
> Report errors and bugs to li...@brodo.de, please.
> analyzing CPU 0:
> driver: powernow-k8
> CPUs which need to switch frequency at the same time: 0
> hardware limits: 1000 MHz - 2.20 GHz
> available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
> available cpufreq governors: ondemand, performance
Interessant: performance ist fest im Kernel, ondemand auch (Fallback).
> current policy: frequency should be within 1000 MHz and 1000 MHz.
> The governor "performance" may decide which speed to use
> within this range.
> current CPU frequency is 1000 MHz (asserted by call to hardware).
> wie gesagt, das funktioniert dann (hoch und runter takten) bis zum
> erneuten Reboot.
Keine Ahnung, was die Skripte des Paketes cpufreqd da machen - das hast
lediglich Du auf dem Rechner.
--
der tom
[eisfair-team]
Fabian Törner
Am 21.08.2011 17:21, schrieb Thomas Bork:
> Am 21.08.2011 13:25, schrieb Fabian Törner:
>
>> irgendwo hakt es bei cpufreq:
>> --- [messages.log] ---
>> Aug 3 16:19:49 eis kernel: freq_table: exports duplicate symbol
>
> Da fehlt mir mal wieder eine aussagekräftige Beschreibung:
> Treten die Meldungen direkt nach Update des Kernels und der Module aber
> vor einem Reboot auf oder wie ist das gemeint?
ok - sorry - hast ja Recht... Die Meldungen treten immer dann auf, wenn
ich den Rechner neu boote. Egal ob nach einem Kernelupdate oder nach
einem z.B. Base Update oder wenn ich den Rechner "mal einfach so" neustarte.
>> was bisher bis zum erneuten Reboot funktioniert hat:
>
> Siehe oben, wann genau wird weshalb rebootet?
das soll heißen, dass nach den u.g. "Eingriffen" das hoch- und
runtertakten funktioniert - bis halt zum nächsten Reboot der wie oben
schon geschrieben - sagen wir - manuell (Baseupdate oder Kernekupdate
oder einfach so ein Restart) ausgelöst wird.
>> eis # /etc/init.d/cpufreqd restart
>> Stopping Cpufreqd...
>> unloading governors ...
>> FATAL: Module powernow_k8 is in use.
>> unloading governor ...
>> FATAL: Module cpufreq_performance not found.
>
> Kein Wunder, ist fest im Kernel drin und im Moment default.
was meinst Du in diesem Zusammenhang mit default? aktiviert oder nicht?
>> Danach sieht es dann so aus:
>> eis # cpufreq-info
>> cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
>> Report errors and bugs to li...@brodo.de, please.
>> analyzing CPU 0:
>> driver: powernow-k8
>> CPUs which need to switch frequency at the same time: 0
>> hardware limits: 1000 MHz - 2.20 GHz
>> available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
>> available cpufreq governors: ondemand, performance
>
> Interessant: performance ist fest im Kernel, ondemand auch (Fallback).
verstehe ich auch nicht (s.o.) wenn es per default aktiviert sein sollte
warum ist es dann interessant das es fest im Kernel ist :)
Wenn es fest im Kernel drin ist, warum wird es dann nicht gefunden (s.o.)?
>> current policy: frequency should be within 1000 MHz and 1000 MHz.
>> The governor "performance" may decide which speed to use
>> within this range.
>> current CPU frequency is 1000 MHz (asserted by call to hardware).
>> wie gesagt, das funktioniert dann (hoch und runter takten) bis zum
>> erneuten Reboot.
>
> Keine Ahnung, was die Skripte des Paketes cpufreqd da machen - das hast
> lediglich Du auf dem Rechner.
Funktioniert denn das Hoch- und Runtertakten auch ohne cpufreqd?
Also "out of the box" mit dem Kernel der hier zur Verfügung gestellt
wird? Bitte nicht falsch verstehen - dann würde ich das cpufrqd ja nicht
benötigen - ansonsten halte ich es schon für sinnvoll, da ich dadurch ne
Menge Strom spare.
Wie machen das die Anderen hier - lassen die ihre CPU's immer mit vollem
Takt laufen?
Vielen Dank & viele Grüße
Fabian
Thomas Bork
> ok - sorry - hast ja Recht... Die Meldungen treten immer dann auf, wenn
> ich den Rechner neu boote. Egal ob nach einem Kernelupdate oder nach
> einem z.B. Base Update oder wenn ich den Rechner "mal einfach so"
> neustarte.
Wie gesagt:
Es entzieht sich meiner Kenntnis, was die cpufreqd-Skripte auf Deinem
Rechner machen.
> was meinst Du in diesem Zusammenhang mit default? aktiviert oder nicht?
performance ist fest in den Kernel einkompiliert und im Moment von mir
als default (Voreinstellung) festgelegt.
Das System macht aber einen Fallback auf ondemand, wenn performance
nicht funktioniert.
>>> available cpufreq governors: ondemand, performance
>> Interessant: performance ist fest im Kernel, ondemand auch (Fallback).
> verstehe ich auch nicht (s.o.) wenn es per default aktiviert sein sollte
> warum ist es dann interessant das es fest im Kernel ist :)
Interessant ist, dass das Skript das Vorhandensein von performance
registriert, obwohl es nicht modularisiert vorliegt.
> Wenn es fest im Kernel drin ist, warum wird es dann nicht gefunden (s.o.)?
Es wird doch gefunden, siehe Zitat von Dir:
available cpufreq governors: ondemand, performance
> Funktioniert denn das Hoch- und Runtertakten auch ohne cpufreqd?
> Also "out of the box" mit dem Kernel der hier zur Verfügung gestellt
> wird? Bitte nicht falsch verstehen - dann würde ich das cpufrqd ja nicht
> benötigen - ansonsten halte ich es schon für sinnvoll, da ich dadurch ne
> Menge Strom spare.
Wenn meine Recherchen stimmen - ja.
Allerdings müssen vorher irgendwie die passenden Module geladen werden.
--
der tom
[eisfair-team]
Stefan Kuhne
Hallo,
> Wie gesagt:
> Es entzieht sich meiner Kenntnis, was die cpufreqd-Skripte auf Deinem
> Rechner machen.
>
eben mal nachgesehen.
es will die Eingestellten governors laden und startet dann cpufreqd.
Wenn es keine Module für die governors mehr gibt, hilft
"CPUFREQD_GOVERNOR_N='0'". Daan läd er keine Module und startet cpufreqd
trotzdem.
Nur der Treiber will er immer laden. Ist das auch ein Problem?
Stefan Kuhne
PS.: Ich muss das Paket mal angehen.
Fabian Törner
Am 22.08.2011 22:10, schrieb Stefan Kuhne:
>
> es will die Eingestellten governors laden und startet dann cpufreqd.
> Wenn es keine Module für die governors mehr gibt, hilft
> "CPUFREQD_GOVERNOR_N='0'". Daan läd er keine Module und startet cpufreqd
> trotzdem.
habe eben manuell die /etc/config.d/cpufreqd editiert und
CPUFREQD_GOVERNOR_N=0 gesetzt. danach restart ausgeführt hier das Ergebnis:
--- [schnip] ---
eis # /etc/init.d/cpufreqd restart
Stopping Cpufreqd...
unloading governors ...
FATAL: Module powernow_k8 is in use.
unloading governor ...
set Cpufreq to max ...
/etc/init.d/cpufreqd: line 106:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: Permission denied
eis # /etc/init.d/cpufreqd status
Checking status of cpufreqd...
cpufreqd is not running
--- [schnap] ---
danach fällt er zurück auf max Taktung:
--- [schnip] ---
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1.80 GHz and 2.20 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.20 GHz (asserted by call to hardware).
eis #
--- [schnap] ---
und Auszug aus der messages.log
--- [schnip] ---
ug 23 17:52:57 eis kernel: freq_table: exports duplicate symbol
cpufreq_frequency_get_table (owned by kernel)
Aug 23 17:52:57 eis cpufreqd: pmu_init : /proc/pmu/info:
No such file or directory
Aug 23 17:52:58 eis cpufreqd: apm_init : /proc/apm: No
such file or directory
Aug 23 17:52:58 eis cpufreqd: acpi_battery_init : error,
acpi_battery module not compiled or inserted (/proc/acpi/battery/: No
such file or directory)?
Aug 23 17:52:58 eis cpufreqd: acpi_battery_init : exiting.
Aug 23 17:52:58 eis cpufreqd: cpufreqd_set_profile : Couldn't set
profile "lo_boost" set for cpu0
--- [schnap] ---
also wieder rückgängig gemacht die Änderung.
Danach den Dienst dreimal neugestartet mit folgenden Ausgaben:
--- [schnip] ---
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1.80 GHz and 2.20 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.20 GHz (asserted by call to hardware).
eis # /etc/init.d/cpufreqd restart
Stopping Cpufreqd...
unloading governors ...
FATAL: Module powernow_k8 is in use.
unloading governor ...
FATAL: Module cpufreq_performance not found.
set Cpufreq to max ...
/etc/init.d/cpufreqd: line 106:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: Permission denied
eis # /etc/init.d/cpufreqd restart
Stopping Cpufreqd...
cpufreqdd is not running
Starting cpufreqd...
loading cpu driver ...
loading governor ...
FATAL: Module cpufreq_performance not found.
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1000 MHz and 1000 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
eis # dmesg
freq_table: exports duplicate symbol cpufreq_frequency_get_table (owned
by kernel)
freq_table: exports duplicate symbol cpufreq_frequency_get_table (owned
by kernel)
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1.80 GHz and 2.20 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.20 GHz (asserted by call to hardware).
eis # cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to li...@brodo.de, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0
hardware limits: 1000 MHz - 2.20 GHz
available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 1000 MHz and 1000 MHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
--- [schnap] ---
das komische ist dass er auch ohne Last zwischendurch mal kurz (zwischen
den letzten beiden cpufreq-info) auf max (2200) war und danach gleich
wieder auf min (1000)
> Nur der Treiber will er immer laden. Ist das auch ein Problem?
keine Ahnung - war die Frage an mich gerichtet?
> Stefan Kuhne
>
> PS.: Ich muss das Paket mal angehen.
Ja, das wäre Spitze! :)
Fabian Törner
> Es entzieht sich meiner Kenntnis, was die cpufreqd-Skripte auf Deinem
> Rechner machen.
grundsätzlich -> interessiert es Dich denn?
> Es wird doch gefunden, siehe Zitat von Dir:
> available cpufreq governors: ondemand, performance
ahh ok es wird wohl unterschieden ob "fest im Kernel" und "als Modul"
So entnehme ich, dass cpufreqd das Modul nicht findet weil es fest im
Kernel ist - korrekt?
--- [Zitat] ---
FATAL: Module cpufreq_performance not found.
--- [/Zitat] ---
> Allerdings müssen vorher irgendwie die passenden Module geladen werden.
mhh ok - da kommt dann wohl cpufreqd ins Spiel ;)
Stefan Kuhne
Hallo,
>> PS.: Ich muss das Paket mal angehen.
>
> Ja, das wäre Spitze! :)
>
ich habe das Gefühl der Kernel ist zu neu für das binary oder so ...
Stefan Kuhne
Thomas Bork
> grundsätzlich -> interessiert es Dich denn?
Eigentlich nicht oder nur insofern, dass eventuell Änderungen am Kernel
notwendig sind, um Probleme damit zu beseitigen.
> ahh ok es wird wohl unterschieden ob "fest im Kernel" und "als Modul"
> So entnehme ich, dass cpufreqd das Modul nicht findet weil es fest im
> Kernel ist - korrekt?
Vermutlich.
>> Allerdings müssen vorher irgendwie die passenden Module geladen werden.
> mhh ok - da kommt dann wohl cpufreqd ins Spiel ;)
Man kann die prozessorspezifischen Module auch auf andere Art laden.
Wenn der Kernel das Scaling übernehmen soll, benötigt man keine
userspace-Programme wie cpufreqd.
Siehe
http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html
Und wenn das entsprechende Scaling-Modul bereits fest im Kernel steckt
(ondemand), muss man m.E. gar nichts weiter tun...
--
der tom
[eisfair-team]
Stefan Kuhne
Hallo,
> Und wenn das entsprechende Scaling-Modul bereits fest im Kernel steckt
> (ondemand), muss man m.E. gar nichts weiter tun...
>
das mache ich hier auch so.
Nur hatte Fabian damals bestimmte Anforderungen.
Deswegen läuft bei ihm der cpufreqd.
Stefan Kuhne
Thomas Bork
> Nur hatte Fabian damals bestimmte Anforderungen.
Welche denn?
--
der tom
[eisfair-team]
Stefan Kuhne
Hallo,
> Welche denn?
>
die Mails von 2006 geben dazu nix her.
Muss ich mal die Konfiguration fragen.
Ah, etwas eher hochschalten und auch wenn nur ein Core läuft.
So lese ich zumindest die Konfiguration.
Stefan Kuhne
Frans de Vre
t...@eisfair.org says...
>
> es ist eine Entwickler-Version 2.0.11 von eiskernel verfügbar. Intern
> wird hierfür der Kernel 2.6.32.44 verwendet.
Hallo Tom,
update auf 4 Maschinen ohne Probleme. Alles läuft bis auf WOL.
Dankeschön!
/Frans
Thomas Bork
> update auf 4 Maschinen ohne Probleme. Alles läuft bis auf WOL.
Äh - was war noch einmal das Problem mit WOL?
--
der tom
[eisfair-team]
Frans de Vre
t...@eisfair.org says...
>
>
> Äh - was war noch einmal das Problem mit WOL?
Hallo Tom,
es sind insgesamt 4 Rechner mit unterschiedliche NIC's.
1x Intel eepro100 (onboard)
2x Intel e1000 (PCI)
1x Realtek 8139too (PCI)
Die NIC werden beim runterfahren deaktiviert traffic LED erlischt.
Nun hat sich mit Kernel 2.6 die ACPI handhabung geändert also:
# dmesg | grep ACPI
ACPI: RSDP 000ff980 00014 (v00 AMI )
ACPI: RSDT 0fff0000 0002C (v01 DELL ZUUL 20001128 MSFT 00001011)
ACPI: FACP 0fff1000 00074 (v01 DELL ZUUL 20001128 MSFT 00001011)
ACPI: DSDT 0ffe0000 02DEB (v01 D815EA EA81510A 00000012 MSFT 0100000B)
ACPI: FACS 0fff8000 00040
ACPI: BOOT 0fff4000 0002B (v01 DELL ZUUL 20001128 MSFT 00001011)
ACPI: PM-Timer IO Port: 0x408
ACPI: Core revision 20090903
ACPI: setting ELCR to 0200 (from 8e00)
ACPI: bus type pci registered
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S5)
ACPI: Using PIC for interrupt routing
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12) *15
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12) *0,
disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12) *0,
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12) *0,
disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11 12)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12) *0,
disabled.
PCI: Using ACPI for IRQ routing
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNP
apm: overridden by ACPI.
ACPI: Sleep Button [SBTN]
ACPI: Power Button [PWRF]
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 9
soweit OK
# cat /proc/interrupts
0: 4376167 XT-PIC-XT timer
1: 2 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
6: 3 XT-PIC-XT floppy
9: 8037 XT-PIC-XT acpi, uhci_hcd:usb2, eth0
10: 0 XT-PIC-XT ehci_hcd:usb1, ohci_hcd:usb3
12: 4 XT-PIC-XT i8042
14: 25645 XT-PIC-XT ide0
Auch OK.
Aber
cat /proc/acpi/wakeup
SBTN S4 *enabled
PCI1 S1 disabled pci:0000:00:1e.0 < !!!!
PS2M S1 disabled pnp:00:05
PS2K S1 disabled pnp:00:06
UAR1 S1 disabled pnp:00:08
USB S1 disabled pci:0000:00:1f.2
USB2 S1 disabled
AC9 S1 disabled
SMB S1 disabled pci:0000:00:1f.3
Da stimmt was nicht.
Frage an alle: funktioniert bei euch WOL mit 2.6 kernel?
CU
/Frans
Thomas Bork
> es sind insgesamt 4 Rechner mit unterschiedliche NIC's.
> 1x Intel eepro100 (onboard)
> 2x Intel e1000 (PCI)
Für e1000 habe ich inzwischen denselben Workaround in die nächste
base-Version eingebaut, wie in Kernel 2.4.35-wt1.
Dieser Treiber darf laut Dokumentation in Kernel 2.6 wie der originale
Intel-Treiber, den ich in 2.4.35-wt1 eingebaut hatte, nicht entladen
werden, wenn WOL funktionieren soll.
Es würde mich aber wundern, wenn das plötzlich bei allen Treibern in
Kernel 2.6 so sein soll...
> SBTN S4 *enabled
> PCI1 S1 disabled pci:0000:00:1e.0< !!!!
> PS2M S1 disabled pnp:00:05
> PS2K S1 disabled pnp:00:06
> UAR1 S1 disabled pnp:00:08
> USB S1 disabled pci:0000:00:1f.2
> USB2 S1 disabled
> AC9 S1 disabled
> SMB S1 disabled pci:0000:00:1f.3
> Da stimmt was nicht.
http://www.vdr-wiki.de/wiki/index.php/WAKE_ON_LAN
echo -n PCI1 > /proc/acpi/wakeup
Einige Treiber benötigen laut Link anscheinend auch noch spezielle
Optionen (3c59x enable_wol=1).
Zum eepro100:
http://debianforum.de/forum/viewtopic.php?f=30&t=126324
Darf eventuell auch nicht entladen werden.
Zu e100:
http://debianforum.de/forum/viewtopic.php?f=33&t=117444
Anscheinend auch nicht.
--
der tom
[eisfair-team]
Holger Bruenjes
> http://www.vdr-wiki.de/wiki/index.php/WAKE_ON_LAN
>
> echo -n PCI1> /proc/acpi/wakeup
>
> Einige Treiber benötigen laut Link anscheinend auch noch spezielle
> Optionen (3c59x enable_wol=1).
Das sieht mir aber alles eher nach einem Eintrag in der base aus. ;-)
Statt wild alles nicht mehr zu entladen.
Vielleicht sollten wir da mal drueber nachdenken, in dem Fall und in
die base ein paar Parameter nachschieben die das behandeln.
Holger
Thomas Bork
>> Einige Treiber benötigen laut Link anscheinend auch noch spezielle
>> Optionen (3c59x enable_wol=1).
> Das sieht mir aber alles eher nach einem Eintrag in der base aus. ;-)
Das oben ja.
> Statt wild alles nicht mehr zu entladen.
Das nicht. Ich habe leider nicht gesehen, dass diese 3 Treiber für wol
eben nicht entladen werden dürfen.
Für 2.4.35-wt1 haben wir e1000/e1000e schon immer automagisch so
behandelt, jetzt habe ich das für die nächste base für e100/e1000/e1000e
und Kernel 2.6 hinzugefügt.
--
der tom
[eisfair-team]
Holger Bruenjes
>
> Das nicht. Ich habe leider nicht gesehen, dass diese 3 Treiber für wol
> eben nicht entladen werden dürfen.
> Für 2.4.35-wt1 haben wir e1000/e1000e schon immer automagisch so
> behandelt, jetzt habe ich das für die nächste base für e100/e1000/e1000e
> und Kernel 2.6 hinzugefügt.
Ja, dass waere aber besser in der base aufgehoben, dann wird das
zentral gehandhabt.
ETH_DRV_N='1'
ETH_DRV_1='e1000'
ETH_DRV_1_OPTION=''
ETH_DRV_1_WOL='yes' # yes or no
Das ist ein einfacher Weg
Holger
Thomas Bork
> Ja, dass waere aber besser in der base aufgehoben, dann wird das zentral
> gehandhabt.
Es wird auch jetzt schon zentral gehandhabt, in eth - und ohne dass der
User über eine zusätzliche Konfigurations-Option eingreifen muss, die
bei anderen Treibern als den 3 genannten sowieso nichts macht...
--
der tom
[eisfair-team]
Stefan Welte
> Am 15.08.2011 22:25, schrieb Stefan Welte:
>> "
>> Loading SCSI modules
>> insmod: can't read 'cdrom': Is a directory
>> insmod: can't read 'sr_mod': No such file or directory
>> insmod: can't read 'isofs': No such file or directory
>> insmod: can't read 'st': No such file or directory
>> loading cdrom drivers ...
>> "
>> -> ungelöst
>
> Wann tritt das auf? Hast Du in der base Modulnamen angegeben, die so nicht mehr existieren?
> Eventuell muss man da auch noch mal nachsehen, ob statt insmod nicht besser modprobe verwendet
> werden sollte.
Recherche ergab:
Das Paket scsi-aic7xxx drivers 1.0.0 stable 2002-06-25 "Various aic7xxx based Adaptec SCSI
controllers _not_ AHA2920" besitzt folgende (ggf. noch mehr) Dateien:
$ cat /var/install/packages/scsi-aic7xxx
<package>
<name>scsi-aic7xxx</name>
<short>Various aic7xxx based Adaptec SCSI controllers _not_ AHA2920</short>
<version>1.0.0</version>
<date>2002/06/25</date>
<author>Frank Meyer, fr...@eisfair.org</author>
<status>stable</status>
<section>drivers</section>
<source>www.eisfair.org</source>
<require>base-1.0.0</require>
<description>
SCSI package for Kernel 2.2.19
Various aic7xxx based Adaptec SCSI controllers _not_ AHA2920
</description>
</package>
$ cat /etc/init.d/scsi
#! /bin/sh
DRV=aic7xxx
case $1
in
start)
echo "Loading SCSI modules"
f=`echo /proc/scsi/*` # SCSI already in kernel?
if [ "$f" = "/proc/scsi/*" ] # no...
then
/sbin/insmod scsi_mod # load SCSI-lowlevel driver
/sbin/insmod $DRV # load adapter specific driver
/sbin/insmod sd_mod # load disk driver
fi
/sbin/insmod cdrom # load generic cdrom driver
/sbin/insmod sr_mod # load scsi cdrom driver
/sbin/insmod isofs # load isofs
/sbin/insmod st # load tape driver
;;
stop)
echo "Unloading SCSI modules"
/sbin/rmmod st 2>/dev/null # unload tape driver
/sbin/rmmod isofs 2>/dev/null # unload isofs
/sbin/rmmod sr_mod 2>/dev/null # unload scsi cdrom driver
/sbin/rmmod cdrom 2>/dev/null # unload generic cdrom driver
/sbin/rmmod sd_mod 2>/dev/null # unload disk driver
/sbin/rmmod $DRV 2>/dev/null # unload adapter specific driver
/sbin/rmmod scsi_mod 2>/dev/null # unload SCSI-lowlevel driver
;;
esac
exit 0
$ ls -la /etc/rc2.d/
lrwxrwxrwx 1 root root 14 23. Jun 2006 S01scsi -> ../init.d/scsi
Daher die insmod Fehler!?
Eine Datei /var/install/deinstall/scsi-* ist weit und breit nicht zu finden.
Ich vermute, daß das Paket von der damaligen Installation per Diskette oder so sein könnte. Eine
Linkänderung
$ mv /etc/rc2.d/S01scsi /etc/rc2.d/K99scsi
zeigte, daß der eis auch so problemlos startete und die Fehlermeldungen verschwanden.
Kann ich die Dateien
/etc/rc2.d/K99scsi
/etc/init.d/scsi
/var/install/packages/scsi-aic7xxx
problemlos löschen? Falls ja, waren das alle, die ich löschen muss/soll?
Danke und Gruß,
Stefan
Holger Bruenjes
Am 2013-01-20 02:49, schrieb Stefan Welte:
> Recherche ergab:
> Das Paket scsi-aic7xxx drivers 1.0.0 stable 2002-06-25 "Various aic7xxx based Adaptec SCSI
> controllers _not_ AHA2920" besitzt folgende (ggf. noch mehr) Dateien:
>
> $ cat /var/install/packages/scsi-aic7xxx
> <package>
> <name>scsi-aic7xxx</name>
> <short>Various aic7xxx based Adaptec SCSI controllers _not_ AHA2920</short>
> <version>1.0.0</version>
> <date>2002/06/25</date>
Standard Kernel von eisfair-1. diese Teile duerften auch schon beim
2.4.35 er Kernel Probleme bereitet haben
>
> SCSI package for Kernel 2.2.19
es wird ein Verzeichnis geben
/lib/modules/2.2.19
das ist total obsolet
> problemlos löschen? Falls ja, waren das alle, die ich löschen muss/soll?
Holger