Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Henrikx
Gestern 19:39:58

Wenn ihre Krankheit sie eines gelehrt habe, dann das: Es gebe so viele wichtigere Dinge als den "verdammten Stress".

schard
Gestern 19:16:34

Das ist wirklich traurig. Ich bin mit der Musik von Roxette aufgewachsen. hmm

Henrikx
Gestern 19:10:01

Tod von Marie Fredriksson
Eine Stimme, der man glaubte

https://www.tagesschau.de/ausland/roxet … d-101.html    sad

segfault
08.12.2019 07:35:35

Ich muss jetzt auch mal motzen.

Ich wundere mich, warum plötzlich der NFS-Mount nicht mehr geht. Klappt doch von überall, nur nicht mehr von einem Host. Gekuckt und gemacht, Debugging, tcpdump und was weiß ich…

Dann die Erkenntnis: Kernel 5.4.2 hat die Jumbo Frames kaputt gemacht. Jedenfalls bei meiner Netzwerkhardware:

$ lspci -vvv -nn -k -s 02:00.0
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
        Subsystem: ASRock Incorporation Motherboard (one of many) [1849:8168]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 60
        Region 0: I/O ports at f000 [size=256]
        Region 2: Memory at fce04000 (64-bit, non-prefetchable) [size=4K]
        Region 4: Memory at fce00000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169

Der Treiber lädt ganz normal:

$ journalctl -b -g 8169 --no-hostname --no-pager
-- Logs begin at Thu 2019-09-12 18:56:56 CEST, end at Sun 2019-12-08 06:12:07 CET. --
Dec 07 16:52:27 kernel: libphy: r8169: probed
Dec 07 16:52:27 kernel: r8169 0000:02:00.0 eth0: RTL8168h/8111h, 70:85:c2:11:11:11, XID 541, IRQ 61
Dec 07 16:52:27 kernel: r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Dec 07 16:52:27 kernel: r8169 0000:02:00.0 enp2s0: renamed from eth0
Dec 07 16:52:27 kernel: Generic FE-GE Realtek PHY r8169-200:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
Dec 07 16:52:27 kernel: r8169 0000:02:00.0 enp2s0: Link is Down
Dec 07 16:52:31 kernel: r8169 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control rx/tx

Sobald aber Frames >1500 zustande kommen bleibt die Verbindung hängen. Reproduzierbar. Nutze ich nur die Standard MTU "sudo ip link set mtu 1500 dev enp2s0", klappt alles wieder ausgezeichnet.

Den einzigen Commit der da was geändert haben kann ist der:

r8169: fix jumbo configuration for RTL8168evl

Leute, das ist doch Kacke!

Update: Der o.g. Commit ist unschuldig. Die Jumboframes funktionieren mit Kernel 5.3.13. Ab 5.4.x sind sie defekt.

sanni
13.10.2019 20:42:34

Nicht ganz richtig:  Foren-Troll.
Außerdem, versuch es doch mal mit Selbstreflexion!?

Dirk
07.10.2019 23:03:41

Och nee … Ich hab das seit Jahren nicht mehr installiert, und war ganz happy, dass das endlich nicht mehr standardmäßig das System vollmüllt.

Ich ging inzwischen sogar davon aus, dass das Paket deprecated ist.

Edit: https://bugs.archlinux.org/task/64071

schard
07.10.2019 09:54:45

Toll, in Version 2 des neuen base Pakets schreiben die Core Devs einem nun vor, systemd-sysvcompat zu installieren, auch wenn man es überhaupt nicht benötigt.
Grrr....

chepaz
21.09.2019 11:58:54
apocalyptycus schrieb:

Blöd ist, daß ich vergessen habe, wie man Arch installiert.

Dann nimm rsync und ein grub-install, dann musst du nicht installieren smile

apocalyptycus
21.09.2019 09:32:40

Ein neuer Rechner wird gebaut.
Ganz dicke CPU, jede Menge RAM usw.
Blöd ist, daß ich vergessen habe, wie man Arch installiert.
Läuft ja seit ca. 5 J.
Es ist zum Kotzen.
Scheiße, wenn man alt ist.

segfault
06.08.2019 16:28:49
TBone schrieb:

Btw es geht nicht um die Race-condition beim Booten, das System war bereits gebootet und lief etwas mit wpa_supplicant. Dann stop des einen, start des anderen: Interface umbenannt.

Ja, aber das ist dokumentiert und man kann das abstellen.

Werner
29.07.2019 20:02:13

Aha, so machen die das.
Der Zweig GitLab Self-Managed wäre demnach nur dann betroffen, wenn man sein Projekt – als ein von den USA unerwünschter Weltenbürger – bei gitlab.com hosten will oder bereits gehostet hat.

Bei gitlab.com habe ich zwischenzeitlich einen entsprechenden Hinweis gefunden. Bruchstelle bei GitLab ist offenbar die Google Cloud Platform.

schard
29.07.2019 18:50:04

GitLab ist eine freie Software zur Einrichtung einer Webanwendung zur Verwaltung von Git Repositorien ähnlich wie GitHub. GitLab.com ist eine kommerzielle Plattform, welche diese Software einsetzt.
Ergo kannst du dir GitLab auf deinem privaten Server installieren und das Projekt dort hosten.

Werner
29.07.2019 18:08:51

Unterliegt GitLab nicht ebenfalls dem US-Handelsrecht? Dann würden die US-Sanktionen auch bei den kostenpflichtigen Accounts von GitLab greifen.

… Heise hat das Thema heute aufgegriffen (1)

lolchen
29.07.2019 15:29:20

Na angeblich ist die Krim doch feindlich besetzt? Wieso will man die Bevölkerung mit Sanktionen bestrafen? big_smile

Sanktionen sind sowieso fragwürdig. Wenn man bedenkt dass es primär die Zivilbevölkerung trifft. Github Verlust kostet immerhin nicht das Leben, wie bei Sanktionen auf Medikamente.

Dirk
29.07.2019 14:55:28

GitLab ist eh die bessere Plattform.

Fußzeile des Forums

Powered by FluxBB