Kernel Modul erstellen, austauschen... Anfängerfrage

[pit234a]

Hi.
Mein Laptop hat einen Wlan-Chip engebaut und ich versuche, den mal unter FreeBSD zu nutzen. Dabei taucht ein Problem auf, dessen Lösung hier:
http://forums.pcbsd.org/viewtopic.php?f=27&t=11827
beschrieben ist.
Da wird erklärt, daß es ein neueres Kernelmodul gibt und auch, wie ich dieses einbauen könnte.
Mein Problem ist, daß ich auf diesem Laptop, wo FreeBSD von eimen USB-Stick läuft, keine sources aufgespielt habe.
Also, das Vorgehen, das in dem Thread oben beschrieben wird, nämlich den Code des neuen Moduls nach /sys/contrib/dev/ath/ zu bringen und danach in /sys/modules/ath_hal/ ein make zu starten, das gelingt natürlich nicht, denn bei mir ist in /sys alles leer.
Nun möchte ich nicht unbedingt nur um dieses .ko zu bauen, den Rest auch installieren.
Ich habe aber Rechner, hier einen amd64, auf dem die sourcen installiert sind.
Deshalb die Fragen:
-kann ich ein solches Modul, das ich auf einem amd64 bauen lasse, in einem anderen Rechner, einem i386, einsetzen?
-kann ich auf einem amd64er ein Modul für einen i386er bauen lassen und wenn ja, wie?

edit:
ich möchte das noch ergänzen, denn inzwischen habe ich auch keinen Erfolg damit gehabt, die Kernel-Sourcen zu installieren und dann diesen neuen .ko zu aktivieren. Weder das beschriebene, einfache Kopieren nach /boot/kernel half, noch das make install nach dem make, wobei das .ko ja entstanden war. Durch das make install wird das neue File ebenfalls an /boot/kernel gesandt und außerdem noch ein kldxref /boot/kernel nachgeschickt. Trotzdem meldet sich dmesg noch immer mit der alten Version und dem gleichen Fehler.
Nun verstehe ich offensichtlich nicht das Konzept der festeingebauten und ladbaren Module.
kldstat zeigt mir von all diesen nämlich auch nichts an, kldload erklärt aber, daß sie bereits laufen. Deshalb vermute ich mal, daß kldstat nur nachträglich geladene Module anzeigt und nur die mit kld(un)load gest(oppt)artet werden können. Das würde mir erklären, daß es keinen Erfolg haben kann, nur das Modul zu tauschen. In einem solchen Fall müsste ich wohl mit den veränderten Kernel-Sourcen diesen neu kompilieren, oder einen Weg finden, nicht das feste Modul zu nehmen, sondern das nachträglich erstellte manuell zu laden.
Bitte verbessert mich und klärt mich vielleicht mal auf.

 

[Yamagi]

Ich gehe erst einmal auf den letzten Teil ein:
Der FreeBSD-Kernel kennt nur Module. Es gibt technisch gesehen keinen Unterschied zwischen fest eingbaut und nachträglich geladen, ein nachträglich gelandes Modul ist daher prinzipbedingt auch nicht langsamer oder ähnliches als ein fest eingebautes. Um nicht zu sagen, dass es mit völlig unverständlich ist, wieso FreeBSD GENERIC nicht auf das absolute Minimum beschränkt und wirklich alles was geht als Modul lädt. Da FreeBSD eine stabile API hat und zudem in Zukunft (ab 8.0) die Module zudem noch eine interne Versionierung haben, die das Laden nicht funktionierender Module verhindert, wäre dies problemlos möglich und tendentiell sogar sicherer als unter Linux, wo veraltete Module schon mal das System abstürzen lassen.
Der einzige Unterschied zwischen eingebauten und nachträglich geladenen Modulen liegt in ihrer Endladbarkeit. Ein nachträglich geladenes Modul wird vom sogenannten "Kernel Linker" in den laufenden Kernel eingefügt. Da dieser weiß, wie er es gemacht hat, kann er diesen Vorgang rückgängig machen und das Modul wieder entfernen. Zumindest meistens, es gibt einige Module, die sich nicht wieder entladen lassen. "aio.ko" ist so eines. Bei Module von Drittanbietern können die Entladeroutinen auch fehlerhaft sein, dass Rausschmeißen von "nvidia.ko" führt daher gerne mal zum sofortigen Absturz. Fest in den Kernel eingebaute Module sind fest verdrahtet. Der Linker weiß nicht, wie diese eingefügt wurden, kann sie also auch nicht entfernen. Daher kannst du ein per "device if_ath" in deinen Kernel einkompilierten Atheros-Treiber nicht entfernen. Du kannst auch das Modul nicht laden, da es ja bereits geladen ist.

Das ist die Theorie, nun die Praxis:
Dadurch, das ein Modul fest verdrahtet wird, wird es zu einem sogenannten "Untermodul". Ein Beispiel:

12    4 0xffffffff807df000 67360    sound.ko
	Contains modules:
		Id Name
		37 sound
		38 midi

Das Modul "midi" ist mit dem Modul "sound.ko" fest verdrahtet. Wer "midi" will, muss also auch den Rest, der in "sound.ko" mit drinhängt mitnehmen. Umgekehrt kann man "midi" auch nicht alleine entladen, wer es loswerden möchte, muss das ganze sound.ko entfernen. Es ist nun - rein theoretisch - möglich, diese Verdrahtungen in der Kernelkonfiguration aufzuheben. Sinnvoll ist dies aber nicht, da sie meist aus gutem Grund existieren.

Ebenso ist der Kernel nicht mehr als ein Modul, die in ihn hineingebauten Dinge werden als Submodule fest verdrahtet:

 1   54 0xffffffff80100000 575ae0   kernel
	Contains modules:
		Id Name
		121 nexus/acpi
		122 acpi/acpi_acad
		123 acpi/acpi_button
		124 acpi/acpi_cmbat
		125 acpi/cpu
		126 acpi/acpi_ec
		127 acpi/acpi_hpet
		128 acpi/acpi_isab
		129 acpi/acpi_lid
		130 pcib/acpi_pci
		131 acpi/acpi_pci_link
		132 acpi/acpi_pcib
		133 pci/acpi_pcib
		134 cpu/acpi_perf
		135 acpi/acpi_sysresource
		136 acpi/acpi_smbat
		137 acpi/acpi_tz
		138 cpu/acpi_throttle
		139 acpi/acpi_timer
		140 legacy/eisa
		141 eisab/eisa
		142 eisa/mainboard
		143 null
		144 pci/eisab
		145 pci/fixup_pci
		146 pci/hostb
		147 pci/ignore_pci
		148 pci/isab
		149 pcib/pci
		150 pci/pcib
		151 pci/vgapci
		152 acpi/uart
		153 isa/uart
		154 cardbus/uart
		155 pci/uart
		156 watchdog
		157 devfs
		158 g_dev
		159 g_disk
		160 g_vfs
		161 g_part
		162 eisab/isa
		163 isab/isa
		164 isa/isahint
		165 isa/orm
		166 elf64
		167 shell
		168 cpu/cpufreq
		169 rootbus
		170 sysvmsg
		171 msgrcv
		172 msgsnd
		173 msgget
		174 msgctl
		175 msgsys
		176 sysvsem
		177 semop
		178 semget
		179 __semctl
		180 semsys
		181 sysvshm
		182 shmget
		183 shmdt
		184 shmctl
		185 shmat
		186 shmsys
		187 ether
		188 loop
		189 zlib
		190 nexus/cryptosoft
		191 ufs
		192 g_class
		193 acpi/fpupnp
		194 nexus/apic
		195 pci/ioapic
		196 legacy/cpu
		197 nexus/legacy
		198 isa/sysresource
		199 nexus/ram
		200 root/nexus
		201 acpi/attimer
		202 isa/attimer
		203 legacy/isa
		204 acpi/atdma
		205 isa/atdma
		206 isa/pcibus_pnp
		207 legacy/pcib
		208 atkbdc/atkbd
		209 acpi/atkbdc
		210 isa/atkbdc
		211 scterm-sc
		212 scrndr-vga
		213 isa/sc
		214 isa/vga
		215 elf32

Dies sind also aus Sicht des System normale Submodule, die genauso wenig wie "midi" im oberen Beispiel allein betrachtet werden können. Den Kernel komplett zu entladen und einen neuen zu laden geht im laufenden Betrieb auch nicht, man kann sich denken wieso

Zum Schluss noch zwei Anmerkungen:
- Module von Drittanbietern kommen nach /boot/modules, nicht nach /boot/kernel. Ein neuer Kernel überschreibt sie dann nicht.
- Nachdem ein neues Modul in sein Zielverzeichnis kopiert wurde oder ein vorhandenes geänder wird, muss einmal "kldxref /verzeichnis" ausgeführt werden. Dies baut eine Zusammenstellung, die dem Kernel Linker sagt, wie Module zusammenhängen. Sprich "Wenn du if_em lädtst, musst du erst miibus laden!". Lässt man diesen Schritt weg, kann es böse - also im Absturz - enden.

P.S.: Die schönen Ausgaben der Module oben erhält man mit "kldstat -v"

 

[pit234a]

Oh, das ist sehr erhellend, was du mir da erklärst. Danke!
Es beschreibt genau, was ich da beobachtete und vermutete.
Schon mit Linux hatte ich meine Probleme, die ersten Versionen die ich nutzte, kannten ladbare Module noch fast gar nicht und es war sonnenklar, daß ein Kernel mit entsprechenden Optionen neu gebaut werden mußte, wenn denn eine neue Funktion realisiert werden wollte. Mit den damals verfügbaren 386er und 486er CPUs immer eine eine Angelegenheit für die Nacht. Das Konzept der ladbaren Module, zur Laufzeit ladbaren Module, erkannte ich als große Verbesserung, aber seither dies möglich wurde, verstand ich auch nicht mehr genug von der Materie, mir noch einen Kernel selbst kompilieren zu lassen, der dann auch funktionieren konnte. DIe Anzahl der Entscheidungen überforderte mich.
Zurück zu FreeBSD.
Wenn ich das recht verstanden habe, kommt mein GENERIC mit sehr viel fest eingebauten Modulen daher. Deshalb kann er fast alles, ohne daß ich jedesmal einen Kernel neu bauen muß. Zusätzlich gibt es die Möglichkeit, Module nachzuladen, wenn diese nicht schon fest verdrahtet sind.
In meinem Fall gelingt es nicht, auch nicht, wenn mittels kldxref der Kernel Linker die entsprechende Information erhält, wie und wo er das neue Moduel finden kann, denn der Kernel ist so kompiliert, daß er das alte Modul als fest verdrahtet beinhaltet.

Nun hätte ich, wenn ich das recht verstanden habe, folgende Möglichkeiten:

-einen Kernel bauen, in dem KEIN Modul ath... enabled wird und dann dieses manuell (automatisiert) durch den Kernel Linker nachladen lassen. Damit hätte ich später die Möglichkeit, durch Austausch des Moduls direkt eine neuere Version einbauen zu können, ohne wieder einen Kernel neu bauen zu müssen.
-einen neuen Kernel bauen mit unveränderten Optionen, also auch mit dem Modul ath... fest verdrahtet, nur diesmal die neuere Version in den /sys Dateien eingebaut, so daß sich hier also automatisch das neue Modul fest einbauen würde. (Es ist kein drittanbieter Modul, sondern eine neuere Version des FreeBSD Moduls).

Wenn ich das richtig verstanden habe, scheinen mir die Vorteile der ladbaren Module ebenfalls offensichtlich und die derzeitige Handhabung ein wenig unverständlich. Die Module sind eh alle vorhanden, ein GENERIC könnte sehr klein bleiben und eine GNERIC-loader.conf dann trotzdem alles laden, was vorgesehen ist und würde unglaublich Bedienerfreundlich sein, verglichen mit dem Aufwand, einen Kernel neu bauen zu lassen.

 

[pit234a]

mit diesem neuen Wissen habe ich nun tatsächlich mal einen Kernel auf dem fraglichen Rechner gebaut, in dem ich sehr vieles weggelassen habe, das ich dann direkt wieder in der /boot/loader.conf eingetragen habe, damit dann die Module entsprechend trotzdem geladen werden.
Nachdem das funktioniert hatte, bekam ich auch wie erwartet die gleiche Fehlermeldung zu meiner Wlan Karte, was aber hier unwichtig ist, das gehört dann in einen neuen Thread. Es geht mir um den Tausch der Module.
Also, nachdem der Kernel neu gebaut war und ohne die feste Verdrahtung des entsprechenden Moduls, konnte ich dieses durch einen Eintrag in der /boot/loader.conf laden.
kldstat zeigt es mir nun auch an, wie erwartet.
Nun nahm ich das Modul, das nach der Anleitung oben gebaut worden war (ich hatte es noch gespeichert, es ist aber auch kein großer Akt, das wieder neu zu machen) und kopierte es nach /boot/kernel (wo nun mein neuer Kernel drin ist). Damit überschrieb ich das alte Modul und nach einem Neustart war nun tatsächlich eine Änderung zu sehen, die ich gleich zeigen will. Ich bin sicher, daß ich auch hätte mit kld(un)load das neue Modul laden, ein Neustart war mir aber lieber.
Wie gesagt, leider hilft es immer noch nicht, meine Karte zu unterstützen.

mit altem Modul:

ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
ath0: <Atheros 5424/2424> mem 0xf0000000-0xf000ffff irq 18 at device 0.0 on pci5
ath0: cannot map register space
device_attach: ath0 attach returned 6

mit neuem Modul:

ath_hal: 0.11.1.3 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417)
ath0: <Atheros 5424/2424> mem 0xf0000000-0xf000ffff irq 18 at device 0.0 on pci5
ath0: cannot map register space
device_attach: ath0 attach returned 6

Ein kldxref war nicht nötig gewesen, denn es ist der gleiche Modulname, nur mit neuem Inhalt versehen und somit entsteht kein Problem mit dem Linker, weil er ja nichts neues finden mußte.

Auf diese Weise kann also leicht eine Veränderung durch bloßen Tausch der Module herbeigeführt werden. Die Handhabung scheint mir deutliche Vorteile zu haben.

Wegen meiner Eingangsfrage kann ich noch erklären, daß ein gleiches Modul unter amd64 gebaut deutlicher größer wird, als mit i386 und somit sicher nicht austauschbar ist. Wie und ob überhaupt auf einem amd64 für i386 Module gebaut werden können, weiß ich nicht.
DIe Module, die ein i386er baute, waren aber identisch und austauschbar zu einem anderen i386er.

 

[Yamagi]

Wegen meiner Eingangsfrage kann ich noch erklären, daß ein gleiches Modul unter amd64 gebaut deutlicher größer wird, als mit i386 und somit sicher nicht austauschbar ist. Wie und ob überhaupt auf einem amd64 für i386 Module gebaut werden können, weiß ich nicht.

Ein Modul für amd64 muss größer werden, da diverse Strukturen im Modul 64 Bit belegen und nicht 32 Bit. Ist ganz normal. Austauschen untereinander geht auch nicht, da eine i386-CPU gar keinen amd64-Befehle verarbeiten kann, aus welchen das Modul aber besteht. Das gilt auch, wenn die CPU amd64-kompatibel ist, du dies aber nicht nutzt, da du ein FreeBSD/i386 auf ihr betreibst. Umgekehrt wäre es theoretisch möglich, amd64 kann i386-Befehle verarbeiten. Unter Linux kann man daher mit ein wenig frickeln i386-Module unter amd64 laden, nVidia steht im Verdacht das für ihren Grafiktreiber zu nutzen. FreeBSD kann soetwas allerdings nicht, da es bis jetzt nicht nötig war.
Innerhalb einer Architektur kann man übrigens beliebig austauschen. Sprich, ein i386-Modul läuft unter jedem FreeBSD/i386. Dabei muss man aber die Versionen berücksichtigen. Zwischen Hauptversionen ist das Austauschen gefährlich, das Laden eines FreeBSD 6 Moduls unter FreeBSD 7 kann zum Absturz führen. 8.0 wird daher Mechanismen haben, die vor dem Laden sicherstellen, dass das Modul auch passt. Innherhalb einer Version sollte es komaptibel bleiben. Sprich, dein unter FreeBSD 7.0 gebautes Modul wird auch unter 7.2 noch laufen. "Sollte" schreibe ich, da es Ausnahmen gibt. 7.0 hatte so zum Beispiel einen Fehler in der internen Verarbeitung von auf Datenträgern gespeicherter Daten, ihn zu beheben erzwang einen Bruch der Modulschnittstelle. Alte Module laufen zwar noch, aber sie haben den Fehler. Daher muss man entsprechende Module an dieser Schnittstelle neu bauen, in der Praxis ist das für die meisten Personen "fuse.ko" aus den Ports.
Unter Linux - und das muss hier noch einfach rein - ist das ganze noch viel übler. Linux Modulhandling ist durch den Aufbau des Linuxkernel viel "primitiver" als FreeBSD. Dort kann schon das simple Neukompilieren des Kernels ausreichen, dass Module nicht mehr sauber funktionieren.

ich selbst nutze übrigens alles als Modul, da es mir unter Umständen Ausfallzeiten erspart. Die Kernelkonfiguration dazu (FreeBSD/amd64 7.0) ist:

# Allgemein -- CPU
machine		amd64
cpu		HAMMER
ident		SCREW
options		SMP

# Allgemein -- Options
options         SCHED_ULE
options         INET
options         INET6
options		IPSEC
options		SCTP
options         KBD_INSTALL_CDEV
options         ADAPTIVE_GIANT
options         PREEMPTION
options		STOP_NMI
options		KTRACE
options		AUDIT
options		KSE
options		PRINTF_BUFR_SIZE=256

# Allgemein -- Dateisysteme

# UFS2
options		FFS
options		SOFTUPDATES
options		UFS_ACL
options		UFS_DIRHASH
options		QUOTA
options         UFS_EXTATTR
options         UFS_EXTATTR_AUTOSTART

# Allgemein -- Kompatiblität
options		COMPAT_FREEBSD4
options         COMPAT_FREEBSD5
options		COMPAT_FREEBSD6
options		COMPAT_43TTY
options		COMPAT_IA32
options         _KPOSIX_PRIORITY_SCHEDULING
options         SYSVSHM 
options         SYSVMSG
options         SYSVSEM

# Hardware -- GraKa
device		vga
device		splash

# Hardware -- Console
device		sc

# Hardware -- Netzwerk
device 		loop
device 		ether
device          bpf

# Hardware -- Pseudodevices
device		pty

# Hardware -- Keyboard
device		atkbdc
device		atkbd

# Hardware -- Controller
device          isa
device		eisa
device		pci
device		acpi

# ALTQ
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queueing
options         ALTQ_RED        # Random Early Detection
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler
options         ALTQ_CDNR       # Traffic conditioner
options         ALTQ_PRIQ       # Priority Queueing
options         ALTQ_NOPCC      # Required for SMP build

# Serielle Schnittstelle
device		uart
device          uart_ns8250

# Crypto fuer IPSEC
device		crypto

# Kein reboot bei strg-alt-entf
options		SC_DISABLE_REBOOT

was mit einer angepassten /boot/loader.conf kombiniert wird. Hier die meiner Workstation:

# Loader
autoboot_delay="3"

# Treiber
# -------

# Partitionstypen
geom_bsd_load="YES"
geom_mbr_load="YES"

# Label
geom_label_load="YES"

# Random
random_load="YES"

# Zlib
zlib_load="YES"

# Crypto
crypto_load="YES"

# ATA
ata_load="YES"
atapci_load="YES"
atadisk_load="YES"

# X11 Kram
mem_load="YES"
io_load="YES"

# SCSI
cam_load="YES"
atapicam_load="YES"

# Firewire
firewire_load="YES"

# NFS
nfsclient_load="YES"
nfsserver_load="YES"

# Netzwerk
miibus_load="YES"
if_em_load="YES"
if_nfe_load="YES"

# SMBus
smbus_load="YES"
nfsmb_load="YES"

# Parallelport
ppbus_load="YES"
ppc_load="YES"

# CPUFreq
cpufreq_load="YES"

# Sound
sound_load="YES"
snd_spicds_load="YES"
snd_envy24ht_load="YES"
snd_ich_load="YES"

# GELI
geom_eli_load="YES"

# PF
pf_load="NO"
pflog_load="NO"

# Diskette
fdc_load="YES"

# CPU-Device
cpu_load="YES"

# USB
usb_load="YES"
ums_load="YES"
umass_load="YES"
ukbd_load="YES"
uwacom_load="YES"

# Linux
linux_load="YES"

# Keyboard
kbdmux_load="YES"

# Fuse
fuse_load="YES"

# Brücke
if_bridge_load="YES"

# Tap
if_tap_load="YES"

# KQemu
kqemu_load="YES"

# Aio
aio_load="YES"

# Temperatursensoren
k8temp_load="YES"

# Tun
if_tun_load="YES"

EDIT: Man kann Module "crosscompilen", also z.B. für i386 bauen, obwohl man selbst unter amd64 ist. Geht per "make TARGET_ARCH=i386".

 

[Yamagi]

Aber um mal zu deinem Problem zu kommen:

ath0: cannot map register space
device_attach: ath0 attach returned 6

Das bedeutet, dass der Treiber nicht den Speicher bekommt, welchen er haben will. Dazu gibt es zwei Erklärungen. Einmal das dein BIOS Mist baut. In dem Fall hilft dort eine Aktualisierung oder einfach mal die Karte in einen anderen Steckplatz stecken, falls möglich. Die andere Möglichkeit ist, dass ein anderer Treiber dort im Weg ist. Ein ganz klassischer Kandidat ist dort nvidia.ko, er blockiert z.B. auch sehr gern Diskettenlaufwerke. Sodenn man überhaupt noch eins hat.

 

[pit234a]

ath0@pci0:5:0:0:        class=0x020000 card=0x3065168c chip=0x001c168c rev=0x01 hdr=0x00
    vendor     = 'Atheros Communications Inc.'
    device     = 'AR5006 family 802.11abg Wireless NIC'
    class      = network
    subclass   = ethernet

das ist so die einzige Information, der einzige Hinweis, den ich habe, weshalb es vielleicht nicht gelingt, denn diese Karte ist für den ath_hal: 0.11.1.3 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) eben nicht aufgelistet.
An das Bios des Laptops komme ich nicht ran und kann damit nichts probieren. Das ist vielleicht auch gut so, denn ich wollte nie Wlan nutzen und bin nur neugierig geworden, ob es nicht laufen könnte.
Der Chip ist eingebaut und ich kann den Steckplatz nicht tauschen und weiß auch nicht, wie ich einen IRQ ändern könnte und vermutlich wird das auch nichts bringen.
Bei meiner Suche im Web zeigte sich bei einigen Usern mit einer solchen Karte, daß mit neuem at_hal.ko die Karte sauber eingebunden wurde. Die Fehlermeldungen sahen meist anders aus, waren aber in einem Fall zunächst identisch. Nachdem die Betroffenen es geschaft hatten, ein neues Modul einzubauen, hatten sie dann offensichtlich Erfolg.
Doch wie gesagt, das war nun für mich nur ein Aufhänger und ich werde vermutlich nicht allzuviel darin investieren, das nun zu ändern.

Interessanterweise sieht zwar meine kernconf und meine loader nun ganz ähnlich aus, wie bei dir, doch einige Dinge habe ich genau anders entschieden. Bei einigen, weiß ich natürlich nicht, wofür die mal gut sein werden, aber so kann ich doch schön damit spielen. Das erscheint mir wirklich ein großer Vorteil.
Erstaunt bin ich, daß du nfs als Kernel-Modul lädst. Das kenne ich so von Linux, dachte aber, daß es bei FreeBSD genau nicht so realisiert wäre, sondern eine extra Software später geladen wird.
agp habe ich auch in die loader genommen, weil mir aufgefallen ist, daß da viele Unetrmodule geladen werden und ich hoffte, daß ich da mal was dran drehen könnte um nur noch die benötigten zu laden. Nun dauert das entsprechend ein wenig, bis die durchgeladen ist.

Also, das war für mich heute wirklich erigiebig, auch ohne Wlan. Danke.

 

[pit234a]

PS, noch ein Nachsatz: FreeBSD läuft auf diesem Laptop vom Stick. Auf einem anderen Stick kann ich ein SuSE Linux booten, das ja bekannt dafür ist, so ziemlich alles zu können. Es erkennt auch die Atheros Karte und kann sie auch nicht einbinden.

 

[iceberg101971]

Hi Yamagi,
auch wenn der Beitrag schon älter ist,habe ich dennoch ne Frage. Woher bekomme ich alle Informationen und Beschreibungen zu den Kernelmodulen und allen Optionen die ich einstellen kann? Zum Beispiel ist mir die Option "SC_DISABLE_REBOOT" völlig neu.

ICE-B

 

[steinex]

Hi Yamagi,
auch wenn der Beitrag schon älter ist,habe ich dennoch ne Frage. Woher bekomme ich alle Informationen und Beschreibungen zu den Kernelmodulen und allen Optionen die ich einstellen kann? Zum Beispiel ist mir die Option "SC_DISABLE_REBOOT" völlig neu.

ICE-B

SC_DISABLE_REBOOT ist eigentlich nicht neu.

Siehe /usr/src/sys/i386/conf/NOTES bzw. /usr/src/sys/amd64/conf/NOTES bzw. /usr/src/sys/conf/NOTES