|
|
|
|
|
|
|
Wenn ich zu faul bin, einen Laptop zu öffnen aber trotzdem wissen will, ob er einen m.2 Slot hat, kann ich das unter Linux irgendwie abfragen? 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Wenn ich zu faul bin, einen Laptop zu öffnen aber trotzdem wissen will, ob er einen m.2 Slot hat, kann ich das unter Linux irgendwie abfragen?
| |
Kannst du das nicht über Google abfragen? So mit Marke, Model...?
Listet 'lspci' was passendes?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GandalfDerPinke am 17.05.2017 8:50]
|
|
|
|
|
|
|
|
|
|
Dachte ich auch. Ist aber ein etwas älteres Tuxedo Book und die haben sich tatsächlich jede Modell-Bedruckung gespart
|
|
|
|
|
|
|
|
|
|
|
Nein. Du solltest das nicht mit lspci sehen koennen, weil lspci die Komponenten am PCI-Bus auflistet und am M2-Slot ist derzeit, falls vorhanden, wohl nichts.
Wenn du das Geraet wirklich nicht aufschrauben willst und auch unter der Batterie (da verstecken Hersteller gerne: SIM-Kartenslots, Windowssteueraufkleber, Modellbezeichnungen...) nichts findest, wuerde ich dmidecode verwenden. Du musst das aber als root ausfuehren:
Beispiel mit (sinnvollen) Typparametern:
| |
| Code: |
[root@lap-lnx-hsi hoschi]# dmidecode -t 1, 2, 3
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.6 present.
Handle 0x000E, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 4236NGG
Version: ThinkPad T420
Serial Number: R8N6VK3
UUID: FFB40081-513E-11CB-BDDD-D8ED8954EC35
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: ThinkPad T420
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 17.05.2017 10:30]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Beispiel mit (sinnvollen) Typparametern:
| |
| Code: |
[root@lap-lnx-hsi hoschi]# dmidecode -t 1, 2, 3
|
|
| |
Danke, damit bin ich weiter gekommen. Und kein m.2 slot für mich  .
|
|
|
|
|
|
|
|
|
|
|
|
lshw zeigt auch alles detailliert an.
|
|
|
|
|
|
|
|
|
|
|
|
Die Schenker-Tuxedo-etc. Notebooks sind irgendwelche Barebones aus Taiwan von Clevo, da stehen zwar irgendwelche Modellbezeichnungen drauf, die waren bei mir aber nicht zielführend...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Krypt0n
Ich habe hier ein längeres Stück C Code, das sich unter
valgrind --tool=memcheck anders verhält als unter valgrind --tool=callgrind (Das Verhalten unter memcheck entspricht dem verhalten ohne valgrind, callgrind sorgt für fehlschlagende Tests).
Weiß jemand wie man herausfinden könnte woran das liegt?
| |
Was heißt denn "fehlschlagende Tests"? Fließkommadifferenzen, oder "echte" Unterschiede? valgrind lädt teilweise eigene (nicht die Standard) Bibliotheken insbesondere auch für mathematische Funktionen (wenn ich das gerade richtig im Kopf habe). Lädt er da vielleicht unterschiedliche?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [CSF]Omega
Was heißt denn "fehlschlagende Tests"? Fließkommadifferenzen, oder "echte" Unterschiede? valgrind lädt teilweise eigene (nicht die Standard) Bibliotheken insbesondere auch für mathematische Funktionen (wenn ich das gerade richtig im Kopf habe). Lädt er da vielleicht unterschiedliche?
| |
Keine Fließkommazahlen oder Bibliotheken.
4096 Bit Daten werden mit SSE2, AVX und AVX2 Instruktionen verschlüsselt und mit einem Referenzoutput verglichen. Ca. 7 64-Bit Blöcke davon sind komplett unterschiedlich, der rest identisch.
AVX und AVX2 scheinen relativ neu in valgrind zu sein, ich könnte mir vorstellen, dass es da irgendwo einen Bug gibt.
Ich habe es inzwischen auf eine intrinsic eingegrenzt, in der der Unterschied stattfindet. Wenn ich vorher den Zielbuffer memsette, verhält sie sich normal, ansonsten tritt der Unterschied auf. Ich werde später mal versuchen ein minimales Beispiel zu basteln.
|
|
|
|
|
|
|
|
|
|
|
Klingt interessant, halt uns auf dem Laufenden.
https://www.polygon.com/2017/5/16/15622366/valve-gabe-newell-sales-origin-destructive
Hat uns Valve reingelegt? Ich Spiele (bis jetzt) nur Valves eigene Titel mit Steam. Und ich habe immer vor der Allmacht einer technisch unnoetigen Luliveupdateplattform gewarnt. Trotzdem, der Linuxsupport hat mich sofort in eine willenlosen Lemming verwandelt.
Sie habe bis jetzt keine groesseren Schaden auf Clientrechner angerichtet. Dafuer laufen die Spiele nur so lange es Valve gibt und Valve ueber Internet erreichbar ist. Aber die AppStore-Ausbeutung laesst Apple, Google und Windowsstore beinahe Human aussehen.
Der Rant gegenueber sogenannten Startups, die angebliche so viel Leisten ist uebrigens richtig gut. Die Gier nach schneller Marktdominanz ist die Ursuende der IT, kritische Nutzermasse erreichen um jeden Preis.
Dank an Fefe, endlich mal wieder pure IT.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Valgrind?
Ich tippe mal auf einen Bug im Decoder / Instrumenter, der nur durch Callgrind ausgelöst wird.
e: 82.22% of diff hit (target 83.53%) — knapp vorbei ist auch daneben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 17.05.2017 21:41]
|
|
|
|
|
|
|
|
|
Ganz dumme Frage, aber diese Zeile hier:
| |
| Code: |
vpxor %xmm1, %xmm1, %xmm1
|
|
sieht für mich ein bisschen komisch aus. Ich nehme an, die soll die 0-Werte setzen, setzt aber nur die unteren 128 Bits des xmm1/ymm1 Registers neu, sollte dann in den oberen 128 Bits von (jetzt nur) ymm1 nicht noch das 0xf drin stecken? Nicht dass das irgendeinen Unterschied machen sollte, nachdem das Ergebnis des zweiten maskstore eh nicht benutzt wird.
¤: Und ja, Google sagt das valgrind in der Tat mal Probleme mit vmov... hatte, die sollten aber seit 3.10 gefixt sein, aber vielleicht hilft ein Update ja trotzdem.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [CSF]Omega am 17.05.2017 22:25]
|
|
|
|
|
|
|
|
|
| | Zitat von [CSF]Omega
Ganz dumme Frage, aber diese Zeile hier:
| |
| Code: |
vpxor %xmm1, %xmm1, %xmm1
|
|
sieht für mich ein bisschen komisch aus. Ich nehme an, die soll die 0-Werte setzen, setzt aber nur die unteren 128 Bits des xmm1/ymm1 Registers neu, sollte dann in den oberen 128 Bits von (jetzt nur) ymm1 nicht noch das 0xf drin stecken? Nicht dass das irgendeinen Unterschied machen sollte, nachdem das Ergebnis des zweiten maskstore eh nicht benutzt wird.
| |
Laut einer zufälligen website, die man findet wenn man die instruktion sucht, zeroed sie die obere hälfte, wenn sie mit %xmm registern verwendet wird.
|
|
|
|
|
|
|
|
|
|
|
nur so nebenbei, die parameter für die maskstore intrin sind richtig rum? du willst den inhalt von B1/B2 via one in temp speichern?
mich wundert da eher, dass der gcc da nicht erkennt, dass du da effektiv ne 0 weiterreichst.
was wird da als asm generiert, wenn du die schleife mit dem printf weg lässt?
die alignments der variablen stimmen alle? die vektor sachen sind da ein wenig speziell was das angeht.
nur als referenz:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/
|
|
|
|
|
|
|
|
|
|
|
Daran habe ich mich bisher orientiert. Das schreibt aber nichts davon, was vpxor mit 128Bit registern macht, noch, ob die verwendeten intrinsics irgendein alignment brauchen (was wohl heißt, dass sie keins brauchen).
Nur movdqa brauch ein Alignment und das ist durch .align 32 erfüllt meines erachtens.
| |
nur so nebenbei, die parameter für die maskstore intrin sind richtig rum? du willst den inhalt von B1/B2 via one in temp speichern?
| |
Ja
| | Zitat von Traxer
mich wundert da eher, dass der gcc da nicht erkennt, dass du da effektiv ne 0 weiterreichst.
was wird da als asm generiert, wenn du die schleife mit dem printf weg lässt?
| |
Ich habe jetzt test2.s zum obigen link hinzugefügt, in der ich die Schleife von 1 habe beginnen lassen. Dadurch wird sie geunrolled und der Fehler tritt nicht mehr auf.
|
|
|
|
|
|
|
|
|
|
|
Dann wende Dich doch mal an die valgrind-Leute, zumindest der Assemblercode scheint vom GCC ja richtig/sinnvoll erzeugt zu werden.
clang optimiert übrigens alle AVX Sachen weg, und ruft printf mit Konstanten auf.
|
|
|
|
|
|
|
|
|
|
|
|
Ich muss mich mit OSM befassen, hat mal jemand ein gutes Howto zur Hand wie man einen Tileserver aufsetzt?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das ist nunmal der Support den man bekommt, wenn man Kunde ist und nicht das Produkt. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Wenn ihr euch da sicher seit... | |
Wieso?  Bisher kam nur "guck dir das mal an".
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
| | Zitat von GH@NDI
Wenn ihr euch da sicher seit... | |
Wieso? Bisher kam nur "guck dir das mal an".
| |
Sofern ihr Planet.osm nutzen wollt, braucht ihr für die Tiles schonmal 12TB DiskSpace. Kleine Regionen entsprechend weniger. 
Allein die Planet.osm ist als XML file ~790GB groß. Der Import in eine PostgreSQL geht je nach Performance Stunden oder Tage.
Ich will dich nicht gleich komplett desillusioneren. Aber je nachdem was ihr vor habt, müsst ihr da schon resourcen rein buttern.
// Serving your own tiles?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 18.05.2017 14:37]
|
|
|
|
|
|
|
|
|
|
Also wir brauchen nur DE. Das ist aber schonmal ein Argument mir ne bessere Vorgabe zu machen als "guck dir das mal an"
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealHawk am 18.05.2017 14:54]
|
|
|
|
|
|
|
|
|
|
Wenn ihr einfach nur weg von Google wollt dann müsst ihr nicht gleich den ganzen Stack hochziehen. Dann könt ihr (bis zu einer gewissen Nutzerbasis) einfach die offiziellen Tile-Server nutzen. Wenns größer wird kann man auch TileHosting buchen. Oder z.B. bei MapBox auch eigene Stile übers Web konfigurieren und die machen dann das HeavyLifting gegen einen kleinen Obulus.
|
|
|
|
|
|
|
|
|
|
|
|
Hab das mal so ins Ticket geschrieben und als obsolet geschlossen
|
|
|
|
|
|
|
|
|
|
|
|
xml 790GB... als json wärs dann nur nen viertel davon gewesen...
|
|
|
|
|
|
|
|
|
|
|
|
nett stell ich mir bei solchen daten nen "append" vor...
|
|
|
|
|
|
|
|
|
|
|
Sind dafür diese "Load-Store" Architekturen, Papa?
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
