[gelöst]Kern braucht 10 sek fürs Netz

[alboran]

Hallo, vielleicht kann mir ja jemand einen kleinen Tipp geben.
Nachdem der Kernel das b43-fwcutter geladen hat braucht er ungefähr 10-20 sek um die Schnittstelle zu stabilisieren
Hab mal die letzten Logzeilen angehängt.
LG Muff
35832

[rendegast]

Ist nicht tg3 das Problem? 15 Sekunden
Es kommt keine Meldung darüber, aber dem tg3 ist firmware bereitgestellt?

# modinfo tg3
filename: /lib/modules/2.6.39-2-686-pae/kernel/drivers/net/tg3.ko
firmware: tigon/tg3_tso5.bin
firmware: tigon/tg3_tso.bin
firmware: tigon/tg3.bin
version: 3.117
license: GPL

-> firmware-linux-nonfree,
auch problemlos aus sid (zur Not entpackt und kopiert), falls das Linderung verschafft.




wlan b43 braucht 8 Sekunden um immer noch nicht ready zu sein

Aug 9 17:19:38 muff kernel: [ 19.228105] b43 ssb0:0: firmware: requesting b43/ucode5.fw
Aug 9 17:19:38 muff kernel: [ 19.237887] b43 ssb0:0: firmware: requesting b43/pcm5.fw
Aug 9 17:19:38 muff kernel: [ 19.248979] b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
Aug 9 17:19:38 muff kernel: [ 19.262967] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
Aug 9 17:19:38 muff kernel: [ 19.380065] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)

http://packages.debian.org/firmware-b43
Welchen der drei benutzt Du denn?

• firmware-b43-installer_4.150.10.5-4_all.deb (wget wl-4.150 2008-01)
  firmware-b43-lpphy-installer_4.174.64.19-4_all.deb (wget wl-4.178 2009-02)(der "neueste")
  firmware-b43legacy-installer_4.178.10.4-4_all.deb (wget wl_apsta-3.130 2006-01)
  (lustige Versionierung)

Nach dem firmware-Datum müßte es zumindest b43 oder b43-lpphy sein.

Bei allen dreien werden obige Dateien erstellt. Die pcm5.fw sind sogar identisch.
Da ist also eine Wechselmöglichkeit.


Auch hier könntest Du die Version(en) aus sid versuchen

• b43-fwcutter_1%3a014-9_i386.deb
  firmware-b43-installer_1%3a014-9_all.deb (wget wl-5.10 2010-07)
  (firmware-b43-lpphy-installer_1%3a014-9_all.deb (bearbeitet selbe Datei wie stable))
  (firmware-b43legacy-installer_1%3a014-9_all.deb (bearbeitet selbe Datei wie stable))

Muß ja nicht installiert werden, einfach nur die Pakete herunterladen,
den cutter und die postinst nach /tmp kopieren, das postinst-Skript anpassen:
b43-fwcutter -> /tmp/b43-fwcutter
FIRMWARE_INSTALL_DIR="/lib/firmware" -> FIRMWARE_INSTALL_DIR="/tmp/b43_sid"
Ein Test muß noch deaktiviert werden:

Code: Alles auswählen

chip=`lspci -n | grep -o "14e4:4320 (rev 03)"` || true
#if [ "$chip" ] ; then
   echo "Your card is BCM4306/3 [14e4:4320] (rev 03), firwmare 5.10.56.27.3 will be used"
   latest_firmware
   exit 0
#fi 

und voila!
( Anmerkung: Bei auskommentiertem Lösch-Befehl
#rm -rf broadcom-wl-5.10.56.27.3_mipsel.tar.bz2 broadcom-wl-5.10.56.27.3
bleibt das /root/broadcom...tar.bz2 zurück.
Da sollte besser /tmp/ verwendet werden.)

Letztendlich hast Du 4 verschiedene firmware, die für Versuche einfach nach /lib/firmware kopiert werden können.





Und wie steht es mit der Konfiguration?
Über network-manager (auch eines seiner frontends) oder die /etc/network/interfaces?

[alboran]

Hallo rendegast, erstmal vielen Dank für deine Bemühungen. Das mit tgm3 hab ich ja problemlos hinbekommen....
aber jetzt gibts was zum Lachen . Also ich hatte auf einer anderen Festplatte (Notebook wohlgemerkt) auch squeeze installiert mit Lilo.
Jetzt startet diese meine andere Platte ( die vorhin erwähnte liegt neben mir) mit Lilo und zwar mit dem gleichen Benutzernamen wie ich ihn auf der neben mir liegenden Platte eingegeben habe. Auf diesem System ist kein Lilo drauf! 110%. Keine conf keine bootdateien..nichts. Kopfkratz
Das ist seitdem ich die firmware-linux-nonfree draufgespielt habe. Hab sie zwischenzeitlich wieder runter geschmissen--es bleibt bei Lilo.
Ich hab nichts dagegen aber mir verwehrt sich da im Moment die Logik
Hat sich da LiloLALA auf meinen Ram geschrieben
Deine Meinung würd mich interessieren.
LG Muff

Was vielleicht interessant ist, ist das Lilo auf der tty2 läuft (durch zufall festgestellt) und auf der tty1 siehts so aus als wenn da der normale Bootvorgang stattgefunden hätte.

Stückchen Zeit später..
Hab Grub neu geschrieben und die Pakete aus Sid getesten. Dir Treiber sind letztendlich die gleichen bis auf den Cutter. Jetzt geht alles sage und schreibe 1 Sek schneller
Also irgendwie muss der Knoten wohl woanders liegen. (Mal ne Nacht drüber schlafen)
mfg Muff

Anhang: /etc/network/interfaces

[rendegast]

Den Post schau Dir nochmal an und editiere ihn,
in der Form ist das nicht schlüssig.

firmware linux-nonfree bietet nur firmware an unter /lib/firmware,
diese erweitert oder ermöglicht die Funktionen einiger Treiber.
Bei der Installation wird 'update-initramfs -u' aufgerufen,
für den gerade laufenden Kernel wird dadurch die initrd neu erstellt.

lilo oder andere Bootloader werden automatisch nur bei Aktionen mit Kernelpaketen
über /etc/kernel/ getriggert.

Das mit tgm3 ...

"tg3", wenn der Treiber verwendet wird, ist die firmware angeraten.

Das ist seitdem ich die firmware-linux-nonfree draufgespielt habe.
Hab sie zwischenzeitlich wieder runter geschmissen--es bleibt bei Lilo.

Ein woanders installierter lilo kann einen nichtreferenzierten Kernel nicht starten,
da er den kernel nicht logisch anhand des Dateisystems sucht sondern physisch anhand des Ortes auf der Platte.

Falls das lilo seinen "richtigen" Kernel benutzt, dieser dann aber das falsche System startet,
kann das an der Anweisung "root=" der Kernel-Commandline liegen und an den mount-Anweisungen der /etc/fstab.
Falls 'root=/dev/...', die devices können sich bei für ein startendes System bei unterschiedlicher Anordnung leicht ändern.
Falls 'root=LABEL=...'oder 'root=UUID=...',
Für alle existierenden Partitionen aller Platten sind die LABEL/UUID unterschiedlich?
(ZBsp. beim einfachen Klonen einer Partition mittels 'dd' würden natürlich auch LABEL/UUID übernommen)
Kontrolle mit 'blkid | sort'
Anzuraten ist durchgängige Verwendung von UUID/LABEL beim Bootloader und /etc/fstab.
(was auch mittlerweile Standard ist)


Hast Du vielleicht lilo aufgerufen, während beide Systeme angesteckt waren?
Sodaß sich der lilo-Startsektor auch auf die "Nicht-lilo"-Platte schreiben konnte.

Jetzt startet diese meine andere Platte ( die vorhin erwähnte liegt neben mir) mit Lilo und zwar mit dem gleichen Benutzernamen wie ich ihn auf der neben mir liegenden Platte eingegeben habe.

Was für ein Benutzernamen?
Soll das heißen, daß du das jeweilige System am Namen eines vorhandenen Benutzers
identifizierst?
Benutze hier im Thread dann bitte auch eindeutige Bezeichner,
bei "das eine" und "das andere" kommt leicht Verwirrung auf.

Hat sich da LiloLALA auf meinen Ram geschrieben ...
Was vielleicht interessant ist, ist das Lilo auf der tty2 läuft (durch zufall festgestellt) und auf der tty1 siehts so aus als wenn da der normale Bootvorgang stattgefunden hätte.

Ich weiß nicht was Du damit meinen könntest.

Dir Treiber sind letztendlich die gleichen bis auf den Cutter

"Firmware",
Paket firmware-b43-cutter aus sid schneidet eine vierte Version aus broadcom-wl-5.10.56.27.3,
wie dargelegt.

Anhang: /etc/network/interfaces

?

[alboran]

Hallo rendegast,
vielleicht habe ich mich ein wenig missverständlich ausgedrückt, sorry.
Platte 1=muff, Platte 2=fluxmuff
Ich kann in meinem Laptop entweder 1 oder 2 drin haben, beide zusammen geht nicht. P1 hat Grub, P2 hat Lilo.
Ich hatte gestern beide nacheinander drin. Nachdem ich dann wieder auf meinem normalen System P1 gearbeitet habe und die firmware-linux installiert habe bootet P1 mit Lilo. Frag mich bitte nicht warum, für mich ist es genauso wenig nachvollziehbar wie für dich, denke ich.
Wie dem auch sei, mit der Live CD konnte ich Grub allerdings nicht zurückschreiben, zumindest nicht auf die Boot Partition.
Hab dann Grub auf /dev/sda geschrieben und Lilo mit sudo dd if=/dev/zero of=/dev/sda5 bs=1 count=440 conv=notrunc gelöscht.
Hab dir mal ein Bootinfoscript rangehängt
35836

"tg3", wenn der Treiber verwendet wird, ist die firmware angeraten.

hab ich ja installiert mit den firmware-linux-nonfree

Hast Du vielleicht lilo aufgerufen, während beide Systeme angesteckt waren?
Sodaß sich der lilo-Startsektor auch auf die "Nicht-lilo"-Platte schreiben konnte.

Nein, deswegen ja eher die scherzhafte Äußerung ob sich Lilo vielleicht in den Ram geschrieben hätte

?

bezog sich auf deine Frage nach der Konfiguration

mfg muff

[rendegast]

Das lilo auf muff/sda5 hattest Du dann wohl irgendwann mal in Verwendung,
ein chainload-Boot der Partition.
Ein vergessener Versuch mit lilo, oder noch ein Osterei aus lenny-Zeiten?

Der Startsektor ist vielleicht durch das Paket os-prober erkannt worden
und bekam einen Eintrag in der menu.lst.
Hat jedenfalls nichts mit dem Paket firmware-linux-nonfree zu tun.

Ich kann in meinem Laptop entweder 1 oder 2 drin haben, beide zusammen geht nicht.

Aus der fstab:

#/dev/sdb1 /media/disk ext3 rw,auto,user,umask=0000 0 0
#UUID=0ad699b3-38ca-49db-9f90-e874c8448fd8 /media/disk ext3 rw,auto,defaults 0 2

Eine andere Platte hatte mal Verbindung, sei es ein USB-Stick oder USB-Platte.
Genauso könnte die zweite Platte in einem USB-Gehäuse oder -Adapter angesteckt worden sein,
zBsp. für kurzfristige Kopierorgien.

Und wie steht es mit der Konfiguration?
Über network-manager (auch eines seiner frontends) oder die /etc/network/interfaces?

Anhang: /etc/network/interfaces

?

bezog sich auf deine Frage nach der Konfiguration

Da ist aber nichts angehängt.
nm hält sich dann auch aus der Konfiguration heraus,
oder ist komplett deaktiviert? (frontend + dämon)

[alboran]

Das der von Lenny noch da ist könnte natürlich sein, andernfalls wundert es mich das er mit meinem Usernamen von der 2ten Platte gestartet ist die ich erst vor ca 2 Wochen bestückt habe.
Die sdb1 ist nur eine passive Platte die ich für Backups und als Auslagerungsmedium nehme.
Aber wie gesagt, es war für mich halt eher lustig und ich hab auch kein Problem damit gehabt

Da ist aber nichts angehängt.
nm hält sich dann auch aus der Konfiguration heraus,
oder ist komplett deaktiviert? (frontend + dämon)

Wenn dann hab ich Wicd laufen(ist momentan aber abgeschaltet, front+daem), aber im Moment läuft das Interface
35837

mfg muff

[alboran]

Hall rendegast, ich glaube das Problem ist mit der neuen Firmware gelöst worden

Code: Alles auswählen

Aug 10 20:01:16 muff kernel: [   13.742824] tg3 0000:02:00.0: irq 29 for MSI/MSI-X
Aug 10 20:01:16 muff kernel: [   13.778530] ADDRCONF(NETDEV_UP): eth0: link is not ready
Aug 10 20:01:16 muff kernel: [   15.360608] tg3: eth0: Link is up at 100 Mbps, full duplex.
Aug 10 20:01:16 muff kernel: [   15.360611] tg3: eth0: Flow control is on for TX and on for RX.
Aug 10 20:01:16 muff kernel: [   15.360817] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 10 20:01:16 muff kernel: [   16.904078] b43 ssb0:0: firmware: requesting b43/ucode5.fw
Aug 10 20:01:16 muff kernel: [   16.955199] b43 ssb0:0: firmware: requesting b43/pcm5.fw
Aug 10 20:01:16 muff kernel: [   16.962274] b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
Aug 10 20:01:16 muff kernel: [   16.972528] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
Aug 10 20:01:16 muff kernel: [   17.092064] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
Aug 10 20:01:16 muff kernel: [   17.165153] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Aug 10 20:01:16 muff kernel: [   26.356044] eth0: no IPv6 routers present
Aug 10 20:01:16 muff kernel: [   43.688479] fuse init (API version 7.13)
Aug 10 20:01:16 muff kernel: [   44.649280] apm: BIOS not found.

er braucht jedenfalls keine 20Sek mehr. Danke
Das mit dem Lilo war ja dann doch wohl eher so ein "schwankerl", oder wie man das nennt.
Ich dank dir aber für deine Geduld
mfg muff