lkml.org 
[lkml]   [2012]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectKernel oops in at76c50x-usb
    Johannes,

    This particular oops is seen for at76c50x-usb on a PPC, but I have seen a
    similar oops for b43legacy, and i thought there was one earlier in the wireless
    ML, but I could not find it just now.

    This particular oops does not always occur. Usually, the machine just freezes.

    The dmesg dump is:

    =============================================================

    [ 156.231550] Unable to handle kernel paging request for data at address 0x0000004c
    [ 156.231571] Faulting instruction address: 0xc0342e98
    [ 156.231594] Oops: Kernel access of bad area, sig: 11 [#1]
    [ 156.231599] PowerMac
    [ 156.231692] Modules linked in: at76c50x_usb nfs lockd fscache auth_rpcgss
    nfs_acl sunrpc uinput cpufreq_userspace cpufreq_conservative cpufreq_ondemand
    cpufreq_stats cpufreq_powersave bluetooth fuse loop firewire_sbp2 arc4 b43
    mac80211 cfg80211 rfkill rng_core ssb mmc_core pcmcia evdev yenta_socket
    pcmcia_rsrc pcmcia_core ext4 mbcache jbd2 crc16 ohci_hcd ehci_hcd usbcore
    firewire_ohci sungem firewire_core sungem_phy crc_itu_t sr_mod cdrom usb_common
    nls_base [last unloaded: scsi_wait_scan]
    [ 156.231703] NIP: c0342e98 LR: e25121ac CTR: c0342e80
    [ 156.231715] REGS: df869e00 TRAP: 0300 Not tainted (3.5.0-rc4-wl+)
    [ 156.231732] MSR: 00001032 <ME,IR,DR,RI> CR: 42000042 XER: 20000000
    [ 156.231738] DAR: 0000004c, DSISR: 40000000
    [ 156.231804] TASK = df859b00[5] 'kworker/u:0' THREAD: df868000
    [ 156.231804] GPR00: e25121ac df869eb0 df859b00 00000000 df858db0 df858db0
    1d0be361 00000000
    [ 156.231804] GPR08: 00000000 00000001 73635f72 0000004c c0342e80 00000000
    018bd137 0197dda0
    [ 156.231804] GPR16: 018bd55a 0196ecb8 018ee7d4 018bd538 ffbc1280 018bcd5b
    00000001 c05830d4
    [ 156.231804] GPR24: c05e46d8 00000000 00000001 00000001 de8cd460 debde9c8
    df869ec8 debde300
    [ 156.231840] NIP [c0342e98] __netif_schedule+0x18/0x78
    [ 156.231967] LR [e25121ac] ieee80211_propagate_queue_wake+0x100/0x14c [mac80211]
    [ 156.231972] Call Trace:
    [ 156.231986] [df869eb0] [c0342ee0] __netif_schedule+0x60/0x78 (unreliable)
    [ 156.232025] [df869ec0] [e25121ac] ieee80211_propagate_queue_wake+0x100/0x14c
    [mac80211]
    [ 156.232065] [df869f00] [e25123bc] ieee80211_wake_queues_by_reason+0x3c/0x7c
    [mac80211]
    [ 156.232096] [df869f20] [e29a2178] at76_dwork_hw_scan+0x184/0x1a8 [at76c50x_usb]
    [ 156.232123] [df869f50] [c0057d04] process_one_work+0x2a4/0x45c
    [ 156.232136] [df869f80] [c0058358] worker_thread+0x244/0x3d4
    [ 156.232153] [df869fb0] [c005d168] kthread+0x88/0x8c
    [ 156.232174] [df869ff0] [c000fa58] kernel_thread+0x4c/0x68
    [ 156.232180] Instruction dump:
    [ 156.232200] 83810010 83a10014 83c10018 83e1001c 38210020 4e800020 9421fff0
    7c0802a6
    [ 156.232219] 3963004c 39200001 90010014 93e1000c <7c005828> 7c0a4b78 7d40592d
    40a2fff4
    [ 156.232232] ---[ end trace 11d3cd4cb4a4faf3 ]---
    [ 156.232236]
    [ 156.232401] Unable to handle kernel paging request for data at address 0xfffffffc
    [ 156.232411] Faulting instruction address: 0xc005cb48

    =============================================================
    The objdump listing and the source for the routine in question follows:

    =============================================================

    00001600 <__netif_schedule>:
    __netif_schedule():
    1600: 94 21 ff f0 stwu r1,-16(r1)
    1604: 7c 08 02 a6 mflr r0
    1608: 39 63 00 4c addi r11,r3,76
    160c: 39 20 00 01 li r9,1
    1610: 90 01 00 14 stw r0,20(r1)
    1614: 93 e1 00 0c stw r31,12(r1)
    1618: 7c 00 58 28 lwarx r0,0,r11
    161c: 7c 0a 4b 78 or r10,r0,r9
    1620: 7d 40 59 2d stwcx. r10,0,r11
    1624: 40 a2 ff f4 bne- 1618 <__netif_schedule+0x18>
    1628: 70 00 00 01 andi. r0,r0,1
    162c: 40 a2 00 38 bne+ 1664 <__netif_schedule+0x64>
    1630: 7f e0 00 a6 mfmsr r31
    1634: 57 e9 04 5e rlwinm r9,r31,0,17,15
    1638: 7d 20 01 24 mtmsr r9
    163c: 90 03 00 44 stw r0,68(r3)
    1640: 3d 20 00 00 lis r9,0
    1644: 38 03 00 44 addi r0,r3,68
    1648: 39 29 00 00 addi r9,r9,0
    164c: 81 69 00 04 lwz r11,4(r9)
    1650: 90 6b 00 00 stw r3,0(r11)
    1654: 38 60 00 02 li r3,2
    1658: 90 09 00 04 stw r0,4(r9)
    165c: 48 00 00 01 bl 165c <__netif_schedule+0x5c>
    1660: 7f e0 01 24 mtmsr r31
    1664: 80 01 00 14 lwz r0,20(r1)
    1668: 83 e1 00 0c lwz r31,12(r1)
    166c: 38 21 00 10 addi r1,r1,16
    1670: 7c 08 03 a6 mtlr r0
    1674: 4e 80 00 20 blr

    static inline void __netif_reschedule(struct Qdisc *q)
    {
    struct softnet_data *sd;
    unsigned long flags;

    local_irq_save(flags);
    sd = &__get_cpu_var(softnet_data);
    q->next_sched = NULL;
    *sd->output_queue_tailp = q;
    sd->output_queue_tailp = &q->next_sched;
    raise_softirq_irqoff(NET_TX_SOFTIRQ);
    local_irq_restore(flags);
    }

    void __netif_schedule(struct Qdisc *q)
    {
    if (!test_and_set_bit(__QDISC_STATE_SCHED, &q->state))
    __netif_reschedule(q);
    }
    EXPORT_SYMBOL(__netif_schedule);

    ===================================================


    My PPC instruction decoding skills are poor, but I think the crash is happening
    at offset 1660. In addition, the routine is about to exit.

    Thanks,

    Larry


    \
     
     \ /
      Last update: 2012-06-30 00:01    [W:0.040 / U:31.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site