Ticket #195 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Bug in ath_vap_delete (after suspend)

Reported by: radsaq@gmail.com Assigned to: svens
Priority: major Milestone: version 1.0.0 - first stable release
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

While attempting to rmmod ath_pci when there was still a vap, I got the following kernel bug message.

Attachments

madwifi-ng.txt (2.1 kB) - added by radsaq@gmail.com on 12/01/05 00:16:35.
bug dump
madwifi-mlme-only-on-up-devices.diff (0.6 kB) - added by svens on 01/10/06 08:25:10.
madwifi-lock-statemachine.diff (0.9 kB) - added by svens on 01/10/06 09:16:12.

Change History

12/01/05 00:16:35 changed by radsaq@gmail.com

  • attachment madwifi-ng.txt added.

bug dump

12/01/05 08:08:50 changed by mrenzmann

For the records: which revision of trunk is that?

12/01/05 13:07:19 changed by radsaq@gmail.com

It's revision 1347

12/05/05 21:16:49 changed by svens

Had the same oops a few minutes ago. Only thing to note is that this happened after suspend. (I unloaded (at least i tried to unload ;-)) the module since it wasn't working after suspend)

12/05/05 21:19:54 changed by anonymous

Additinal Info: Kernel was 2.6.15-rc2, madwifi was revision 1349

12/06/05 08:10:41 changed by mrenzmann

@reporter: Did this issue occur on your side after suspending, too?

12/06/05 19:00:13 changed by radsaq@gmail.com

Yes

12/07/05 00:38:23 changed by kelmo

Maybe you could try the patch mentioned in ticket #205 ?

12/07/05 00:39:23 changed by kelmo

err, make that #201 ; )

12/07/05 07:51:27 changed by mrenzmann

  • summary changed from Bug in ath_vap_delete to Bug in ath_vap_delete (after suspend).
  • milestone changed from version 0.9.0 - move to new codebase to version 1.0.0 - first stable release.

#201 is probably related.

12/07/05 17:43:05 changed by radsaq@gmail.com

Yes, sorry, I should have mentioned that they were related, as I filed two bugs so as not to potentially confuse the issues, but perhaps this report is superfluous anyway..

12/15/05 08:32:47 changed by mrenzmann

@reporter: can you please confirm whether the patch in #201 solved the problem reported in this ticket as well? If so, I can close this ticket once that patch is committed.

12/17/05 00:01:32 changed by radsaq@gmail.com

Hrm.. not exactly.. With r1359 and the patch in #201, if I rmmod ath_pci without destroying ath0, everything goes fine up until I load ath_pci again, at which point I cannot create ath0 any longer: 

# wlanconfig ath0 create wlandev wifi0 wlanmode sta
wlanconfig: ioctl: Invalid argument
# wlanconfig eth1 create wlandev wifi0 wlanmode sta
eth1

But using another name, as shown, works.

12/19/05 09:22:11 changed by mrenzmann

There seems to be a general problem such that MadWifi fails to destroy its interfaces when the module is unloaded. We have some other indications that this problem is there. The proper solution seems to be to make sure that every device which has been created by MadWifi, either as representation of the physical device (wifiX) or as VAP (wlanconfig ...).

12/19/05 22:38:53 changed by svens

  • status changed from new to assigned.
  • owner set to anonymous.

Yes, see ticket 169 for a patch proposal. Looks to me like on unloading the driver the net80211 devices are not unset in the wlanunit bitmap. Can you please try both patches and report the results? Thanks for you patience :)

12/19/05 22:39:31 changed by svens

  • status changed from assigned to new.
  • owner changed from anonymous to svens.

12/21/05 00:09:02 changed by radsaq@gmail.com

The patch in #169 seems to have solved the device recreation problem, but as I said in #201, I still have problems there.. I'll have to do more testing later this week.

01/04/06 13:03:01 changed by pj_beers@hotmail.com

I had the same bug with sources dated 2006, 2 January. However, I had not suspended, and I used madwifi with wpa_supplicant-0.4.7. See #283

01/10/06 02:25:31 changed by svens

Tracked this down today. Even if the vap is not UP ieee80211_setmlme tries to associate to a station. This doesn't work, and the 80211 state machine toggles between IEEE802111_S_SCAN and IEEE80211_S_AUTH. If the vap is now destroyed, it is not stopped (because IFF_RUNNING isn't set on the vap). Changed ieee80211_setmlme to return EINVAL in this case fixed this. But more important is to limit the valid state transitions in the state machine. (e.g. changing from IEEE80211_S_INIT to IEEE80211_S_AUTH isn't possible if the Interface is down). Opinions?

01/10/06 02:27:04 changed by svens

the last sentence should read "e.g. changing from IEEE80211_S_INIT to IEEE80211_S_AUTH shouldn't be possible if the Interface is down."

01/10/06 06:33:45 changed by mrenzmann

I'd say both proposed changes would be a good idea.

01/10/06 08:25:10 changed by svens

  • attachment madwifi-mlme-only-on-up-devices.diff added.

01/10/06 09:16:12 changed by svens

  • attachment madwifi-lock-statemachine.diff added.

01/12/06 09:16:17 changed by svens

  • status changed from new to closed.
  • resolution set to fixed.

fixed as of r1394.

02/01/06 11:36:57 changed by kelmo

  • patch_attached set to 1.