[rt2x00-users] [PATCH 1/8] rt2x00: Convert rt2x00 to use threaded interrupts

Helmut Schaa helmut.schaa at googlemail.com
Thu Jul 8 23:44:59 AEST 2010


Am Donnerstag 08 Juli 2010 schrieb Ivo Van Doorn:
> On Thu, Jul 8, 2010 at 3:33 PM, Helmut Schaa
> <helmut.schaa at googlemail.com> wrote:
> > Am Donnerstag 08 Juli 2010 schrieb Ivo Van Doorn:
> >> On Tue, Jul 6, 2010 at 12:11 PM, Helmut Schaa
> >> <helmut.schaa at googlemail.com> wrote:
> >> > Use threaded interrupts for all rt2x00 PCI devices.
> >> >
> >> > This has several generic advantages:
> >> > - Reduce the time we spend in hard irq context
> >> > - Use non-atmic mac80211 functions for rx/tx
> >> >
> >> > Furthermore implementing broad- and multicast buffering will be
> >> > much easier in process context while maintaining low latency and
> >> > updating the beacon just before transmission (pre tbtt interrupt)
> >> > can also be done in process context.
> >> >
> >> > Signed-off-by: Helmut Schaa <helmut.schaa at googlemail.com>
> >>
> >> I have tested the patch, and on rt2800usb it produces the following warning:
> >>
> >> phy1 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 3,
> >> CWmax: 4, Aifs: 2, TXop: 102.
> >> ------------[ cut here ]------------
> >> WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x46/0x93()
> >> Hardware name: Aspire 5536
> >> Modules linked in: rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib
> >> compat_firmware_class cryptd aes_x86_64 aes_generic fuse
> >> ipt_MASQUERADE iptable_nat nf_nat bridge stp llc sunrpc
> >> cpufreq_ondemand powernow_k8 freq_table xt_physdev ip6t_REJECT
> >> nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 microcode
> >> dm_multipath kvm_amd kvm uinput arc4 ecb snd_hda_codec_atihdmi
> >> snd_hda_codec_realtek snd_hda_intel ath9k snd_hda_codec snd_hwdep
> >> mac80211 snd_seq snd_seq_device snd_pcm ath9k_common snd_timer
> >> ath9k_hw snd uvcvideo soundcore snd_page_alloc ath videodev cfg80211
> >> acer_wmi tg3 v4l1_compat edac_core edac_mce_amd rfkill
> >> v4l2_compat_ioctl32 wmi i2c_piix4 video output radeon ttm
> >> drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
> >> scsi_wait_scan]
> >> Pid: 0, comm: swapper Not tainted 2.6.32.14-127.fc12.x86_64 #1
> >> Call Trace:
> >>  <IRQ>  [<ffffffff81056364>] warn_slowpath_common+0x7c/0x94
> >>  [<ffffffff81056390>] warn_slowpath_null+0x14/0x16
> >>  [<ffffffff8105d402>] _local_bh_enable_ip+0x46/0x93
> >>  [<ffffffff8105d887>] local_bh_enable+0x12/0x14
> >>  [<ffffffffa03864a3>] rt2x00lib_rxdone+0x22c/0x260 [rt2x00lib]
> >>  [<ffffffffa01cc6c7>] rt2x00usb_interrupt_rxdone+0x7d/0x93 [rt2x00usb]
> >>  [<ffffffff8132fab0>] usb_hcd_giveback_urb+0x91/0xc5
> >>  [<ffffffff8134235c>] ehci_urb_done+0x7b/0x90
> >>  [<ffffffff8134241f>] qh_completions+0xae/0x4b9
> >>  [<ffffffff8103e78e>] ? __wake_up_common+0x4e/0x84
> >>  [<ffffffff81344b6a>] ehci_work+0x95/0x750
> >>  [<ffffffff81017d45>] ? sched_clock+0x9/0xd
> >>  [<ffffffff81079435>] ? sched_clock_local+0x1c/0x82
> >>  [<ffffffff81017e73>] ? native_sched_clock+0x2d/0x5f
> >>  [<ffffffff81017d45>] ? sched_clock+0x9/0xd
> >>  [<ffffffff81346b1c>] ehci_irq+0x2c1/0x423
> >>  [<ffffffff8107790e>] ? hrtimer_get_next_event+0xa7/0xc3
> >>  [<ffffffff8132f382>] usb_hcd_irq+0x3f/0x7b
> >>  [<ffffffff810acfd5>] handle_IRQ_event+0x60/0x121
> >>  [<ffffffff8107962a>] ? sched_clock_tick+0x78/0x7d
> >>  [<ffffffff810aee12>] handle_fasteoi_irq+0x8b/0xc7
> >>  [<ffffffff81014625>] handle_irq+0x8b/0x96
> >>  [<ffffffff8145ad74>] do_IRQ+0x5c/0xbc
> >>  [<ffffffff81012693>] ret_from_intr+0x0/0x11
> >>  <EOI>  [<ffffffff81030229>] ? native_safe_halt+0xb/0xd
> >>  [<ffffffff81018f39>] ? default_idle+0x36/0x53
> >>  [<ffffffff81010cdd>] ? cpu_idle+0xaa/0xe4
> >>  [<ffffffff8144eaef>] ? start_secondary+0x1f2/0x233
> >> ---[ end trace 177da08ab9000b68 ]---
> >> phy1 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 4,
> >> CWmax: 5, Aifs: 2, TXop: 188.
> >>
> >> Apparently the ieee80211_rx_ni is not allowed within the URB callback
> >> function. :(
> >
> > Hmm, that's bad. Any idea why it's not allowed?
> 
> Well the warning is triggered by this statement:
> 
> WARN_ON_ONCE(in_irq() || irqs_disabled());
> 
> So the USB seems to be working in IRQ context as well. Which is odd, since
> I though practically everything was done in process context :S

Crap! We could still use ieee80211_rx_irqsave (also from the threaded
interrupts) but that has more overhead then plain ieee80211_rx_ni :(

Any good ideas how to fix this?

Helmut




More information about the users mailing list