On Mon, 2009-04-27 at 00:59 -0700, Zdenek Kabelac wrote:
> 2009/4/24 Zdenek Kabelac <zdenek.kabelac@xxxxxxxxx>:
> > 2009/4/22 John W. Linville <linville@xxxxxxxxxxxxx>:
> >> On Wed, Apr 22, 2009 at 12:33:03PM +0200, Zdenek Kabelac wrote:
> >>> Hi
> >>>
> >>> I'm checking whether -rcX kernel could be usable on my
> >>> T61/4GB/C2D/x86_64 - but wireless seems to be still out of
> >>> functionality:
> >>> I'm getting lots of weird trace-back messages and it looks like
> >>> iwl3945 is not working at all.
> >>> (attached messages from fresh build of -rc3 - but it never worked even in -rc1)
> >>
> >> Looks like this one did _not_ make -rc3:
> >>
> >> commit df833b1d73680f9f9dc72cbc3215edbbc6ab740d
> >> Author: Reinette Chatre <reinette.chatre@xxxxxxxxx>
> >> Date: Tue Apr 21 10:55:48 2009 -0700
> >>
> >> iwlwifi: DMA fixes
> >>
> >> A few issues wrt DMA were uncovered when using the driver with swiotlb.
> >> ...
> >>
> >> It is in wireless-2.6 and should be in net-2.6 -- please try one of those kernels.
> >
> >
> > I can confirm that current upstream linux commit
> > 9f5a691253924fd033a58c6b1fed57bb0a4eccf4 works again with iwlwifi.
> > and it already contains the patch you suggested to check.
> >
>
>
> While Wifi seems to be working well - I've noticed once attached long
> INFO message during suspend.
>
> Zdenek
>
> -----------
>
> Linux version 2.6.30-rc3-00324-g8087eae (gcc version 4.4.0 20090414
> (Red Hat 4.4.0-0.34) (GCC) ) #55 SMP Fri Apr 24 20:22:26 CEST 2009
> Command line: ro root=/dev/sda5 selinux=0 no_console_suspend
> ...
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> virbr0: no IPv6 routers present
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticated
> wlan0: associate with AP 00:11:d8:da:65:40
> wlan0: RX AssocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
> wlan0: associated
> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> wlan0: disassociating by local choice (reason=3)
> audit(1240599276.009:18266): audit_enabled=0 old=1 auid=4294967295
> ses=4294967295 res=1
> wlan0: no IPv6 routers present
> fuse init (API version 7.11)
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticated
> wlan0: associate with AP 00:11:d8:da:65:40
> wlan0: RX AssocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
> wlan0: associated
> wlan0: no probe response from AP 00:11:d8:da:65:40 - disassociating
> wlan0: deauthenticated (Reason: 7)
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticated
> wlan0: associate with AP 00:11:d8:da:65:40
> wlan0: RX ReassocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
> wlan0: associated
>
> ..........
>
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 2.6.30-rc3-00324-g8087eae #55
> ---------------------------------------------------------
> swapper/0 just changed the state of lock:
> (&(&priv->scan_check)->timer){+.-...}, at: [<ffffffff80250d90>]
> run_timer_softirq+0x120/0x2e0
> but this lock was taken by another, HARDIRQ-safe lock in the past:
> (&priv->lock){-.-...}
>
> and interrupts could create inverse lock ordering between them.
>
>
The locking used to protect scan_check is not consistent and is so
because we overusing the priv->lock spinlock. scan_check is used in
three places (iwl_rx_scan_complete_notif, iwl3945_bg_request_scan, and
iwl3945_set_mode). In iwl_rx_scan_complete_notif the access is protected
with priv->lock, while the other two use priv->mutex. The protection in
iwl_rx_scan_complete_notif with priv->lock is not necessary ... but a
significant effort is required to change this. We are starting to move
in this direction. A workaround will be to acquire priv->lock in
iwl3945_bg_request_scan and iwl3945_set_mode, but that will be ugly.
We can leave this code as is in 2.6.30 because inverse lock ordering is
not possible here as priv->mutex cannot be obtained in
iwl_rx_scan_complete_notif path as it (the mutex) sleeps and this code
path doesn't (it is run in a tasklet).
Reinette
--
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
