I got a slightly different BUG with this patch applied: BUG: unable to handle kernel NULL pointer dereference at 00000000 IP: [<f89e3d41>] :b43:b43_dma_mapping_error+0x16/0x97 *pde = 00000000 Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:00/0000:00:08.0/0000:01:06.0/ssb0:0/firmware/ssb0:0/loading Modules linked in: sbs sbshc wmi battery iptable_filter ip_tables x_tables ac sbp2 rtc arc4 ecb crypto_blkcipher cryptomgr crypto_algapi b43 mac80211 cfg80211 led_class snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc i2c_nforce2 i2c_core button ohci1394 3c59x ieee1394 forcedeth ehci_hcd ohci_hcd usbcore thermal processor fan thermal_sys Pid: 4259, comm: NetworkManager Not tainted (2.6.26-rc5-mm2 #9) EIP: 0060:[<f89e3d41>] EFLAGS: 00010296 CPU: 0 EIP is at b43_dma_mapping_error+0x16/0x97 [b43] EAX: f6f205a0 EBX: c0416790 ECX: 0000006e EDX: 00000000 ESI: 0000006e EDI: 36060000 EBP: f6259b10 ESP: f6259afc DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process NetworkManager (pid: 4259, ti=f6259000 task=f78e8000 task.ti=f6259000) Stack: 01107455 0000006e c0416790 f6f205a0 f6dfc9b0 f6259b64 f89e41d5 00000001 f78e8000 c013506c f6dfc9b0 f6259b38 c0135026 01ffffff 00000001 00000000 00000080 36060000 00000000 f6259b5c c01063c4 f7962940 00000000 3fffffff Call Trace: [<f89e41d5>] ? b43_setup_dmaring+0xf2/0x51e [b43] [<c013506c>] ? trace_hardirqs_on+0xb/0xd [<c0135026>] ? trace_hardirqs_on_caller+0xe5/0x120 [<c01063c4>] ? dma_set_mask+0x1a/0x37 [<f89e4cc1>] ? b43_dma_init+0x21d/0x23b [b43] [<f89d6d2f>] ? b43_wireless_core_init+0x4a5/0x6d9 [b43] [<f89d7528>] ? b43_op_start+0xab/0xea [b43] [<f89b2ca9>] ? ieee80211_open+0x1e5/0x448 [mac80211] [<c013506c>] ? trace_hardirqs_on+0xb/0xd [<c02ccf41>] ? dev_open+0x66/0x99 [<c02cbcf6>] ? dev_change_flags+0x9c/0x14a [<c02d3361>] ? do_setlink+0x227/0x2d7 [<c031fca4>] ? _read_unlock+0x27/0x3c [<c02d4318>] ? rtnl_setlink+0xa4/0xbb [<c0135026>] ? trace_hardirqs_on_caller+0xe5/0x120 [<c02d4274>] ? rtnl_setlink+0x0/0xbb [<c02d3f4e>] ? rtnetlink_rcv_msg+0x192/0x1ac [<c02d3dbc>] ? rtnetlink_rcv_msg+0x0/0x1ac [<c02d92e7>] ? netlink_rcv_skb+0x30/0x75 [<c02d3db4>] ? rtnetlink_rcv+0x17/0x1f [<c02d90ce>] ? netlink_unicast+0x1c9/0x242 [<c02d9bf9>] ? netlink_sendmsg+0x21b/0x228 [<c02c22e2>] ? sock_sendmsg+0xc9/0xe0 [<c012a6f9>] ? autoremove_wake_function+0x0/0x30 [<c012a6f9>] ? autoremove_wake_function+0x0/0x30 [<c0135f43>] ? __lock_acquire+0xb2e/0xb4a [<c013506c>] ? trace_hardirqs_on+0xb/0xd [<c0135026>] ? trace_hardirqs_on_caller+0xe5/0x120 [<c01efe08>] ? copy_from_user+0x3b/0x5e [<c02c8930>] ? verify_iovec+0x40/0x70 [<c02c2446>] ? sys_sendmsg+0x14d/0x1a8 [<c02c2d34>] ? sys_recvmsg+0x172/0x17f [<c0135f43>] ? __lock_acquire+0xb2e/0xb4a [<c0156352>] ? handle_mm_fault+0x220/0x600 [<c02c32d2>] ? sys_socketcall+0x13e/0x171 [<c01ef9f8>] ? trace_hardirqs_on_thunk+0xc/0x10 [<c0102c95>] ? sysenter_past_esp+0x6a/0xa5 ======================= Code: c8 74 0d 41 75 05 42 b3 40 74 05 bb 1e 00 00 00 89 d8 5b c9 c3 55 89 e5 57 89 d7 56 89 ce 53 83 ec 08 8a 55 08 88 55 ef 8b 50 58 <8b> 12 8b 52 08 89 55 f0 8b 40 34 83 f8 1e 74 07 83 f8 20 75 5b EIP: [<f89e3d41>] b43_dma_mapping_error+0x16/0x97 [b43] SS:ESP 0068:f6259afc ---[ end trace 7a51b359a273191c ]--- On Tue, Jun 10, 2008 at 10:50 AM, Michael Buesch <mb@xxxxxxxxx> wrote: > On Tuesday 10 June 2008 16:42:41 Vegard Nossum wrote: >> This change comes from >> >> commit 353c409463ecba63c3a41a992d3f5fba935eada9 >> Author: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> >> Date: Fri May 23 19:02:30 2008 +0000 > > > Ok, FUJITA Tomonori, please make sure a patch like the following goes > into the same trees that you submitted commit 353c409 to. > Also make sure to check b43legacy. I _guess_ you might have added > the same bug there. > > Index: wireless-testing/drivers/net/wireless/b43/dma.c > =================================================================== > --- wireless-testing.orig/drivers/net/wireless/b43/dma.c 2008-06-10 13:58:22.000000000 +0200 > +++ wireless-testing/drivers/net/wireless/b43/dma.c 2008-06-10 16:48:53.000000000 +0200 > @@ -802,6 +802,7 @@ struct b43_dmaring *b43_setup_dmaring(st > if (!ring) > goto out; > ring->type = type; > + ring->dev = dev; > > nr_slots = B43_RXRING_SLOTS; > if (for_tx) > @@ -853,7 +854,6 @@ struct b43_dmaring *b43_setup_dmaring(st > DMA_TO_DEVICE); > } > > - ring->dev = dev; > ring->nr_slots = nr_slots; > ring->mmio_base = b43_dmacontroller_base(type, controller_index); > ring->index = controller_index; > > >> dma-mapping-add-the-device-argument-to-dma_mapping_error >> >> Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER >> architecture does: >> >> This enables us to cleanly fix the Calgary IOMMU issue that some devices >> are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423). >> >> I think that per-device dma_mapping_ops support would be also helpful for >> KVM people to support PCI passthrough but Andi thinks that this makes it >> difficult to support the PCI passthrough (see the above thread). So I >> CC'ed this to KVM camp. Comments are appreciated. >> >> A pointer to dma_mapping_ops to struct dev_archdata is added. If the >> pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If it's >> NULL, the system-wide dma_ops pointer is used as before. >> >> If it's useful for KVM people, I plan to implement a mechanism to register >> a hook called when a new pci (or dma capable) device is created (it works >> with hot plugging). It enables IOMMUs to set up an appropriate >> dma_mapping_ops per device. >> >> The major obstacle is that dma_mapping_error doesn't take a pointer to the >> device unlike other DMA operations. So x86 can't have dma_mapping_ops per >> device. Note all the POWER IOMMUs use the same dma_mapping_error function >> so this is not a problem for POWER but x86 IOMMUs use different >> dma_mapping_error functions. >> >> The first patch adds the device argument to dma_mapping_error. The patch >> is trivial but large since it touches lots of drivers and dma-mapping.h in >> all the architecture. >> >> (Added to Cc.) >> >> >> Vegard >> > > > > -- > Greetings Michael. > -- 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