eth0 des öfteren down - Wheezy

[Faber38]

hallo,
ich hab ab und an folgendes Problem...

Code: Alles auswählen

[    0.000000] ACPI: TAMG 00000000cfdda8c0 00122 (v01 GBT    GBT   B0 5455312E BG?? 00000101)
[ 7565.808256]  <IRQ>  [<ffffffff810468fd>] ? warn_slowpath_common+0x78/0x8c
[ 7565.808270]  [<ffffffff810469a9>] ? warn_slowpath_fmt+0x45/0x4a
[ 7565.808277]  [<ffffffff812a2ee1>] ? netif_tx_lock+0x40/0x72
[ 7565.808288]  [<ffffffff812a3042>] ? dev_watchdog+0xe9/0x148
[ 7565.808294]  [<ffffffff81051f70>] ? run_timer_softirq+0x19a/0x261
[ 7565.808299]  [<ffffffff812a2f59>] ? netif_tx_unlock+0x46/0x46
[ 7565.808307]  [<ffffffff81065ad3>] ? timekeeping_get_ns+0xd/0x2a
[ 7565.808313]  [<ffffffff8104bee4>] ? __do_softirq+0xb9/0x177
[ 7565.808320]  [<ffffffff8135162c>] ? call_softirq+0x1c/0x30
[ 7565.808327]  [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
[ 7565.808333]  [<ffffffff8104c14c>] ? irq_exit+0x3c/0x9a
[ 7565.808340]  [<ffffffff81024058>] ? smp_apic_timer_interrupt+0x74/0x82
[ 7565.808346]  [<ffffffff8134fe9e>] ? apic_timer_interrupt+0x6e/0x80
[ 7565.808349]  <EOI>  [<ffffffffa023c398>] ? arch_local_irq_enable+0x4/0x8 [processor]
[ 7565.808376]  [<ffffffffa023d020>] ? acpi_idle_enter_simple+0xc6/0x102 [processor]
[ 7565.808389]  [<ffffffff8126c573>] ? cpuidle_idle_call+0xec/0x179
[ 7565.808396]  [<ffffffff8100d248>] ? cpu_idle+0xa5/0xf2
[ 7565.808402]  [<ffffffff8133c8f0>] ? start_secondary+0x1d5/0x1db

dann ist meine eth0 down... wenn ich dann gerade Fernsehe über local-stream bleibt das Bild stehen...gehe ich auf einen webbrowser.. startet das Netzwerk wieder


Die Meldungen sagen doch eigentlich das etwas mit dem ACPI oder IRQ nicht stimmt... ich kann damit nicht wirklich etwas anfangen....
hätte da einer eine Idee ?? könnte es mit dem IOMMU im Bios zutun haben ? das war das einzige soweit ich mich erinnern kann, was ich geändert hab (IOMMU enabled - auf empfehlung von dmesg !) oder haben noch mehr diese Probleme (update bug ? )

[Cae]

Bei dem Stacktrace sollten auch so lustige "cut here"-Zeilen dabei sein. Die haben ihre Berechtigung, denn aus dem jetzt geposteten Teil erfährt man nicht wirklich, wo etwas passiert, sondern nur, was passiert.

Gruß Cae

[Faber38]

sorry..

Holger-Wheezy kernel: [ 7565.808101] ------------[ cut here ]------------
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808114] WARNING: at /build/buildd-linux_3.2.20-1-amd64-lTzScn/linux-3.2.20/net/sched/sch_generic.c:255 dev_watchdog+0xe9/0x148()
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808120] Hardware name: GA-970A-DS3
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808124] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808127] Modules linked in: snd_seq_dummy(O) des_generic ecb md4 hmac nls_utf8 cifs ip6table_filter ip6_tables ebtable_nat ebtables powernow_k8 mperf cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_stats xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE xt_DSCP ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables parport_pc ppdev lp parport bnep rfcomm bluetooth rfkill binfmt_misc nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc kvm_amd kvm loop snd_hda_codec_hdmi(O) snd_hda_codec_realtek(O) snd_hda_intel(O) snd_hda_codec(O) snd_hwdep(O) nvidia(P) snd_pcm(O) snd_page_alloc(O) pl2303 usbserial snd_seq(O) snd_seq_device(O) snd_timer(O) snd(O) soundcore k10temp processor sp5100_tco thermal_sys wmi i2c_piix4 edac_mce_amd psmouse serio_raw edac_core i2c_core fam15h_power evdev pcspkr button ext4 crc16 jbd2 mbcache dm_mod usbhid hid sr_mod sd_mod cdrom crc_t1
Jun 29 18:41:33 Holger-Wheezy kernel: 0dif ahci ata_generic ohci_hcd libahci ehci_hcd xhci_hcd pata_atiixp r8169 mii usbcore libata scsi_mod usb_common [last unloaded: scsi_wait_scan]
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808249] Pid: 0, comm: swapper/2 Tainted: P O 3.2.0-2-amd64 #1
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808253] Call Trace:
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808256] <IRQ> [<ffffffff810468fd>] ? warn_slowpath_common+0x78/0x8c
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808270] [<ffffffff810469a9>] ? warn_slowpath_fmt+0x45/0x4a
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808277] [<ffffffff812a2ee1>] ? netif_tx_lock+0x40/0x72
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808288] [<ffffffff812a3042>] ? dev_watchdog+0xe9/0x148
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808294] [<ffffffff81051f70>] ? run_timer_softirq+0x19a/0x261
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808299] [<ffffffff812a2f59>] ? netif_tx_unlock+0x46/0x46
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808307] [<ffffffff81065ad3>] ? timekeeping_get_ns+0xd/0x2a
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808313] [<ffffffff8104bee4>] ? __do_softirq+0xb9/0x177
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808320] [<ffffffff8135162c>] ? call_softirq+0x1c/0x30
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808327] [<ffffffff8100f8e5>] ? do_softirq+0x3c/0x7b
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808333] [<ffffffff8104c14c>] ? irq_exit+0x3c/0x9a
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808340] [<ffffffff81024058>] ? smp_apic_timer_interrupt+0x74/0x82
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808346] [<ffffffff8134fe9e>] ? apic_timer_interrupt+0x6e/0x80
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808349] <EOI> [<ffffffffa023c398>] ? arch_local_irq_enable+0x4/0x8 [processor]
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808376] [<ffffffffa023d020>] ? acpi_idle_enter_simple+0xc6/0x102 [processor]
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808389] [<ffffffff8126c573>] ? cpuidle_idle_call+0xec/0x179
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808396] [<ffffffff8100d248>] ? cpu_idle+0xa5/0xf2
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808402] [<ffffffff8133c8f0>] ? start_secondary+0x1d5/0x1db
Jun 29 18:41:33 Holger-Wheezy kernel: [ 7565.808406] ---[ end trace 4efc56b145ee408b ]---

ich habe im Bios den IOMMU wieder disabled... anscheinend liegt es daran... jetzt läuft wieder alles...mal sehen ob es nochmal vorkommt.

[rendegast]

GA-970A-DS3 ist dann erstmal wohl eher nur ein windows-Board?
Oder zeigt sich da ein bios-Bug? -> Aktuelles Bios F2 1,11 MB 2012.03.30

IOMMU ist doch eine nette Sache, wenn Deine VM das nutzen können,
es mal mit einer separaten Netzwerkkarte (anderer Chip?) versuchen?

Probiere mal den kernel 3.4 aus experimental.
http://packages.debian.org/experimental ... runk-amd64

[habakug]

Hallo!

@rendegast
Was ist ein "windows-Board"?

Zu dem Fehler gibt es einen Bug-Report [1] und einen Patch [2]. Aus irgendwelchen Gründen ist der Patch für dieses Gerät (RTL_GIGA_MAC_VER_34) aber bis jetzt nicht in den Kernelsourcen angekommen, hier mainline-3.5-rc4:

Code: Alles auswählen

[...]
	case RTL_GIGA_MAC_VER_22:
	case RTL_GIGA_MAC_VER_23:
	case RTL_GIGA_MAC_VER_24:
		RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
		break;
	default:
		RTL_W32(RxConfig, RX128_INT_EN | RX_DMA_BURST);
		break;
	}[...]

Will man das so betreiben müßte man selbst Hand anlegen.
Um mal den Enthusiasmus in Bezug auf IOMMU etwas zu dämpfen: Das braucht man nur, wenn man PCI-Geräte an die virtuelle Maschine durchreichen möchte. Und es geht nur mit Karten in den kleinen PCIe-Slots. Grafikkarten und Karten in PCI-Slots sind ausgeschlossen, da sie eine "exclusive" Nutzung nicht zulassen. Fieserweise sind sie in der virtuellen Maschine z.B. mit lspci zu sehen, jedoch ohne weitere Funktion.

Gruß, habakug

[1] https://bugzilla.kernel.org/show_bug.cgi?id=42899#c32
[2] https://bugzilla.kernel.org/attachment.cgi?id=73108

[rendegast]

Was ist ein "windows-(Gerät)"?

Das Übliche, unter linux Fehlermeldungen und Gewurschtel, unter windows "Geht!".

Und "Netzwerkkarte (anderer Chip)" würde hier dann ja helfen

[Faber38]

Danke für eure Antworten...
nun bin ich etwas schlauer.... IOMMU muss ich nicht unbedingt benutzen.

den Kernel werde ich aber mal ausprobieren...

[nudgegoonies]

Um mal den Enthusiasmus in Bezug auf IOMMU etwas zu dämpfen: Das braucht man nur, wenn man PCI-Geräte an die virtuelle Maschine durchreichen möchte. Und es geht nur mit Karten in den kleinen PCIe-Slots. Grafikkarten und Karten in PCI-Slots sind ausgeschlossen, da sie eine "exclusive" Nutzung nicht zulassen. Fieserweise sind sie in der virtuellen Maschine z.B. mit lspci zu sehen, jedoch ohne weitere Funktion.

Ich habe gerade sehr viel mit Virtualisierung zu tun aber solche Dinge wie das Durchreichen habe ich noch nicht ausprobiert. Würde es gerne, aber werde wohl kaum dazu kommen. Allerdings hat die IOMMU, so wie ich es verstehe, auch ohne Virtualisierung ihren Sinn. Zumindest wenn man mehr als 4 GB hat. Der PCI Bus kann aufgrund der 32 Bit Beschränkung DMA nur innerhalb der ersten 4 GB machen. Für höhere Speicherbereiche macht der Kernel ohne IOMMU so eine Art Double-Buffering wo die Daten hin- und herkopiert werden. Was ich nicht ganz verstanden habe ist, ob diese Beschränkung nur im 32/36 Bit PAE Modus oder auch im echten 64 Bit Long Modus besteht. Letzteres würde bedeuten, dass PCI doch mit 64 Bit umgehen könnte. Ich dachte die 64 Bit bei PCI-X beziehen sich auf 64 Bit Datenbus statt 32 Bit und nicht 64 Bit Adressraum. Ach ja, meine Quelle war hier: http://en.wikipedia.org/wiki/IOMMUSonst findet man wenig zur IOMMU.