On Wed, Feb 13, 2008 at 5:48 PM, Chatre, Reinette <reinette.chatre@xxxxxxxxx> wrote: > > On Tuesday, February 12, 2008 11:42 PM, drago01 wrote: > > > Tomas Winkler wrote: > >> On Jan 26, 2008 9:00 PM, drago01 <drago01@xxxxxxxxx> wrote: > >> > >>> On Jan 22, 2008 9:24 PM, drago01 <drago01@xxxxxxxxx> wrote: > >>> > >>>> On Jan 22, 2008 9:21 PM, Winkler, Tomas > > <tomas.winkler@xxxxxxxxx> wrote: > >>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: drago01 [mailto:drago01@xxxxxxxxx] > >>>>>> Sent: Tuesday, January 22, 2008 10:12 PM > >>>>>> To: Winkler, Tomas > >>>>>> > >>>>>> Cc: ipw3945-devel; Cahill, Ben M; Zhu, Yi; linux-wireless > >>>>>> Subject: Re: [ipw3945-devel] iwl3945 rfkill regression > >>>>>> > >>>>>> On Jan 22, 2008 9:07 PM, Winkler, Tomas <tomas.winkler@xxxxxxxxx> > >>>>>> > >>>>> wrote: > >>>>> > >>>>>>> I believe it's delaying uCode load to mac_start - still need to > >>>>>>> be polished. > >>>>>>> > >>>>>> ok, thx for the quick reply. > >>>>>> If you have any potential fixes I would be happy to test them ;) > >>>>>> > >>>>> Can you get me the sequence it is happening? RF kill switch is off > >>>>> before you power up the laptop or after, during association or in > >>>>> unassociated state..etc Thanks > >>>>> > >>>> I boot with rf kill off = device on > >>>> acciotate using NM > >>>> kill the card by pressing the rfkill (ie. setting it to on) > >>>> card is dead (like described in my first mail), until I relaod the > >>>> module the rfkill switch does not have any effect at this time. > >>>> > >>>> > >>> OK, I investigated a bit and it seems to be the "disable interrupt > >>> when device goes down" is the problem. > >>> In my case NetworkManager detected the rfkill and brought the device > >>> down, which caused the interrupt to be disabled. Now after pressing > >>> the rfkill again nothing happend. But if I bring the device back up > >>> the interrupt is enabled again and rfkill and the card is back to > >>> live. So in short disabling the interrupt in mac_stop breaks the hw > >>> rfkill while the interface is down. > >>> > >>> > >> > >> Thanks for investigating this, still didn't have to time to dig into > >> it. > >> > >> > > ping? > > We are working on this. > > Reinette > OK, it seems not to be the irq (only) seems to be something else too. I tryed the attached patch (not to disable the irq in down when hw rfkill is set) but it was still the same. The driver does not update the sysfs file when the rfkill is back off (device on), so hal and NM still think that the rfkill is on while its off. Patch (hack) tested: diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 093b863..70e5e25 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -6545,6 +6545,9 @@ static int iwl3945_mac_start(struct ieee80211_hw *hw) IWL_DEBUG_MAC80211("enter\n"); + if(!atomic_read(&priv->pci_dev->enable_cnt)) + goto device_open; + if (pci_enable_device(priv->pci_dev)) { IWL_ERROR("Fail to pci_enable_device\n"); return -ENODEV; @@ -6559,6 +6562,7 @@ static int iwl3945_mac_start(struct ieee80211_hw *hw) goto out_disable_msi; } +device_open: /* we should be verifying the device is ready to be opened */ mutex_lock(&priv->mutex); @@ -6640,11 +6644,13 @@ static void iwl3945_mac_stop(struct ieee80211_hw *hw) iwl3945_down(priv); - flush_workqueue(priv->workqueue); - free_irq(priv->pci_dev->irq, priv); - pci_disable_msi(priv->pci_dev); - pci_save_state(priv->pci_dev); - pci_disable_device(priv->pci_dev); + if(!test_bit(STATUS_RF_KILL_HW, &priv->status) && !test_bit(STATUS_IN_SUSPEND, &priv->status)) { + flush_workqueue(priv->workqueue); + free_irq(priv->pci_dev->irq, priv); + pci_disable_msi(priv->pci_dev); + pci_save_state(priv->pci_dev); + pci_disable_device(priv->pci_dev); + } IWL_DEBUG_MAC80211("leave\n"); } -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
