lkml.org 
[lkml]   [2008]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: BUG: NULL pointer dereference at 00000000 -- IP: [<f8e783d5>] :b43:b43_dma_mapping_error+0x16/0x155
    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@bu3sch.de> wrote:
    > On Tuesday 10 June 2008 16:42:41 Vegard Nossum wrote:
    >> This change comes from
    >>
    >> commit 353c409463ecba63c3a41a992d3f5fba935eada9
    >> Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    >> 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.
    >


    \
     
     \ /
      Last update: 2008-06-11 00:13    [W:0.047 / U:1.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site