Find the answer to your Linux question:
Results 1 to 2 of 2
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Trying to get this i2c driver working...

    Hello folks,

    I'm working on a project to integrate one of my company's parts into a specific target environment, and when I try to insert the driver module I'm getting a stack dump. I was hoping somebody with more Linux experience would be able to translate this and make some sense out of it for me. I am dynamically allocating kernel memory for my driver upon insertion...not really sure if I'm doing it wrong or I have it pointing to the wrong location. If anyone has any experience writing kernel drivers (specifically i2c), please have a look and let me know what you make of this.

    # dmesg
    Unable to handle kernel paging request at virtual address 302f646f
    pgd = c67c0000
    [302f646f] *pgd=00000000
    Internal error: Oops: 1 [#1]
    Modules linked in: kxte9
    CPU: 0 Not tainted ( #1)
    PC is at device_add_groups+0x58/0x7c
    LR is at device_add+0x2c0/0x5b0
    pc : [<c01a3b70>] lr : [<c01a43d0>] psr: 20000013
    sp : c6673d60 ip : c6673d88 fp : c6673d84
    r10: c6d33228 r9 : 00000003 r8 : 00000000
    r7 : 302f646f r6 : 00000000 r5 : 00000000 r4 : c6d33228
    r3 : 00000000 r2 : 00000001 r1 : 302f646f r0 : c6d33228
    Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
    Control: 00c5387f Table: 867c0018 DAC: 00000015
    Process insmod (pid: 402, stack limit = 0xc66722e
    Stack: (0xc6673d60 to 0xc6674000)
    3d60: c6d33228 c6ca7c38 00000000 c6ca7c70 00000000 c6d33290 c6673dc4 c6673d88
    3d80: c01a43d0 c01a3b24 c6673dac c6ca7c90 c6d332b0 00000000 c6d33228 c6d33228
    3da0: c6ca7c38 00000000 c6ca7c70 ffffffff 00000003 bf0000a0 c6673ddc c6673dc8
    3dc0: c01a46dc c01a411c c6d33200 c6ca7c38 c6673e04 c6673de0 c01ceae4 c01a46cc
    3de0: 0000000f c016b5c4 bf001820 0000000f 00000000 c6ca7c38 c6673e24 c6673e08
    3e00: bf000100 c01cea08 0000000f 00000000 c6ca7c38 0000000f c6673e5c c6673e28
    3e20: c01ce5a8 bf0000ac 00000000 00000000 00000000 00000000 00000002 c6ca7c38
    3e40: bf0015f4 00000008 bf0014b0 00000002 c6673e94 c6673e60 c01cf560 c01ce4c8
    3e60: c6673e84 bf0000a0 c006c6d8 bf0014b0 c6ca7c38 bf001820 00000001 0000002a
    3e80: c786f000 c6667a48 c6673eb4 c6673e98 bf000070 c01cf3b0 c6ca7c38 bf001408
    3ea0: 00000000 00000001 c6673ed4 c6673eb8 c01cf140 bf000040 bf001820 bf0016c0
    3ec0: bf0016c0 00000001 c6673eec c6673ed8 bf0030c8 c01cf08c c6d28f60 00000001
    3ee0: c6673fa4 c6673ef0 c008e248 bf00300c 00000000 00000000 c6673f1c 001aa953
    3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    3f20: 00000000 00000000 00000000 00000000 0000000a c7884330 c6d79600 c787f410
    3f40: c787f078 00000000 00000075 00000075 0000000e 0000002a c787ec55 c787f460
    3f60: bf0016cc c787f438 0000002b 00000028 00000000 c038f0c4 c6673fa4 001cf2c0
    3f80: 001cf370 001c2fc8 00000080 c002e008 c6672000 00000000 00000000 c6673fa8
    3fa0: c002de60 c008cda0 001cf2c0 001cf370 001cf370 00015789 001aa953 00000000
    3fc0: 001cf2c0 001cf370 001c2fc8 00000080 00000000 00000068 00000000 00000002
    3fe0: 00000000 be966804 0001a4fc 00009464 60000010 001cf370 ee2282ff 3e000475
    [<c01a3b18>] (device_add_groups+0x0/0x7c) from [<c01a43d0>] (device_add+0x2c0/0x5b0)
    [<c01a4110>] (device_add+0x0/0x5b0) from [<c01a46dc>] (device_register+0x1c/0x20)
    [<c01a46c0>] (device_register+0x0/0x20) from [<c01ceae4>] (i2c_attach_client+0xe8/0x18
    r5:c6ca7c38 r4:c6d33200
    [<c01ce9fc>] (i2c_attach_client+0x0/0x18 from [<bf000100>] (kxte9_attach+0x60/0x7c [kxte9])
    r7:c6ca7c38 r6:00000000 r5:0000000f r4:bf001820
    [<bf0000a0>] (kxte9_attach+0x0/0x7c [kxte9]) from [<c01ce5a8>] (i2c_probe_address+0xec/0x140)
    r7:0000000f r6:c6ca7c38 r5:00000000 r4:0000000f
    [<c01ce4bc>] (i2c_probe_address+0x0/0x140) from [<c01cf560>] (i2c_probe+0x1bc/0x1d0)
    [<c01cf3a4>] (i2c_probe+0x0/0x1d0) from [<bf000070>] (kxte9_attach_adapter+0x3c/0x6c [kxte9])
    [<bf000034>] (kxte9_attach_adapter+0x0/0x6c [kxte9]) from [<c01cf140>] (i2c_register_driver+0xc0/0x100)
    r7:00000001 r6:00000000 r5:bf001408 r4:c6ca7c38
    [<c01cf080>] (i2c_register_driver+0x0/0x100) from [<bf0030c8>] (kxte9_init+0xc8/0x120 [kxte9])
    r7:00000001 r6:bf0016c0 r5:bf0016c0 r4:bf001820
    [<bf003000>] (kxte9_init+0x0/0x120 [kxte9]) from [<c008e248>] (sys_init_module+0x14b4/0x157c)
    r5:00000001 r4:c6d28f60
    [<c008cd94>] (sys_init_module+0x0/0x157c) from [<c002de60>] (ret_fast_syscall+0x0/0x2c)
    Code: e2444004 5afffff9 ea000007 e2855001 (e7971105)
    ---[ end trace 7e5394f37c05e45a ]---

    # lsmod
    kxte9 6500 1 - Loading 0xbf000000

    Any insight would be greatly appreciated!

    Thank you,

  2. #2
    Sorry to clog up your forum with my stack trace...anyways I figured out what the problem was; thought folks might be interested.

    I had a pretty good idea that the problem was with the kernel memory allocation, and in researching [kmalloc sizeof], I realized that most of the code I saw showed explicit typing of the kmalloc return pointer. Example:

    struct my_data {
    struct i2c_client *my_client;
    struct cdev cdev;
    unsigned int addr;
    } *my_data_ptr;

    Init function:
    my_data_ptr = (struct my_data *)kmalloc(sizeof(struct my_data), GFP_KERNEL);

    The bolded part is what I had left out before, and once the code was changed and recompiled, I was able to verify communication with our part. Now off to write a userspace application to exercise some functionality...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts