PCI Nvidia

Illuminatus

Illuminatus

in geheimer Mission
ZOTAC GeForce® GT 520 PCI
http://www.zotac.com/index.php?page...8&option=com_virtuemart&Itemid=100200&lang=de

wohlgemerkt nicht PCI-Express!

Unter FreeBSD 8.2 x86 erhalte ich beim Laden des nvidia moduls höchstens:

Code: 
nvidia0: <GeForce GT 520> on vgapci0
vgapci0: child nidia0 requested pci_enable_busmaster
vgapci0: child nidia0 requested pci_enable_io
vgapci0: 0x1000000 bytes of rid 0x10 res 3 failed (0, 0xffffffff)
nvidia0: NVRM: NVIDIA MEM ressource alloc failed, BAR0 @ 0x10
nvidia0: NVRM: NVIDIA hardware alloc failed
device_attach: nvidia0 attach returned 6



ich werde in der loader.conf es mit debug.acpi.disabled="sysres" probieren wenn ich das nächste mal am PC bin. Hat jemand eine bessere Idee oder kann deuten worauf die Fehlermeldung zielt?
 
Naja wieviel Sinn eine solche Karte im PCI 32Bit, 33MHz Slot macht sei mal dahin gestellt. PCI-X 64Bit, 133MHz Karten haben halt keinen Markt.

Gab es da nicht ne Nvidia und ne FreeBSD AGP Unterstützung zwischen der man wählen muss/kann?
 
Illuminatus schrieb:
Unter FreeBSD 8.2 x86 erhalte ich beim Laden des nvidia moduls höchstens:

Code: 
nvidia0: <GeForce GT 520> on vgapci0
vgapci0: child nidia0 requested pci_enable_busmaster
vgapci0: child nidia0 requested pci_enable_io
vgapci0: 0x1000000 bytes of rid 0x10 res 3 failed (0, 0xffffffff)
nvidia0: NVRM: NVIDIA MEM ressource alloc failed, BAR0 @ 0x10
nvidia0: NVRM: NVIDIA hardware alloc failed
device_attach: nvidia0 attach returned 6



ich werde in der loader.conf es mit debug.acpi.disabled="sysres" probieren wenn ich das nächste mal am PC bin. Hat jemand eine bessere Idee oder kann deuten worauf die Fehlermeldung zielt?
Zum Vergrößern anklicken....

Das setzen von:
Code: 
debug.acpi.disabled="sysresource"
in der /boot/loader.conf
wäre wohl der einfachste Ansatz:
http://www.nvnews.net/vbulletin/showpost.php?p=2206222&postcount=535

Fällt mir noch was ein, könnte es einen Unterschied machen, an welcher Stelle:
Code: 
nvidia_load="YES"
in der /boot/loader.conf steht?
Bei mir steht es an erster Stelle.
 
Nein, das ist egal. Die Module werden nur vom loader geladen, initialisiert werden sie vom Kernel immer in der richtigen Reihenfolge... Ab 9.0 soll man Module aber eh in der /etc/rc.conf mit kld_list="" laden . Ist nebenbei noch schneller. :)
 
@Yamagi:
Woher bekommt der normale User denn eigentlich solche Infos? Es soll ja auch Situationen geben in denen kein Yamagi (o.ä.) zur Verfühgung steht ;-)
 
Dann schaut man sich z.B. PCBSD9 an, dort wird auch mit kld_list gearbeitet.

Nur für einige Module ist noch ein Eintrag in /boot/loader.conf nötig.
(geli_load, wenn / verschlüsselt sein soll)

Leider sind die manpages unter man.freebsd.org nicht gerade aktuell, denn in den manpages unter RC-1 steht für rc.conf folgende:
Code: 
    kld_list    (str) A list of kernel modules to load right after the local
                 disks are mounted.  Loading modules at this point in the boot
                 process is much faster than doing it via /boot/loader.conf
                 for those modules not necessary for mounting local disk.
 
In den Release Notes könnte es auch stehen. Habe nun aber nicht nachgeschaut... Ich lese einfach die Commits, da bekommt man eigentlich alles mit. "kld_list" wurde auch irgendwann mal auf einer Mailinglisten diskutiert. Den Thread habe ich gelesen, da mich das Thema - GENERIC für FreeBSD 10.0 in Module zerlegen - interessierte.
 
Ein Kernel ist ja doch relativ groß im Verhältnis den TLBs gängiger CPUs. Wie wirken sich Module auf die Nutzung von Superpages aus?
 
Ich habe keine Ahnung... Mein Verständnis bewegte sich immer auf der Ebene, dass ein Modul durch NEWBUS registriert werden muss. Und egal ob statisch ins Image gelinkt oder dynamisch eingefügt, wird es nur genutzt, wenn es Hardware greift und eben diese Registrierung durchführt. Damit macht es keinen Unterschied, ob ein Modul nun statisch gelinkt oder dynamisch geladen wurde. Und tatsächlich habe ich praktisch nie einen messbaren Unterschied gesehen und fahre seit vielen Jahren mit vollmodularisierten Kernel [1] gut.

Eine kurze Suche auf arch@ (nicht per Google, stattdessen im wesentlich besser strukturierten lokalen Archiv) führt zu einem Beitrag von kib@:
Code: 
There might be some measurable difference on i386, where we use dso for
modules. As a consequence, the overhead of GOT/PLT indirection, and, more
important, stolen %ebx on the register-starved architecture, may make
a difference. I doubt that any difference can be measured on amd64.

Weiter unten hat ivoras@ dann einige Milchmädchentests gemacht:
Code: 
For what it's worth, I've done the comparison with GEOM_ZERO and
"diskinfo -vt". The results are surprising. I've done about 7 iterations
of the diskinfo benchmark in each case (module and compiled-in) and
analyzed all their outputs collectively with ministat - as there is no
actually IO performed, all operations are basically NOPs no matter what
seeks are issued.

Here's the ministat analysis of "seek times" (x is as module, + is as
directly compiled; GENERIC is used in both cases, AMD64 8.2-RELEASE):

x  70         0.021         0.031         0.028   0.027585714  0.0016637034
+  98         0.025         0.033         0.031    0.02972449  0.0020548189
Difference at 95.0% confidence
        0.00213878 +/- 0.000583402
        7.7532% +/- 2.11487%
        (Student's t, pooled s = 0.00190204)


Here's the analysis for bandwidth part of the benchmark (same symbols):

    N           Min           Max        Median           Avg        Stddev
x  30       1785465       2096170       1909806     1915060.4     77626.781
+  42       1777623       2083800       1819215     1833298.4     62484.689
Difference at 95.0% confidence
        -81761.9 +/- 32966.2
        -4.26942% +/- 1.72142%
        (Student's t, pooled s = 69161.2)


It looks like for both benchmarks, the results are better for the module
case (lower seek times, higher bandwidth).

As the results were surprising, I did ABAB interleaving of the two cases
(module vs built-in).
Der Thread findet sich hier: http://lists.freebsd.org/pipermail/freebsd-arch/2011-June/011340.html

Das ist nun natürlich alles keine Antwort auf die Frage, aber zeigt zumindest grob in die Richtung...

1:
Code: 
yamagi@happy:pts/4 ~: kldstat
Id Refs Address            Size     Name
 1  237 0xffffffff80100000 653fd0   kernel
 2    1 0xffffffff80754000 7098     vesa.ko
 3    2 0xffffffff8075c000 7838     ataahci.ko
 4    6 0xffffffff80764000 160f0    ata.ko
 5    3 0xffffffff8077b000 adc8     atapci.ko
 6    1 0xffffffff80786000 2ee8     atajmicron.ko
 7    1 0xffffffff80789000 b068     linprocfs.ko
 8    3 0xffffffff80795000 9328     pseudofs.ko
 9    3 0xffffffff8079f000 41fe8    linux.ko
10    2 0xffffffff807e1000 8570     procfs.ko
11    1 0xffffffff807ea000 15520    msdosfs.ko
12    1 0xffffffff80800000 b910     geom_label.ko
13    1 0xffffffff8080c000 20de0    firewire.ko
14    1 0xffffffff8082d000 7418     if_tap.ko
15    1 0xffffffff80835000 7318     if_tun.ko
16    1 0xffffffff8083d000 3d330    miibus.ko
17    1 0xffffffff8087b000 68be8    if_em.ko
18    1 0xffffffff808e4000 18ae8    if_ral.ko
19    2 0xffffffff808fd000 3d48     firmware.ko
20    4 0xffffffff80901000 59e30    wlan.ko
21    2 0xffffffff8095b000 1c30     wlan_amrr.ko
22    4 0xffffffff8095d000 74f60    sound.ko
23    1 0xffffffff809d2000 a038     snd_envy24ht.ko
24    2 0xffffffff809dd000 1b78     snd_spicds.ko
25    1 0xffffffff809df000 24ce0    snd_hda.ko
26    7 0xffffffff80a04000 35650    usb.ko
27    1 0xffffffff80a3a000 7ea8     ukbd.ko
28    1 0xffffffff80a42000 4410     ums.ko
29    1 0xffffffff80a47000 8c18     umass.ko
30    4 0xffffffff80a50000 81b88    cam.ko
31    1 0xffffffff80ad2000 efe0     aio.ko
32    1 0xffffffff80ae1000 f0f8     random.ko
33    1 0xffffffff80af1000 1f30     coretemp.ko
34    1 0xffffffff80af3000 2908     geom_part_bsd.ko
35    1 0xffffffff80af6000 28c8     geom_part_mbr.ko
36    1 0xffffffff80af9000 5df8     geom_part_gpt.ko
37    1 0xffffffff80aff000 40d8     atadisk.ko
38    1 0xffffffff80b04000 103f8    ahci.ko
39    2 0xffffffff80b15000 3ae0     mem.ko
40    2 0xffffffff80b19000 10b0     io.ko
41    1 0xffffffff80b1b000 5230     atapicam.ko
42    2 0xffffffff80b21000 23c8     smbus.ko
43    1 0xffffffff80b24000 5158     ichsmb.ko
44    1 0xffffffff80b2a000 10350    cpufreq.ko
45    1 0xffffffff80b3b000 ae88     xhci.ko
46    1 0xffffffff80b46000 d180     ehci.ko
47    1 0xffffffff80b54000 6208     kbdmux.ko
48    1 0xffffffff80b5b000 15e20    fuse.ko
49    1 0xffffffff80b71000 cf20     if_bridge.ko
50    2 0xffffffff80b7e000 6628     bridgestp.ko
51    3 0xffffffff80b85000 4c098    vboxdrv.ko
52    1 0xffffffff80bd2000 37c0     wlan_tkip.ko
53    1 0xffffffff80bd6000 641f0    ufs.ko
54    3 0xffffffff80c3b000 1f170    krpc.ko
55    1 0xffffffff80c5b000 10498d0  nvidia.ko
56    1 0xffffffff81ca5000 5e40     cuse4bsd.ko
57    1 0xffffffff81cab000 4488     aesni.ko
58    1 0xffffffff81cb0000 49a0     cryptodev.ko
59    1 0xffffffff81cb5000 8290     ng_ubt.ko
60    8 0xffffffff81cbe000 14d80    netgraph.ko
61    2 0xffffffff81cd3000 12f88    ng_hci.ko
62    4 0xffffffff81ce6000 2d40     ng_bluetooth.ko
63    1 0xffffffff81ce9000 41d8     ichwd.ko
64    1 0xffffffff81e22000 b740     geom_eli.ko
65    1 0xffffffff81e2e000 155c     fdescfs.ko
66    2 0xffffffff81e30000 290e     vboxnetflt.ko
67    1 0xffffffff81e33000 151a     ng_ether.ko
68    1 0xffffffff81e35000 e5c      vboxnetadp.ko
69    1 0xffffffff81e36000 c5fa     ipfw.ko
70    1 0xffffffff81e43000 a6be     libalias.ko
71    1 0xffffffff81e4e000 14168    nfsclient.ko
72    1 0xffffffff81e63000 bf0      nfslock.ko
73    2 0xffffffff81e64000 908      nfs_common.ko
74    1 0xffffffff81e65000 15f10    nfsserver.ko
75    1 0xffffffff81e7b000 360      nfssvc.ko
76    1 0xffffffff81e7c000 b460     ng_l2cap.ko
77    1 0xffffffff81e88000 16918    ng_btsocket.ko
78    1 0xffffffff81e9f000 1ba6     ng_socket.ko
 
an dieser Stelle Vielen Dank für eure Antworten.
@Yamagi: ich habe dich dieses Jahr noch nicht gelobt für deine ausführlichen, informativen, hilfreichen und immer interessanten Beiträge
ride on!

@Fusselbär - ob debug.acpi.disabled="sysresource" hilft sehe ich heute abend
übrigens hat die Maschine nur 3GB RAM verbaut
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben