Holla, das nenne ich schnelle Reaktion bei einem Thread, der ja schon eine Weile ruhig war.
Mit Deinem Einwand auf die 32-bit Einschränkung hast Du sicherlich recht. Da der ndiswrapper aber damals auch nur mit den 32-bit Windows-Treibern funktioniert hat und von 64-bit nie die Rade war, bezog sich meine Aussage nur auf 32-bit.
Naja, seit Februar 2006 ging es in diesem Thread ziemlich viel um die 64-Bit-Version, da sind etliche Postings dazu (deshalb bin ich ja auf diesen Thread gekommen, weil Google in mir mit dem Suchwort x86_64 ausgespuckt hat).
Der Support von AVM für Linux ist meiner Meinung nach ziemlich erbärmlich. Umso schlimmer, weil die Fritz!Boxen alle unter Linux laufen. Dass der USB-Stick dann so schlecht unter Linux unterstützt wird, ist schon traurig. Ich sehe auch nicht, dass in Richtung 64bit-nativer Treiber in absehbarer Zeit etwas passieren wird (ich meine mich zu erinnern, dass es von AVM eine Aussage gab, dass nach der 1.0-Version des 32bit-Treibers nicht weiter am Linux-Treiber gearbeitet wird).
Deshalb wäre ja der ndiswrapper so wichtig.
Interessant zu wissen wäre, ob die Probleme auch bei Nicht-SMP-Kerneln auftreten. Ich habe derzeit auf einem Core2Duo natürlich einen SMP-Kernel laufen. Wenn jemand einen Einzel-Prozessor-Kernel benutzt, wäre es interessant zu wissen, ob der USB-Stick dann besser auf x86_64 mit ndiswrapper funktionioniert. Vielleicht kommt ja ein entsprechender Kommentar, dann kann ich mir das Ändern meines Kernels sparen... (bin faul...
).
Meine Erfahrungen sehen so aus:
Hardware: Core2Duo 6300, 2GB Speicher
Distribution: Gentoo 2007.0
Kernel: 2.6.22-r9 SMP x86_64
Ndiswrapper
1.47-1.49
Fritz-Treiber
Vista/XP 64 1.00.04 (06.12.28 ) Englisch
Kommentar
gar keine Funktion
Ndiswrapper
1.46
Fritz-Treiber
Vista/XP 64 1.00.04 (06.12.28 ) Englisch
Kommentar
beim Booten selten gefunden (2 von ca. 50 mal), nach mehrfachem rmmod/modprobe ndiswrapper gefunden, aber häufig Stehenbleiben des Systems, Absturz sieht wie folgt in /var/log/messages aus:
Nov 22 15:29:16 kiel general protection fault: 0000 [1] SMP
Nov 22 15:29:16 kiel CPU 0
Nov 22 15:29:16 kiel Modules linked in: ndiswrapper coretemp it87 hwmon_vid i2c_isa snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_pcm_oss snd_mixer_oss i2c_algo_pca i2c_algo_pcf i2c_algo_bit ntfs pata_jmicron snd_hda_intel snd_pcm s
nd_timer snd snd_page_alloc nvidia(P) sky2 i2c_i801 i2c_core parport_pc parport jmicron
Nov 22 15:29:16 kiel Pid: 7, comm: events/0 Tainted: P 2.6.22-gentoo-r9 #5
Nov 22 15:29:16 kiel RIP: 0010:[<ffffffff80495238>] [<ffffffff80495238>] __linkwatch_run_queue+0xf8/0x1f0
Nov 22 15:29:16 kiel RSP: 0000:ffff81007da95e70 EFLAGS: 00010246
Nov 22 15:29:16 kiel RAX: ffff81007da95fd8 RBX: 0200229200050042 RCX: ffffffff80624a48
Nov 22 15:29:16 kiel RDX: ffff81007da95fd8 RSI: ffff81007da95ed0 RDI: ffffffff804951f1
Nov 22 15:29:16 kiel RBP: 0000000000000006 R08: ffff81007da94000 R09: 0000000000000000
Nov 22 15:29:16 kiel R10: 00000000ffffffff R11: 0000000000000000 R12: 0200229200050042
Nov 22 15:29:16 kiel R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Nov 22 15:29:16 kiel FS: 0000000000000000(0000) GS:ffffffff8062c000(0000) knlGS:0000000000000000
Nov 22 15:29:16 kiel CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Nov 22 15:29:16 kiel CR2: 00000000007af310 CR3: 0000000061cca000 CR4: 00000000000006e0
Nov 22 15:29:16 kiel Process events/0 (pid: 7, threadinfo ffff81007da94000, task ffff81007e114080)
Nov 22 15:29:16 kiel Stack: 0000000000000003 ffff81007e0f1bc0 ffffffff80495330 ffff81007e0f1bc8
Nov 22 15:29:16 kiel ffff81007e0f1bc8 ffffffff8049535a ffffffff80248dc0 ffffffff8024835e
Nov 22 15:29:16 kiel ffff81007e0f1bd8 ffff81007e0f1bc0 ffffffff80248dc0 ffffffff80248e85
Nov 22 15:29:16 kiel Call Trace:
Nov 22 15:29:16 kiel [<ffffffff80495330>] linkwatch_event+0x0/0x40
Nov 22 15:29:16 kiel [<ffffffff8049535a>] linkwatch_event+0x2a/0x40
Nov 22 15:29:16 kiel [<ffffffff80248dc0>] worker_thread+0x0/0x130
Nov 22 15:29:16 kiel [<ffffffff8024835e>] run_workqueue+0x7e/0x110
Nov 22 15:29:16 kiel [<ffffffff80248dc0>] worker_thread+0x0/0x130
Nov 22 15:29:16 kiel [<ffffffff80248e85>] worker_thread+0xc5/0x130
Nov 22 15:29:16 kiel [<ffffffff8024c6b0>] autoremove_wake_function+0x0/0x30
Nov 22 15:29:16 kiel [<ffffffff80248dc0>] worker_thread+0x0/0x130
Nov 22 15:29:16 kiel [<ffffffff80248dc0>] worker_thread+0x0/0x130
Nov 22 15:29:16 kiel [<ffffffff8024c2eb>] kthread+0x4b/0x80
Nov 22 15:29:16 kiel [<ffffffff8020a938>] child_rip+0xa/0x12
Nov 22 15:29:16 kiel [<ffffffff8024c2a0>] kthread+0x0/0x80
Nov 22 15:29:16 kiel [<ffffffff8020a92e>] child_rip+0x0/0x12
Nov 22 15:29:16 kiel
Nov 22 15:29:16 kiel
Nov 22 15:29:16 kiel Code: 4c 8b a3 a8 03 00 00 75 25 f0 0f ba 73 40 06 8b 43 40 a8 10
Nov 22 15:29:16 kiel RIP [<ffffffff80495238>] __linkwatch_run_queue+0xf8/0x1f0
Nov 22 15:29:16 kiel RSP <ffff81007da95e70>
Ich würde mich wirklich freuen, wenn jemand einen Tipp geben könnte, wie der Ndiswrapper zuverlässiger einsetzbar würde...