Forum Debian Users Gang

Lenny może być niezbyt kompatybilny z kernelami 2.6.39 i wyżej, ponieważ w 2.6.39 zaszły spore zmiany w ACPI.

Radzilbym przeprowadzkę na Squeeze (6.0.3), który ma aktualne wsparcie (Lenny już chyba tylko security-updates), bo prawdopodobnie coś dotyczy ACPI.
Miedzy jajem 2.6.26 z Lennyego, a 3.2 jest trochę duża odległość.
Natomiast Squeeze co prawda bazuje na jaju 2.6.32, ale w backportach ma wersje 2.6.39, i na kernelach 3.x też powinien chodzić.

Edit:
W backportach Squeeze jest też jajo:

linux-image-3.2.0-0.bpo.1-686-pae

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2012-01-27 12:55:26)

Nie myślę, że to ACPI, ale myślę, że to kernel.
A w wersji 2.6.39 i późniejszych były spore zmiany w APCI - które zaobserwowałem u siebie, na 2.6.38 komp chodził, na 2.6.39 tylko z wyłączonym ACPI, wreszcie na 2.6.39.4 ruszył po aktualizacji biosu.

Inne zmiany też były, ale z racji faktu, że z kernelami od 2.6.20.16 do 3.2.2 żadnych większych problemów  poza tym wypadkiem z ACPI nie miałem, myśle, że to możliwe.
Ewentualnie jakieś błędy w sterownikach, lub nieprawidłowa współpraca kernela i userspace.
Bo userspace poza możliwością wywołania kernel-panic, nie ma innych możliwości zawieszania kompa, jeśli nie towarzyszy temu hardcorowy błąd w kernelu.

Co do biblioteki libbluetooth2 , to na 60% bzdura, na 30% lenistwo, a na 10% problem z softem.

Ewentualnie możesz chyba spróbować  skompilować starą bibliotekę, al;bo zainstalować na nowym systemie paczki ze  http://snapshot.debian.org/
Squeeze obsluguje bluetooth bez problemu, włącznie z urządzeniami BT ktore mają kilka lat, także nie czaję argumentu, co to za tajemniczy soft, który jakis idiota zrobil program do max takiej a siakiej wersji biblioteki libbluetooth.
Api bluetooth nie zmienilo się specjalnie.

Co do logów, to po to jest foder /var/log. a w nim pliki syslog i messages, zeby do nich czasem zajrzeć.

Jest też polecenie dmesg - ktore pokazuje logi kernela, i gdzie sa pokazane akcje wszystkich sterowników, acpi, itp.

Np:

root  # dmesg | grep dvb
[    9.224498] cx88/2: cx2388x dvb driver version 0.0.9 loaded
[    9.224502] cx88/2: registering cx8802 driver, type: dvb access: shared

Poza tym popytaj w kontekście kłoptu z wersją libblue* na Squeeze NICA - on jest chyba najlepszym specem od BT na forum, i dobrym hakerem C.

To by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2012-01-27 14:05:26)

Skompilować "avetanaBT" to nie problem, troszkę drobnych poprawek na ich system budowania, troszkę kodu usunąć, zmienić jedną nazwę metody i kompiluje się u mnie. Pytanie tylko czy to działa, ale był bym dobrej myśli.

To było jakoś tak:
{na wstępie zaznaczam że mam x86, 32bit, kernel "prawie" 3.2 i bluez 4.96+; current dir: /src/cvs/avetanabt/ }
1. cvs -z3 -d:pserver:anonymous@avetanabt.cvs.sourceforge.net:/cvsroot/avetanabt checkout avetanabt # lub  paczka z SourceForge: avetanabt-20070719.tgz
2. aclocal
3. autoconf
4. ./configure
5. W "Makefile" hakujemy podając absolutną ścieżkę do katalogu budowania (bo jest niepodana, nie wnikam w ten system budowania; to brudny hak, ale bezpieczny), np.
BIN_DIR        = /src/cvs/avetanabt/avetanabt/build/
6. To samo co w 5. w "c/Makefile"
7. w c/Makefile zmienić kompilator z "g++" na "gcc" (CC             = gcc)
8. w c/Makefile do CFLAGS dodać "-fpermissive" (nie wiem na ile to bezpieczne... ale sam kompilator wprost podał tą flagę przy errorach...  ale to bez znaczenia w sumie... i tak trzeba testować cały produkt (podsystem Bluetooth), tj. albo działa albo nie)
9. wyrzucić z c/sdp_internal.h całą metodę "static inline uint64_t ntoh64(uint64_t n)"
10. w c/ zmienić "hci_local_name" na "hci_read_local_name"
11. make

Z czego po 7. winno się robić 11. i poprawiać to co faktycznie kompilator wywali.

Ostatnio edytowany przez NIC (2012-01-28 02:10:30)