Urządzenia PCI są w większości samo-konfigurujące się - komputer i
system operacyjny przydzielą kartom niezbędne zasoby.
Przerwania mogą być współdzielone na szynie PCI.
Ponadto, system często lepiej się zachowuje, gdy przerwania (IRQs)
są współdzielone, zwłaszcza na architekturach i386.
Istnieje wiele rożnych standardów szyn PCI.
Czasami spotkasz się z kartami o specyfikacji PCI2.2, które
nie będą działać z systemami o specyfikacji PCI2.1. Co więcej,
wiele kart z wbudowanymi szynami (takich jak, wieloportowe
karty sieciowe) nie będzie poprawnie działać na starszych systemach.
Szyna PCI wspiera dwa poziomy sygnałów, 3.3v i 5v.
Karty, które działają z sygnałami 3.3v mają drugie wcięcie
w swoim złączu krawędziowym PCI. Większość kart PCI używa
sygnałów 5v, które są wykorzystywane przez większość komputerów.
Zintegrowane komputery Soekris (Net45x1 i Net4801) są przykładem
często spotykanych konstrukcji, które obsługują jedynie sygnały 3.3v.
12.1.2 - Urządzenia ISA
Urządzenia ISA nie mogą współdzielić zasobów. Ogólnie, muszą być
ręcznie konfigurowane w taki sposób, aby nie było konfliktów
z innymi urządzeniami w systemie.
Niektóre urządzenia ISA są zgodne z "Plug and Play"
(isapnp(4))
- mimo to, jeśli wystąpią jakiekolwiek problemy z tymi urządzeniami, sprawdź
ich ustawienia w
dmesg(8),
ISAPnP nie zawsze działa tak, jak się tego oczekuje.
Ogólnie, jeśli istnieje możliwość wyboru, zaleca się unikanie kart
ISA na rzecz PCI. Karty ISA są trudniejsze w konfiguracji i mają
dużo większy, negatywny wpływ na wydajność systemu.
12.1.3 - Urządzenie jest "rozpoznawane" ale dmesg
wyświetla przy nim komunikat: "not configured"
Krótko mówiąc, twoje urządzenie nie jest obsługiwane przez jądro
którego używasz i dlatego nie możesz go uruchomić.
PCI i wiele innych typów urządzeń dostarcza o sobie informacje, dzięki
czemu OS może je poprawnie rozpoznać i obsłużyć.
Dodanie rozpoznawania sprzętu jest proste, jego obsługa często nie.
Poniżej znajduje się wycinek z dmesg zawierający dwa "nieskonfigurowane"
urządzenia:
...
vendor "Intel", unknown product 0x5201 (class network subclass ethernet,
rev 0x03) at pci2 dev 9 function 1 not configured
...
"Intel EE Pro 100" rev 0x03 at pci2 dev 10 function 0 not configured
...
W pierwsze z nich urządzenie posiada rozpoznany kod producenta.
Rozpoznany został także ogólny typ urządzenia (urządzenie sieciowe)
lecz nie jego konkretny model.
Drugie urządzenie także jest kartą sieciową, jednak tym razem
karta ta była już wcześniej zidentyfikowana przez twórców jądra,
a dokładne informacje o niej zostały wpisane do pliku identyfikującego
urządzenia.
Niemniej, w obu przypadkach urządzenia nie będą działały, ponieważ
oba są wylistowane jako "not configured", co oznacza że
w tej chwili nie system nie przydzielił im żadnego sterownika.
Co mogę zrobić z urządzeniami wylistowanymi jako not configured?
Jeśli nie potrzebujesz danego urządzenia, możesz bezpiecznie
zignorować ten komunikat ("not configured"), nie ma to żadnego negatywnego
wpływu na twój system.
Niektóre urządzenia "specjalnego przeznaczenia" są celowo pozostawione
jako nieskonfigurowane aby mógł się o to zatroszczyć BIOS.
W niektórych przypadkach, jest to po prostu jakaś odmiana
już wspieranego urządzenia, wówczas byćmoże napisanie
wspierającego je sterownika przez developera będzie relatywnie proste.
Może to także być zupełnie nowy układ lub implementacja
(tak jak powyższe przykłady).
W takim wypadku, niezbędne będzie napisanie nowego sterownika,
co może okazać się niemożliwe jeśli urządzenie nie jest w pełni
udokumentowane. Napisanie własnego sterownika dla takiego
urządzenia jest bardzo mile widziane.
Jeśli korzystasz z jądra instalacyjnego, urządzenie może
nie być wkompilowane do danego jądra, lecz może znajdować się
na innym nośniku boot`owalnym z innym zestawem sterowników.
Często zdarza się, że użytkownicy popularnych kontrolerów SCSI
którzy nie doczytali przypisów na stronie platformy
próbują wszystkich boot`owalnych obrazów dyskietek poza tą właściwą,
na której znajduje się sterownik ich kontrolera SCSI.
Jeśli korzystasz ze zmodyfikowanego jądra, możliwe, że usunąłeś
wsparcie dla urządzenia którego teraz potrzebujesz.
Ogólnie, usuwanie urządzeń z kernela jest
złym pomysłem.
Choćby z tego jednego powodu.
Zanim zgłosisz urządzenie oznaczone jako "not configured",
upewnij się że przetestowałeś je na najnowszym
snapshot`cie, ponieważ byćmoże obsługa
twojego urządzenia została już wprowadzona oraz przeglądnij
archiwa list mailingowych
aby sprawdzić czy problem ten został już omówiony.
Trzeba pamiętać, że jeśli korzystasz ze starszej wersji OpenBSD,
będziesz musiał zaktualizować system, aby korzystać z jakiegokolwiek
nowo napisanego sterownika.
12.1.4 - Moja karta jest wylistowana jako obsługiwana,
mimo to nie działa!
Niestety, wielu producentów używa numerów modeli jako oznaczeń
rynkowych przeznaczenia produktu, zamiast ich technicznej natury.
Dlatego też możesz zakupić produkt z taką samą nazwą lub numerem modelu
jak w liście obsługiwanego sprzętu dla twojej platformy i mimo to może on być nieobsługiwany przez OpenBSD.
Na przykład, wiele wczesnych urządzeń sieci bezprzewodowej było
opartych o układ Prism2, obsługiwany przez sterownik
(wi(4)),
lecz później, gdy tańsze układy stały się dostępne, wielu producentów
zaczęło wykorzystywać układy dla których nie ma sterowników open source,
nie zmieniając nigdy swoich numerów modelu.
Niestety, urządzenia sieci bezprzewodowej nie są jedynym przykładem
takich praktyk.
12.1.5 - Czy tzw WinModemy są obsługiwane?
WinModems są tanimi modemami które większość swojego przetwarzania
sygnałów o główny procesor systemu zamiast przetwarzać je sprzętowo
jak robią to "prawdziwe" modemy. Z powodu różnorodności niekompatybilnych
i zwykle nieudokumentowanych układów WinModem`ów, nie ich ma obsługi
w OpenBSD i najprawdopodobniej nie ulegnie to zmianie.
12.1.6 - Co stało się ze wsparciem dla Adaptec RAID (aac)?
Firma Adaptec odmówiła dostarczenia użytecznej i ścisłej dokumentacji do
swoich opartych na FSA
(aac(4))
kontrolerów RAID.
Jako że te kontrolery wydają się być bardzo zapluskwione, dokumentacja ta jest
krytyczna do stworzenia użytecznych sterowników.
Od momentu w którym ten sterownik stał się tak niepewny, został usunięty z jądra
GENERIC.
Mogę skompilować własne jądro z obsługą aac(4), prawda?
Pewnie.
Ale jakiej części "niepewny" nie zrozumiałeś?
To nie jest "eksperymentalna" cecha, tylko dobrze znany niesolidny sterownik.
Być może działa z niektórymi wariacjami sprzętu wystarczająco dobrze by
go używać, jednak nie polecamy trzymania na nim twoich danych.
12.1.7 - Moja karta ami(4) obsługuje tylko jeden dysk logiczny!
Istnieje znany błąd w
ami(4)
powodujący uszkodzenie danych jeżeli korzystasz z więcej niż jednego napędu na
niektórych kontrolerach.
Dla tych kontrolerów OpenBSD włącza ograniczenie do jednego dysku logicznego, co
powoduje pojawienie się mniej więcej takiego komunikatu w dmesg:
ami0: FW A.04.03, BIOS vA.04.03, 4MB RAM
ami0: 3 channels, 16 targets, 2 logical drives
ami0: firmware buggy, limiting access to first logical disk
scsibus0 at ami0: 1 targets
12.2 - DEC Alpha
[jeszcze nic tu nie ma]
12.3 - AMD 64
12.3.1 - Czy mogę uruchomić OpenBSD/amd64 na moim Intel P4
W przypadku wielu nowych procesorów odpowiedź brzmi "tak".
Niestety znalezienie odpowiedzi na pytanie o które modele procesorów Intel
chodzi oraz które nie obsługują poprawnie instrukcji amd64, jest raczej
trudne i zazwyczaj łatwiej jest po prostu sprawdzić czy na danym działa.
12.3.2 - Czy mogę używać binarek i386 na OpenBSD/amd64?
No.
OpenBSD/amd64 jest zupełnie inna platformą niż OpenBSD/i386 i obecnie
nie jest dostarczana żadna kompatybilność binarna.
Biorąc pod uwagę, że OpenBSD skupia się na wolnych aplikacjach ("open source"),
nie istnieje wyraźna potrzeba na zapewnienie takiej kompatybilności.
Zauważ że programy ładujące dla OpenBSD/amd64 oraz OpenBSD/i386
pozwalają na zamienne ładowanie systemów (od OpenBSD 4.2),
dzięki czemy łatwiej można przeładować system na "inna" platformę.
Jednakże wymaga to pełnego wymazania i restartu -- pozostanienie
programów binarnych z "poprzedniej" instalacji sprawi że twoje życie stanie
się zdecydowanie nieprzyjemne.
12.3.3 - Czy zawsze lepiej jest używać OpenBSD/amd64 na procesorach które
obsługują amd64?
Nie zawsze.
Istnieje kilka powodów dla których niektórzy wolą używać OpenBSD/i386
zamiast OpenBSD/amd64, nawet jeżeli sprzęt obsługuje kod amd64:
Potrzebna jest kompatybilność z i386 (lub z innym systemem operacyjnym).
Potrzebne są aplikacje które nie są "64 bit clean".
Potrzebna jest możliwość przeniesienia systemu na inną maszynę.
Dla niektórych aplikacji oraz niektórych urządzeń, wydajność w OpenBSD/i386
jest wyższa niż w OpenBSD/amd64.
Relatywnie niewiele osób może doświadczyć podobnych sytuacji, trwają także prace
nad eliminacją podobnych zachowań.
12.4 - Urządzenia operta na ARM
[jeszcze nic tu nie ma]
12.5 - HP300
[jeszcze nic tu nie ma]
12.6 - HPPA
[jeszcze nic tu nie ma]
12.7 - i386
12.7.1 - Karty sieciowe ISA
OpenBSD dobrze obsługuje starszy sprzęt, a użytkownicy są często
zmuszeni korzystać z kart sieciowych ISA na tych maszynach.
Sprzęt ISA wymaga dużo więcej konfiguracji i zrozumienia tematu, niż
sprzęt PCI. Ogólnie, nie można po prostu wcisnąć takiej karty do
komputera i oczekiwać, że w jakiś magiczny sposób zacznie ona działać.
W wielu systemach, gdzie urządzenia ISA nie są zgodne z standardem
"Plug 'n' Play" (PNP), trzeba samodzielnie zarezerwować w BIOS-ie
zasoby wykorzystywane przez kartę.
3Com 3C509B ep(4)
Jest to bardzo wydajna karta sieciowa ISA obsługiwana przez sterownik
ep(4).
Wersja 'B' może być rozróżniona od wersji nie-B po napisach na karcie
i większym "głównym" chip-ie (około 2.5 cm w przypadku wersji 'B' i
2 cm w przypadku starszych wersji), oraz lepszej wydajności w obciążonym
lub posiadającym dwie karty sieciowe systemie.
Model 3C509B dostarczany jest z włączonym trybem PNP, który niestety
nie odpowiada standardom i powoduje problemy z obsługą
isapnp(4).
Urządzenie jest najpierw rozpoznawane jako nie obsługujące PNP, a następnie,
gdy obsługa PNP jest uaktywniana, powoduje wyświetlanie dodatkowej karty
sieciowej w dmesg.
Wszystko może działać poprawnie, ale może to także powodować inne problemy.
Zaleca się, aby przed konfiguracją karty 3C509B na OpenBSD, wyłączyć jej
tryb PNP i ręcznie skonfigurować bezkonfliktowe ustawienia przy pomocy
DOS'owego programu konfiguracyjnego 3Com.
Sterownik ep(4) rozpoznaje karty w każdej konfiguracji sprzętowej,
która nie rodzi konfliktów z innymi urządzeniami w systemie.
Jeśli masz wiele kart 3C509 w swoim systemie, zaleca się oznaczenie
"grzbietu" kart adresem MAC, i wykorzystanie dmesg do ich rozróżnienia.
Warto zauważyć, że modele 3C509, 3C905 i 3C590 są często mylone.
Model 3C509 to 10Mbitowa karta ISA, 3C905 i 3C590 to karty PCI.
NE2000
Oryginalna karta sieciowa NE2000 została opracowana przez Novell w połowie
lat osiemdziesiątych. Od tego czasu, wielu producentów wypuściło na
rynek bardzo podobne karty, ogólnie nazywane "kompatybilnymi z NE2000" lub
klonami. Ich wydajność jest bardzo zróżnicowana. Podczas gdy
wiele z starszych, kompatybilnych z NE2000 kart miało dobrą wydajność,
większość z obecnie dostępnych klonów sprawuje się dużo gorzej.
Karty kompatybilne z NE2000 są obsługiwane w OpenBSD przez sterownik
ne(4).
OpenBSD poradzi sobie z obsługą niektórych kart kompatybilnych z
NE2000 z włączonym trybem ISAPNP. Inne karty należy skonfigurować
używając albo zworek, albo DOS'owych narzędzi konfiguracyjnych.
Niestety, ponieważ oryginalne karty NE2000 nie miały możliwości
konfiguracji za pomocą oprogramowania, ani wsparcia dla ISAPNP,
nie ma w tym względzie standardów - niezbędne jest narzędzie,
które jest dedykowane danej karcie. Często trudno jest je zdobyć.
Sterownik ne(4) obsługuje trzy konfiguracje kart ISA NE2000 w
jądrze GENERIC:
ne0: port 0x240 irq 9
ne1: port 0x300 irq 10
ne2: port 0x280 irq 9
Jeśli ustawienia te nie są do zaakceptowania, możesz dostroić je przy pomocy
Konfiguracji jądra podczas startu systemu
lub zbudowanie własnego jądra.
Warto zwrócić uwagę, że sterownik ne(4) jest dość "głupi" - jedynie port I/O
jest sprawdzany, jeśli którykolwiek z powyższych adresów I/O jest wykryty,
domyślnie zakładane jest odpowiadające mu IRQ.
dmesg(8)
nie odzwierciedli prawdziwego IRQ urządzenia sieciowego w przypadku sterowników
ISA ne(4). Jeśli nie jest to prawdziwe IRQ, które jest przydzielone karcie,
nie będzie ona działać.
Istnieją karty nie-ISA, które korzystają ze sterownika ne(4) - karty
PCI i PCMCIA. Powyższe notatki nie odnoszą się do nich, ponieważ karty
te są konfigurowane automatycznie.
12.7.2 - OpenBSD nie chce się uruchomić na moim 80386/80386SX/80486SX!
80386SX/DX
W OpenBSD 4.2 zostało zarzucone wsparcie dla procesorów 80386DX oraz 80386SX.
Poza ograniczeniami układów 80386, systemy na nich oparte są po prostu zbyt
powolne, posiadają relatywnie mało pamięci RAM, oraz brak FPU wymaganego do
pracy z OpenBSD.
80486SX
Układ 80486SX jest "niskobudżetową" wersją procesora 80486, pozbawioną
koprocesora matematyczne (podobnie jak 80386), który wymagany jest przez
OpenBSD. Na szczęście w przypadku większości komputerów istnieje prosty
sposób na zamianę zubożonego procesora na jego pełną wersję 80486DX.
Układy 80486DX, oraz nowsze, powinny działać bez problemów z OpenBSD.
12.7.3 - Mój dmesg pokazuje, że wiele urządzeń współdzieli to samo
przerwanie (IRQ)!
Jest to całkowicie dopuszczalne, a nawet zalecane w przypadku urządzeń PCI.
Jest to zaprojektowana własność szyny PCI. Wielu powie, że współdzielenie
wywołań przerwań jest czymś złym, jednak
osoby te albo mylą sytuację z szynami ISA (gdzie współdzielenie przerwań
nie jest dozwolone), albo miały w przeszłości doświadczenia ze źle działającym
sprzętem lub oprogramowaniem.
Urządzenia ISA nie mogą współdzielić przerwań. Jeśli spotkasz się z
urządzeniami ISA, które współdzielą przerwania, musisz to poprawić.
12.7.5 - Moja klawiatura/myszka blokują się
(albo zachowują się w nieoczekiwany sposób)
Ten problem występuje najczęściej gdy wykorzystywane są przełączniki
(czasem nazywane "przełącznikami KVM") służące do podłączenia jednego
monitora, klawiatury i myszki do wielu
komputerów. Można eksperymentować z przełącznikami różnych producentów
jednak OpenBSD wydaje się bardziej wrażliwy na przełączanie myszy niż
inne systemy operacyjne. Problemy pojawiają się najczęściej podczas
przełączania myszy pomiędzy komputerami. Jeśli nie używasz myszki
rozwiązanie jest proste: po prostu nie podłączaj kabla do komputera.
Jeśli jednak myszka jest niezbędna najskuteczniejszym sposobem będzie
podłączeniem osobnej myszki do każdego z komputerów, a przełączanie
jedynie klawiatury i monitora.
Może się okazać ze adapter PS/2 Mouse -> USB (tak że OpenBSD zobaczy
mysz USB) rozwiąże twój problem.
Jeśli niezbędny jest tylko dostęp do
konsoli wygodne może okazać się skorzystanie z
konsoli szeregowej.
12.7.6 - Czy tzw WinModem`y są obsługiwane?
WinModems są tanimi modemami które większość swojego przetwarzania
sygnałów o główny procesor systemu zamiast przetwarzać je sprzętowo
jak robią to "prawdziwe" modemy. Z powodu różnorodności niekompatybilnych
i zwykle nieudokumentowanych układów WinModem`ów, nie ich ma obsługi
w OpenBSD i najprawdopodobniej nie ulegnie to zmianie.
12.7.7 - Co stało się ze wsparciem dla Adaptec RAID (aac)?
Firma Adaptec odmówiła dostarczenia użytecznej i ścisłej dokumentacji do
swoich opartych na FSA
(aac(4))
kontrolerów RAID.
Jako że te kontrolery wydają się być bardzo zapluskwione, dokumentacja ta jest
krytyczna do stworzenia użytecznych sterowników.
Od momentu w którym ten sterownik stał się tak niepewny, został usunięty z jądra
GENERIC.
Mogę skompilować własne jądro z obsługą aac(4), prawda?
Pewnie.
Ale jakiej części "niepewny" nie zrozumiałeś?
To nie jest "eksperymentalna" cecha, tylko dobrze znany niesolidny sterownik.
Być może działa z niektórymi wariacjami sprzętu wystarczająco dobrze by
go używać, jednak nie polecamy trzymania na nim twoich danych.
12.7.8 - Moja karta ami(4) obsługuje tylko jeden dysk logiczny!
Istnieje znany błąd w
ami(4)
powodujący uszkodzenie danych jeżeli korzystasz z więcej niż jednego napędu na
niektórych kontrolerach.
Dla tych kontrolerów OpenBSD włącza ograniczenie do jednego dysku logicznego, co
powoduje pojawienie się mniej więcej takiego komunikatu w dmesg:
ami0: FW A.04.03, BIOS vA.04.03, 4MB RAM
ami0: 3 channels, 16 targets, 2 logical drives
ami0: firmware buggy, limiting access to first logical disk
scsibus0 at ami0: 1 targets
12.8 - Landisk
[jeszcze nic tu nie ma]
12.9 - Luna88k
[jeszcze nic tu nie ma]
12.10 - Mac68k
[jeszcze nic tu nie ma]
12.11 - MacPPC
12.11.1 - Dlaczego sterownik bm(4) jest powolny?
Sterownik
bm
obsługujący chip BMAC obecny w niektórych komputerach MacPPC (włączając w to
wczesne wersje iMaca) posiadają problem objawiający się podczas pracy w
trybie 100 Mbps. Zalecane jest wymuszenie pracy w trybie 10 Mbps przez
użycie opcji "media 10baseT" w pliku /etc/hostname.bm0
lub wymuszenie trybu 10 Mbps w hubie lub switchu.
12.12 - MVME68k
[jeszcze nic tu nie ma]
12.13 - MVME88k
[jeszcze nic tu nie ma]
12.14 - SGI
[jeszcze nic tu nie ma]
12.15 - SPARC
[jeszcze nic tu nie ma]
12.16 - UltraSPARC (sparc64)
12.16.1 - Mój UltraSPARC nie chce się uruchamiać z obrazu dyskietki
Jedynie Ultra 1/1e i Ultra 2 mogą uruchamiać jakikolwiek system
operacyjny z dyskietki. Skorzystaj zamiast tego z CD-ROM'u, Miniroot lub
bootowania po sieci, aby przeprowadzić instalację.
12.16.2 - Otrzymuję komunikaty "partition extends past end of unit"
w disklabel
W systemach sparc i sparc64 disklabel BSD nie może opisać geometrii dysku
większego niż 8GB, podczas gdy pojedyńcze wpisy w disklabel mogą być większe.
Za każdym razem gdy uruchamiasz disklabel(8), wykonuje on testy stanu wpisów
w disklabel, określając geometrię dysku i w momencie gdy zauważy okrojoną geometrię
zostaniesz ostrzeżony a disklabel(8) nie pozwoli ci edytować wpisów przekraczających
8GB, o ile nie nakażesz korzystanie z prawdziwej geometri dysku.
Możesz to zrobić korzystając z polecenia "g" w powłoce poleceń
disklabel(8) i włączyć korzystanie z
"geometrii [d]ysku":
# disklabel -E wd0
# Inside MBR partition 3: type A6 start 63 size 17912412
[...]
Initial label editor (enter '?' for help at any prompt)
> g
[d]isk, [b]ios, or [u]ser geometry: [d] d
> w
> q
Wciąż będą się pojawiały ostrzeżenia, jednak będziesz mógł korzystać ze swojego
dysku zgodnie z twoimi potrzebami.
Poprawne rozwiązanie tego problemu powinno być kompatybilne z obecnie wykorzystywanymi
systemami i dodatkowo powinno być kompatybilne z Solaris-em działającym na dyskach
większych niż 8GB, jednak nie podjęto jeszcze takich prac.
12.17 - DEC VAX
12.17.1 - Czy mogę korzystać z symulatora SIMH dla VAX-a?
Tak!
Symulator SIMH VAX
może być wykorzystany do efektywnej emulacji prawdziwego VAX-a.
Instrukcje możesz znaleźć tutaj.
12.18 - Sharp Zaurus
12.18.1 - Urządzenia USB nie działają poprawnie
Zaurus posiada zbyt małą wydajność prądową na portach USB, zatem wiele
urządzeń USB nie bedzie działać poprawnie w sytuacji gdy są wpięte bezpośrednio
w Zaurus'a.
Dla takich urządzeń musisz użyć zasilanego niezależnie hub'a USB.
![[OpenBSD]](../../images/smalltitle.gif){kind=small}
![[wstecz]](../../images/back.gif){kind=small}
www@openbsd.org