Inlägg

Vad jag förstår är Ky X1 en rebrandad Spacemit K1/X60 (den verkar i alla fall kunna använda samma stöd av det som hittills upstreamats i linux: https://lore.kernel.org/spacemit/20250718085718-GYA695709@gen... och borde därför inte vara sämre men jag kanske missar något.

En lite mindre rolig detalj med just Spacemit K1 är att medan den stödjer unaligned minnesåtkomst för grund-ISAn så gäller det inte för vektortillägget (och har ingen fallback i firmware)... GCC 14:s autovektorisering är inte särskilt bra på att hantera det och genererar i flera fall unaligned minnesåtkomst i sin vektoriserade kod. GCC 15 verkar dock ha löst det i princip helt och klarar att falla tillbaka på skalär kod även i ett test där jag avsiktligt använder minnet unaligned. LLVM (testat 18 upp till och med 20) verkar också ha problem, kanske något mindre än GCC 14 men en del kompilerade program verkar fortfarande dödas av SIGBUS. Kan också se att den gerererar unaligned minnesåtkomst i den vektoriserade koden i testet, dock är testet troligtvis egentligen UB så skulle inte dra någon större slutsats av att just det blir fel.

Jag köpte en BPI-F3 (som använder Spacemit K1) i juli förra året och den första vendor-kärnan baserad på 6.1 var horribel att arbeta med (den hängde sig alltid under belastning efter ett tag om CONFIG_COMPACTION var påslaget exempelvis...). Den baserad på 6.6 är mycket bättre men fortfarande inte helt hundra. Den på 6.1 (och även den på 6.6 till en början) hade de squashat allt till ett par mega-commits där även tidiga patchar på annat från innan de blev accepterade i mainline ingick vilket försvårat felsökning avsevärt, men det är väl tyvärr inte ovanligt att vendor-kärnor ser ut på det sättet. Det finns också en baserad på ca 6.13-rc1 men den har ett par uppenbara artefakter av att vara rebasad som man behöver fixa själv om den ska gå att bygga med rimlig config. Nu börjar iaf stödet i mainline linux bli användbart (om man inkluderar ett par till patchar som inte är helt igenom review) så slipper bråka mer med gamla vendor-kärnor vilket jag är glad över.

Felsökningssteg kan ibland introducera nya fel, det är därför bra att börja med mindre invasiva åtgärder först.
Jag upplevde det senast när jag hjälpte min kusin med en dator som inte startade, han hade tidigare uppdaterat BIOS med flashback. Den POSTade inte alls och gav inte ifrån sig någon felkod. Tog vi bort minnet så pep den men så fort någon av RAM-stickorna kopplades in gjorde den ingenting. Vi testade en massa andra saker men nedgraderade till sist till en tidigare BIOS-version och då POSTade den (ironiskt nog så hade changelog på senaste versionen "Improve memory compatibility"). Visade sig att det ursprungliga problemet var att grafikkortet hade gett upp vilket kunde ha identifierats genom att koppla in bildkabeln till moderkortet istället då CPU hade IGP.

Vet inte om det skulle fungera på er struktur men ett vanligt sätt att göra det stegvis är att lägga till IPv6 på en separat subdomän (exempelvis ipv6.sweclockers.com). Då borde eventuella problem med IPv6 inte påverka huvudsidan och så får ni mer data som hjälper er att utvärdera hur det fungerar. Det låter också oss som vill testa göra det

Har ni någon som använder Tre eller Tele2 till mobilabonnemang? Om jag kommer ihåg rätt har de båda IPv6 påslaget (kombinerat med CG-NAT för IPv4) så det kan vara ett alternativ för att testa internt. Tror det även ska fungera via internetdelning från telefon. Men ifall ni har ett övervakningssystem (typ nagios eller liknande) som inte har tillgång till IPv6 förstår jag att ni är lite tveksamma.

Mjukvara jag inte sett i tråden hittills:

tcpdump - analysera nätverkskommunikation
iperf2/iperf3 - smidigt verktyg för att mäta hastigheten på nätverket mellan två datorer
bird - en routing daemon som har det mesta (BGP, OSPF, mm)
nmap - analysera enheter på nätverk
efibootmgr - hantera (U)EFI boot-poster
pass - en avskalad lösenordshanterare som använder sig av gpg för kryptering
imv - ett alternativ till feh som funkar bra även i wayland
gnuplot - generera grafer
imagemagick och graphicsmagick - bildbehandling mm
smartmontools och hdparm - bra verktyg för hårddiskar och ssd:er
bemenu - ett alternativ till dmenu som funkar bra även i wayland

Jag ber om ursäkt om det framstod som jag försökte rätta någon med mitt inlägg, det var inte min avsikt. Jag tyckte det var roligt att mitt tidigare inlägg var uppskattat och ville därför utveckla. Vad är det jag skrivit som säger emot något i den länkade artikeln? Jag har aldrig påstått att det bara går att ta bort boot-entrys med efibootmgr.

edit:
Okej, visst. Jag kan medge att när väl distributioner är installerade så är det ingen större mening att ha /sys/firmware/efi/efivars monterad rw förutom undantagsvis. LVFS/fwupd kan vara en exempelvis. Jag är också medveten om att vissa kommandon kan ha dålig effekt på uefi om efivars är monterad rw, `# rm -rf --no-preserve-root /` är väl klassikern som i vissa fall kan bricka uefi.
Min kommentar om liveavbilder hänvisar tillbaka till att jag skrev att det gick att göra ändringen på en sådan i mitt första inlägg.
Jag kunde antagligen ha varit tydligare med hur jag framfört det, men i mitt första inlägg inkluderade jag även en rad som visade hur /sys/firmware/efi/efivars skulle vara monterad för att göra ändringen, vilket visar rw.

Det stämmer att /sys/firmware/efi/efivars behöver vara rw för att kunna göra ändringar. Verkar vara lite olika beroende på distribution om den är rw eller ro. De flesta liveavbilder jag testat har dock varit rw, svårt att installera bootloadern annars

Antagligen ja. De vanligaste distributionerna gör en automatisk installation av bootloader och den kommer då att lägga till en boot-entry och sätta den som standard. Gäller även Windows, därför det är enklast att installera Windows först för dual-boot. Nu på uefi-tider så ligger dock den gamla boot-entryn kvar så är bara att sätta den som standard igen. Med efibootmgr kan ordningen ändras med parametern `-o`. Går ju också ofta att ändra ordningen i uefi-gränssnittett direkt om det inte är överdrivet dåligt.

Det stämmer att efibootmgr i sig inte är en bootloader, men skulle säga att en ny installation av os kommer att ändra boot-ordningen vanligtvis. Är väl mer undantagsvis som distributioner låter användaren välja hur bootloadern ska installeras/konfas som förval. efibootmgr kan som ditt citat säger använda uefi-firmware som en bootloader. Jag använde det för ett par år sedan, men bytte för att få bättre flexibilitet.
Körde något sådant här:

#!/bin/sh
efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u \
	"cryptdevice=PARTUUID=a9c2f6c9-5e51-47de-b5b0-4fce3e5e6694:archroot \
	root=/dev/mapper/archroot \
	initrd=/intel-ucode.img \
	initrd=/initramfs-linux.img rw"

Använde Arch vid den tidpunkten men har gått över till andra distributioner.

Tack för svar! Skriv gärna i den här tråden när ni börjar med öppnare tester.

Hej,

Finns någon uppdatering om detta? Precis som @ZerxXxes skriver så har flera mobiloperatörer stöd för IPv6 i sina mobilnät numera.
Som det står här så verkar fler och fler operatörer planera för att införa IPv6 i sina nät eller redan gjort det.
Det finns även uppgifter som tyder på att anslutningar uppkopplas snabbare på IPv6, dvs att användarupplevelsen kan förbättras.

Sen sist har jag uppgraderat från tunnlar via he.net till ett eget autonomt system för IPv6. Jag får också publika IPv6-adresser via min mobiloperatör som annars delar ut CG-NATade IPv4-adresser.

Naturligtvis förväntar jag mig inte att IPv6 kan kopplas på omedelbart. Jag skulle dock gärna vilja se att det finns någon ungefärlig tidsuppskattning på när detta kan införas, alternativt om det är något tekniskt förhinder som gör att det inte går att införa.

Fast Arch kanske inte är det bästa exemplet om att inte behöva starta om vid uppdateringar.
Det har att göra med att Arch inte sparar gamla versioner av linuxkärnan och moduler (ungefär drivrutiner). Det kan då alltså hända att saker slutar fungera efter ett tag om kärnan uppdaterats och man inte startat om. Exempelvis kanske det inte går att montera en extern hårddisk (om filsystemet på den inte används på datorn i övrigt). Det går då att antingen starta om datorn eller ominstallera den gamla kärnan.
Det går att göra med något i stil med:

pacman -U /var/cache/pacman/pkg/linux-$version.tar.zst

Många andra distar sparar de gamla versionerna ett tag så då går det bra att vänta med omstart, men för att den nya kärnan ska användas behövs det. Om vi nu inte ska prata om livepatchning, men det är inget som används ofta i praktiken utanför vissa servrar.

Jag har kört tunnlad IPv6 ganska länge. Min bredbandsleverantör ska ha IPv6 redo, men mitt stadsnät (Zitius) har fortfarande inget stöd. Nu kör jag mitt egna AS från en server på colocation och ett par VPS:er, och det är ju lite roligt att hålla på med BGP och andra routingprotokoll. Jag har självklart filter både ut och in så jag inte läcker prefix jag inte är tilldelad.

Här blev det lite fel. Först, det går att dela upp subnät i vilken storlek som helst, så länge de håller sig inom det tilldelade huvudnätet, alltså i detta fall 192.168.0.0/16, 172.16.0.0/12 eller 10.0.0.0/8. Några exempel: 192.168.128.0/19 (192.168.128.0-192.168.159.255), 172.18.0.0/15 (172.18.0.0-172.19.255.255), 10.192.0.0/12 (10.192.0.0-10.207.255.255). Det är dock inte alla konsumentrourar tillåter det.

Man förlorar 2 adresser för varje subnät (exklusive routern), så ju fler och mindre subnät, desto större förlust. 254 noder stämmer för /24 nätverk, men vet inte riktigt var du fick 254 * 254 från. Det går utmärkt att använda 172.16.0.0/24 och 172.16.255.0/24 som subnät, eller tex 172.16.254.255/23 och 172.16.255.0/23 som adresser. Om man delar upp 172.16.0.0/16 i /24 nät får man 256 * 254 adresser totalt för de näten.

Finns inget som kräver att man begränsar dig till de klassfulla storlekarna, om man nu inte har någon enhet med inkomplett implementering av internetprotokollen. Det maximala antalet adresser som går att använda i respektive tilldelning är 2^16-2 (hela 192.168.0.0/16), 2^10-2 (hela 172.16.0.0/12) och 2^24-2 (hela 10.0.0.0/8).

Subnätsuppdelning kan vara lite bedrägligt om man vill göra annat än de vanligaste uppdelningarna

Jag skulle gissa på att nvidia-settings inte kan hitta DISPLAY (om du nu kör med X). Den är ofta :0, så prova att sätt den till det.
Jag skulle göra något sånt här:

#!/bin/sh -x
LOG="/var/tmp/$(date "+autostart-%y%m%d_%H%m%S.log")"
exec 2> "$LOG" > "$LOG"

DISPLAY=":0" nvidia-settings --load-config-only

exit 0

Då kommer du kunna se vad sh säger i loggen.
Jag har även för mig att bla debian och ubuntu kör med dash som sh istället för bash vilket kan ge små inkompatibiliteter ibland, men tvivlar på att det är så i detta fallet.

Om du utgår från scenario 2 och urmarkerar Tagged: yes från raden med Bridge: WAN borde det ge dig resultatet du vill ha. I nuläget försöker din router ta internet från VLAN 2 på WAN vilket inte kommer funka.

Har ingen aning om det här stämmer på Bredband2, men vad jag vet så använder flera operatörer förtidsfakturering. Om de skickar första fakturan månaden efter du beställt abonnemanget så kommer den täcka 3 perioder: Del av första månaden, nuvarande månad och nästa månad. Sen har flera stadsnät en anslutningsavgift/startavgift också, men den borde ha framgått i beställningen.

Hittade den här, bahnhofs delårsrapport Q3 2018 (möjligtvis betalvägg): https://www.svd.se/bors/news_detail.php?newsid=58dd6167-0368-400a-b471-3201e3c0f672

Nej, artikeln fokuserar inte bara på att vi inte kan höra över en viss frekvens. Här är innehållsförteckningen:

Jag skulle väldigt gärna vilja ha källor på dina påståenden, både den teoretiska och experimentella biten. Jag är själv på inget sätt någon expert på signalbehandling, vilket är ett stort och komplext område, så jag förbehåller mig själv att jag kan ha fel. Med det sagt så hittar jag inget som stödjer dina påståenden.

När en gör egna tester är det viktigt att vara medveten om bland annat placebo-effekt och confirmation bias. Det står mer om det i artikeln under rubrikerna Confirmation bias till Inadvertant cues. Ett sätt att undvika mycket av detta är ABX-tester, en typ av dubbelblindtest.

Den artikel jag länkat till refererar till en studie med dubbelblindtest. Från artikeln:

edit:
Se också speciellt sida 23-26 i denna artikel (som länkas i den första artikeln). Resten av den är också intressant.