Thread: [Ndiswrapper-general] Freezing with an amd64 marvel 1fa7 (w64 drivers) on fed c3
Status: Beta
Brought to you by:
pgiri
From: Jean-Yves S. <let...@ti...> - 2005-09-19 21:16:26
|
Hello, I can't get ndiswrapper working on this amd64, it either A) freeze or B) panic. It worked when i was in a 32bit userland, but since i've 'upgraded' to a 64bit kernel, the driver is unstable. What should i do to help debugging? Here are my system 'specs': - Ndiswrapper : 1.3rc1 - kernel : fedora core 3 2.6.12-1.1372_FC3 - Motherboard: A8V-E Deluxe (wifi on board) for Amd64 - wifi chip: Marvell 1fa7 ( 88W8310 and 88W8000G 802.11g client chipset) - windows driver: windows 64b 2.7.1.2 driver from asus: http://dlsvr02.asus.com/pub/ASUS/mb/socket775/P5AD2-E% 20Premium/Marvell_wlan.zip http://dlsvr01.asus.com/pub/ASUS/mb/socket775/P5AD2-E% 20Premium/Marvell_wlan.zip (drivers are exactly the same than for the socket 775 motherboard) and logs of: make DEBUG=3 install (same result with or w/o INPROCOMM_AMD64=1) sequence: modprobe ndiswrapper ; ifconfig wlan0 up; iwlist wlan0 scanning *freeze* http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/1.3rc1/messages.ndiswrapper.modprobe.ifconfigup.iwlistscanning.froze (500k) Sequence: modprobe ndiswrapper; rmmod ndiswrapper *panic* http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/1.3rc1/messages.ndiswrapper.modprobe.rmmod.panic (300k) Greetings, -- Jean-Yves Simon <let...@ti...> |
From: Giridhar P. <gi...@lm...> - 2005-09-19 21:19:28
|
Submit debug trace (including full oops message). See wiki Bugs entry for details. If the trace is too long to send to the list, send it to me directly. -- Giri |
From: Giridhar P. <gi...@lm...> - 2005-09-19 21:21:26
|
Sorry, didn't notice that you already collected the logs. But I don't see kernel oops message itself in the logs. It may be hard to collect that. You may want to use netconsole for that. -- Giri |
From: Milan <em...@gm...> - 2005-09-19 21:43:31
|
On Po, 2005-09-19 at 17:21 -0400, Giridhar Pemmasani wrote: > Sorry, didn't notice that you already collected the logs. But I don't see > kernel oops message itself in the logs. It may be hard to collect that. You > may want to use netconsole for that. > maybe I'm wrong, but I think this is the whole oops message (excerpt from previously mailed URL). It's in about 75% of the log file... . Sep 19 22:49:00 little kernel: Unable to handle kernel paging request at ffffc2001684bae8 RIP: Sep 19 22:49:00 little kernel: [<ffffc200004ec466>] Sep 19 22:49:00 little kernel: PGD 37ffe067 PUD 37ffd067 PMD 0 Sep 19 22:49:00 little kernel: Oops: 0000 [1] Sep 19 22:49:00 little kernel: CPU 0 Sep 19 22:49:00 little kernel: Modules linked in: ndiswrapper(U) nvidia(U) nfs lockd parport_pc lp parport md5 ipv6 lm75 i2c_sensor sunrpc nls_utf8 ntfs(U) reiserfs vfat fat dm_mod video button battery ac ohci1394 ieee1394 uhci_hcd ehci_hcd emu10k1_gp i2c_viapro i2c_core snd_via82xx gameport snd_mpu401_uart snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore sk98lin(U) sata_via libata sr_mod ext3 jbd aic7xxx scsi_transport_spi sd_mod scsi_mod Sep 19 22:49:00 little kernel: Pid: 5715, comm: rmmod Tainted: PF 2.6.12-1.1372_FC3 Sep 19 22:49:00 little kernel: RIP: 0010:[<ffffc200004ec466>] [<ffffc200004ec466>] Sep 19 22:49:00 little kernel: RSP: 0018:ffff810035c59bd8 EFLAGS: 00010286 Sep 19 22:49:00 little kernel: RAX: ffffc2001684bb18 RBX: ffff810039933e80 RCX: 0000000000657079 Sep 19 22:49:00 little kernel: RDX: 0000000000657079 RSI: ffffc20000542070 RDI: ffff810039933e80 Sep 19 22:49:00 little kernel: RBP: ffff8100362222f0 R08: 0000000000000000 R09: ffffc200005420a0 Sep 19 22:49:00 little kernel: R10: 00000000000002a8 R11: ffff810037631000 R12: ffff810036374440 Sep 19 22:49:00 little kernel: R13: ffff810036569630 R14: 0000000000000880 R15: 0000000000502010 Sep 19 22:49:00 little kernel: FS: 00002aaaaadf56e0(0000) GS:ffffffff8055ce00(0000) knlGS:00000000f7db36c0 Sep 19 22:49:00 little kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 19 22:49:00 little kernel: CR2: ffffc2001684bae8 CR3: 0000000035c37000 CR4: 00000000000006e0 Sep 19 22:49:00 little kernel: Process rmmod (pid: 5715, threadinfo ffff810035c58000, task ffff8100362150b0) Sep 19 22:49:01 little kernel: Stack: ffff810039933e80 ffffc200004ec83e 00000000ffffffff 0000000000000001 Sep 19 22:49:01 little kernel: ffff8100379d48c0 ffff810039933e80 ffff810039933e80 ffffc200004e9093 Sep 19 22:49:01 little kernel: 0000000000502010 ffffffff8887d859 Sep 19 22:49:01 little kernel: Call Trace:<ffffffff8886e890>{:ndiswrapper:pdoDispatchPnp+0} <ffffffff88872123>{:ndiswrapper:miniport_halt+83} Sep 19 22:49:01 little kernel: <ffffffff8886d170>{:ndiswrapper:IopPassIrpDown+0} <ffffffff8886e918>{:ndiswrapper:pdoDispatchPnp+136} Sep 19 22:49:01 little kernel: <ffffffff8886e890>{:ndiswrapper:pdoDispatchPnp+0} <ffffffff8886cf22>{:ndiswrapper:IofCallDriver+258} Sep 19 22:49:01 little kernel: <ffffffff8886d170>{:ndiswrapper:IopPassIrpDown+0} <ffffffff8886cf22>{:ndiswrapper:IofCallDriver+258} Sep 19 22:49:01 little kernel: <ffffffff88873d4c>{:ndiswrapper:ndiswrapper_remove_device+476} Sep 19 22:49:01 little kernel: <ffffffff88859cd2>{:ndiswrapper:ndiswrapper_remove_pci_device+210} Sep 19 22:49:01 little kernel: <ffffffff8024361c>{pci_device_remove+44} <ffffffff802b5a7f>{device_release_driver+111} Sep 19 22:49:01 little kernel: <ffffffff802b5f2c>{bus_remove_driver+156} <ffffffff802b637d>{driver_unregister+13} Sep 19 22:49:01 little kernel: <ffffffff80243144>{pci_unregister_driver+20} <ffffffff8885bf06>{:ndiswrapper:loader_exit+134} Sep 19 22:49:01 little kernel: <ffffffff88875c99>{:ndiswrapper:module_cleanup+9} <ffffffff80160631>{sys_delete_module+497} Sep 19 22:49:01 little kernel: <ffffffff8018822b>{sys_munmap+107} <ffffffff8010f096>{system_call+126} Sep 19 22:49:01 little kernel: Sep 19 22:49:01 little kernel: Sep 19 22:49:01 little kernel: Code: 4c 39 40 d0 74 05 4c 39 00 75 21 ff ca 48 83 e8 38 48 ff c9 Sep 19 22:49:01 little kernel: RIP [<ffffc200004ec466>] RSP <ffff810035c59bd8> Sep 19 22:49:01 little kernel: CR2: ffffc2001684bae8 Sep 19 22:49:01 little kernel: <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 Sep 19 22:49:01 little kernel: in_atomic():0, irqs_disabled():1 Sep 19 22:49:01 little kernel: Sep 19 22:49:01 little kernel: Call Trace:<ffffffff801337df>{__might_sleep+191} <ffffffff8013acc9>{profile_task_exit+41} Sep 19 22:49:01 little kernel: <ffffffff8013cb62>{do_exit+34} <ffffffff80298235>{do_unblank_screen+53} Sep 19 22:49:01 little kernel: <ffffffff80124b1f>{do_page_fault+1839} <ffffffff803a843d>{schedule_timeout+301} Sep 19 22:49:01 little kernel: <ffffffff8010fa15>{error_exit+0} <ffffffff8886e890>{:ndiswrapper:pdoDispatchPnp+0} Sep 19 22:49:01 little kernel: <ffffffff88872123>{:ndiswrapper:miniport_halt+83} <ffffffff8886d170>{:ndiswrapper:IopPassIrpDown+0} Sep 19 22:49:01 little kernel: <ffffffff8886e918>{:ndiswrapper:pdoDispatchPnp+136} Sep 19 22:49:01 little kernel: <ffffffff8886e890>{:ndiswrapper:pdoDispatchPnp+0} <ffffffff8886cf22>{:ndiswrapper:IofCallDriver+258} Sep 19 22:49:01 little kernel: <ffffffff8886d170>{:ndiswrapper:IopPassIrpDown+0} <ffffffff8886cf22>{:ndiswrapper:IofCallDriver+258} Sep 19 22:49:01 little kernel: <ffffffff88873d4c>{:ndiswrapper:ndiswrapper_remove_device+476} Sep 19 22:49:01 little kernel: <ffffffff88859cd2>{:ndiswrapper:ndiswrapper_remove_pci_device+210} Sep 19 22:49:01 little kernel: <ffffffff8024361c>{pci_device_remove+44} <ffffffff802b5a7f>{device_release_driver+111} Sep 19 22:49:01 little kernel: <ffffffff802b5f2c>{bus_remove_driver+156} <ffffffff802b637d>{driver_unregister+13} Sep 19 22:49:01 little kernel: <ffffffff80243144>{pci_unregister_driver+20} <ffffffff8885bf06>{:ndiswrapper:loader_exit+134} Sep 19 22:49:01 little kernel: <ffffffff88875c99>{:ndiswrapper:module_cleanup+9} <ffffffff80160631>{sys_delete_module+497} Sep 19 22:49:01 little kernel: <ffffffff8018822b>{sys_munmap+107} <ffffffff8010f096>{system_call+126} Sep 19 22:49:01 little kernel: |
From: Jean-Yves S. <let...@ti...> - 2005-09-19 21:50:34
|
On Mon, 2005-09-19 at 17:24 -0400, Giridhar Pemmasani wrote: > Try latest snapshot; it may have fixed issue with rmmod. Let me know if it > does (or not). > Tried with the last (now) cvs snapshot, had to remove the 'static' from 4 USB functions for the module to load It still oopses, here are the logs of a: modprobe ndiswrapper; cat /proc/ksym* > file ; rmmod ndiswrapper both gzipped: http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/msg.tar.gz modprobe & rmmod msgs: (210K) http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/messages.oops.modprobe.rmmod /proc/kallsym dump after the modprobe, before the rmmod: (1.6MB) http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/kallsymndiswrapper -- Jean-Yves Simon <let...@ti...> |
From: Jean-Yves S. <let...@ti...> - 2005-09-19 22:26:38
|
On Mon, 2005-09-19 at 17:46 -0400, Giridhar Pemmasani wrote: > I am taking a guess here: Can you add 'return' to the beginning of > update_wireless_stats function, so that that function doesn't do anything? > That _may_ fix the problem with scanning. > Before doing anything, things happened this way: modprobe : ok iwlist wlan0 scanning : ok ifconfig wlan0 up : ok iwlist wlan0 scanning : froze. now i've done this: changed the update wireless stats to return only. things happen like this: modprobe : ok * a new message comes about every 10 seconds: Sep 20 00:09:59 little kernel: ndiswrapper (wrapper_worker_proc:1312): wlan0 is being reset iwlist wlan0 scanning: ok ifconfig wlan0 up: ok iwlist wlan0 scanning : ok all other iwlist * : ok ifconfig wlan0 mode ad-hoc: ok mode managed: ok only failure was when i rmmoded the module (with actual cvs). (if required, i can send the logs for all this) I can't tell for the device when in a working more, it's the only wifi device i have for the moment. But this is a very significative improvement compared to ndisw1.0, i think i'll get a pcmcia wifi card to make some bigger tests soon =) This marvel card i'm trying now is on the motherboard, no way to plug/unplug it, but i'll give a try to the DEBUG=6 (still with the return in the function), will send a mail soon. -- Jean-Yves Simon <let...@ti...> |
From: Giridhar P. <gi...@lm...> - 2005-09-19 22:32:57
|
On Tue, 20 Sep 2005 00:26:14 +0200, Jean-Yves Simon <let...@ti...> said: Jean-Yves> * a new message comes about every 10 seconds: Sep 20 00:09:59 Jean-Yves> little kernel: ndiswrapper (wrapper_worker_proc:1312): wlan0 is Jean-Yves> being reset It may be difficult for me to find out why this happens without hardware, but for now you can disable hangcheck (which is resetting the card): Pass hangcheck_interval=-1 option to ndiswrapper module. Jean-Yves> This marvel card i'm trying now is on the motherboard, no way to Jean-Yves> plug/unplug it, but i'll give a try to the DEBUG=6 (still with Jean-Yves> the return in the function), will send a mail soon. Instead of editing wrapper.c or writing to /proc/net/ndiswrapper/debug initially to disable debug, as I described earlier, just pass debug=0 option to ndiswrapper module (after compiling with DEBUG=6). Later, enable debug and rmmod, as I said: echo 6 > /proc/net/ndiswrapper/debug; rmmod ndiswrapper -- Giri |
From: Jean-Yves S. <let...@ti...> - 2005-09-19 22:45:38
|
On Mon, 2005-09-19 at 18:16 -0400, Giridhar Pemmasani wrote: All the files targzipped: http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/debug6forrmmod/allthefiles.tar.gz (600KB) Here are the results: 1) modprobe ndiswrapper cat /proc/ksym* > file echo 6 > /proc/../debug ; rmmod ndiswrapper this worked. are the first logs: http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/debug6forrmmod/kallsymsndiswrapper.DEBUG6A http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/debug6forrmmod/messagesnoifconfigupworkedA 2) not rebooted; modprobe ndiswrapper cat ksym > fileB ifconfig wlan0 up echo 6 > /proc/.../debug ; rmmod ndiswrapper it oopsed files: http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/debug6forrmmod/kallsymsndiswrapper.DEBUG6bis http://lethalwp.dyndns.org/~lethalwp/files/ndiswrapperlogs/cvs-1.3rc1/debug6forrmmod/messagesifconfigupoopsedBis As i said, i'll try to get another wifi device asap for other tests. But i wonder if it will work if the workprocess resets wlan0 every 20 seconds. > A higher debug level would probably help. Instead of collecting full debug > log, you can enable debug only before rmmod. Load module and disable debug: > > echo 0 > /proc/net/ndiswrapper/debug > > Insert your card. You should not get any debug trace information from > ndiswrapper. Then do > > echo 6 > proc/net/ndiswrapper/debug; rmmod ndiswrapper > > If your card is mini-PCI and you can't plugin after inserting module, replace > > int debug = DEBUG; > > with > > int debug = 0; > > in wrapper.c and recompile with DEBUG=6 > > As requested earlier, could you give more details about what works and what > else doesn't work? Specifically, are you able to use the card to send/receive > packets? > -- Jean-Yves Simon <let...@ti...> |