insmod Stall - Redhat

This is a discussion on insmod Stall - Redhat ; I'm debugging a script that uses insmod to load a set of about 8 modules. It hangs my machine completely. It requires a reboot via power down/up. I decided I could do this one by one to find the culprit. ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: insmod Stall

  1. insmod Stall

    I'm debugging a script that uses insmod to load a set of about 8 modules. It
    hangs my machine completely. It requires a reboot via power down/up. I
    decided I could do this one by one to find the culprit. My first attempt,
    /sbin/insmod rtl.o hung the machine again. I'm definitely not a kernel guy
    or a module guy. What would be a good way to determine what's ailing the insmod?

    Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
    (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
    Obz Site: 39 15' 7" N, 121 2' 32" W, 2700 feet
    --
    "No, Groucho is not my real name. I am only
    breaking it in for a friend." -- Groucho Marx

    Web Page:


  2. Re: insmod Stall

    On Fri, 31 Mar 2006 17:05:54 +0000, W. Watson wrote:

    > I'm debugging a script that uses insmod to load a set of about 8 modules. It
    > hangs my machine completely. It requires a reboot via power down/up. I
    > decided I could do this one by one to find the culprit. My first attempt,
    > /sbin/insmod rtl.o hung the machine again. I'm definitely not a kernel guy
    > or a module guy. What would be a good way to determine what's ailing the insmod?


    Doesn't sound like a kernel problem to me. You may have a bad disk
    or memory problem, though. Google for memtest86 as a starter. Then
    you may need to "fsck -c" the filesystems one by one to check the
    disks.

    HTH

  3. Re: insmod Stall

    Tommy Reynolds wrote:

    > On Fri, 31 Mar 2006 17:05:54 +0000, W. Watson wrote:
    >
    >
    >>I'm debugging a script that uses insmod to load a set of about 8 modules. It
    >>hangs my machine completely. It requires a reboot via power down/up. I
    >>decided I could do this one by one to find the culprit. My first attempt,
    >>/sbin/insmod rtl.o hung the machine again. I'm definitely not a kernel guy
    >>or a module guy. What would be a good way to determine what's ailing the insmod?

    >
    >
    > Doesn't sound like a kernel problem to me. You may have a bad disk
    > or memory problem, though. Google for memtest86 as a starter. Then
    > you may need to "fsck -c" the filesystems one by one to check the
    > disks.
    >
    > HTH

    It's possible that you might be right, but this problem has plagued me in
    attempts to start a specific application each time I've rebuilt the kernel.
    I've rebuilt it 4-5 times via a standard manual procedure to get the app
    working. However, on another machine, much newer by the way, with the same
    app and a kernel I built, the app starts right up. The problem was there
    before I ever had the fsck problem. It always fails in the script with a
    hang, or, as I now know, just doing the insmod above.


    Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
    (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
    Obz Site: 39 15' 7" N, 121 2' 32" W, 2700 feet
    --
    "No, Groucho is not my real name. I am only
    breaking it in for a friend." -- Groucho Marx

    Web Page:

  4. Re: insmod Stall

    I checked the file size on the good machine and the stuck machine for rtl.o.
    180K (good) and 240K (stuck). Beats me what's going on. It's rained here for
    34 days with 3 days of some relief. Maybe that's the problem. :-)

  5. Re: insmod Stall

    W. Watson wrote:

    > I checked the file size on the good machine and the stuck machine for
    > rtl.o. 180K (good) and 240K (stuck). Beats me what's going on. It's
    > rained here for 34 days with 3 days of some relief. Maybe that's the
    > problem. :-)

    OK, I used the nm command on both files, and below is a short list of each
    file. Maybe there's something in there that suggests why they (the *.o
    files) are obviously different.

    Partial output from nm rtl.o in broken system (P3):
    Start of file
    00001a10 T arch_giveup
    00000ad0 T arch_takeover
    000015a0 T cleanup_module
    00000020 T conpr
    000000b0 T conprn
    U console_drivers_Rsmp_9fdea19f
    00001a90 t __constant_memcpy
    000000f8 d __count.3
    U cpu_online_map_Rsmp_c0aa8a72
    000000f4 D debug_lock
    00000630 T default_reschedule_handler <--- start to differ
    00000160 T dispatch_local_linux_irq
    U do_softirq_Rsmp_f0a529b7
    0000048a t end_apic_ack
    000005d0 t find_patch
    U free_irq_Rsmp_f20dabd8
    00001cb0 t get_gpended_irq
    U __global_restore_flags_Rsmp_54dd1dcb
    U __global_save_flags_Rsmp_5d902e96
    00002220 b initial_printkbuf
    00000590 T init_local_code
    00001540 T init_module
    00002a00 b in_printkbuf
    U irq_affinity_Rsmp_0a84c992
    U irq_control_Rsmp_25b88235
    U irq_stat_Rsmp_ed7388c8
    U jiffies_Rsmp_0da02d67
    00001180 B last_cli
    000000e0 d linux_ioapic_level_irq_type_ptr
    00001d24 B local_code
    00001d40 B local_ret_from_intr
    00000060 R __module_author
    000000a0 R __module_description
    00000000 r __module_kernel_version
    00000034 r __module_license

    .... snip

    00001d60 b saved_jumps
    00000370 t save_jump
    000019a0 b save_linux_irq_desc
    U smp_call_function_Rsmp_0014bfd1
    U smp_num_cpus_Rsmp_3b86334d
    000019a0 T soft_dispatch_global
    00000180 T soft_dispatch_local
    00000483 t start_apic_ack
    U __start_rtlinux_funcs_Rsmp_47a3ae8d
    000000e4 D sync_data
    00000960 T sync_off
    000008b0 T sync_on
    00001d16 t .text.lock.KBUILD_BASENAME
    00001fe6 t .text.lock.KBUILD_BASENAME
    000003b0 t unpatch_jump
    00001ba0 t unpatch_kernel
    00000510 t unzap_ack_apic
    U vsprintf_Rsmp_954cbb26
    00001d20 B xdo_IRQ
    End of File

    Partial output from nm rtl.o in working system (P4):

    Start of File
    00001190 T arch_giveup
    00001120 T arch_takeover
    00000c60 T cleanup_module
    00000020 T conpr
    00000090 T conprn
    U console_drivers_R9fdea19f
    00001290 t __constant_memcpy
    000000b0 d __count.3
    000000b0 D debug_lock
    00000280 T default_reschedule_handler
    U do_softirq_Rf0a529b7
    00000230 t find_patch
    U free_irq_Rf20dabd8
    00001390 t get_gpended_irq
    00000f60 b initial_printkbuf
    00000bc0 T init_module
    00001740 b in_printkbuf
    U irq_control_R25b88235
    U irq_stat_R55e8dea0
    00000004 B last_cli
    00000b44 B local_ret_from_intr
    U _mmx_memcpy_R15670e2d
    00000060 R __module_author
    000000a0 R __module_description
    00000000 r __module_kernel_version
    00000034 r __module_license

    .... snip

    00000b60 b saved_jumps
    00000170 t save_jump
    000007c0 b save_linux_irq_desc
    00001020 T soft_dispatch_global
    U __start_rtlinux_funcs_R47a3ae8d
    000000a0 D sync_data
    00000460 T sync_off
    000003c0 T sync_on
    000001b0 t unpatch_jump
    U vsprintf_R954cbb26
    00000b40 B xdo_IRQ

    End of File


    Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
    (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
    Obz Site: 39 15' 7" N, 121 2' 32" W, 2700 feet
    --
    "It is with things that you can neither see nor feel
    that it is important to guard against flights of
    imagination." -- Antoine Lavoisier, Chemist, 1743-1794

    Web Page:

  6. Re: insmod Stall

    On Sat, 01 Apr 2006 19:28:43 +0000, W. Watson wrote:

    > OK, I used the nm command on both files, and below is a short list of each
    > file. Maybe there's something in there that suggests why they (the *.o
    > files) are obviously different.


    I repeat my earlier advice. Check all this using "rpm -Va" and
    re-install problem RPM's.

    Cheers

  7. RAID 1 in Linux

    Hi,

    I am a Solaris Admin and new to Linux. In solaris using Sun Volume Manager
    (SDS) if we have a mirrored volume , we can detach mirror any time (stop
    sync) and then we can work on the other mirrot. If any problem happen , we
    can roll-back to the original data (from detached mirror). We used to use
    this technique for applying patches on system. Can we have same type of
    functionality with RedHat Linux....using Raid 1 with LVM????

    Thanx in advance

    Shahid Qavi

    Eng/Emirates Telecom

  8. Re: insmod Stall

    Tommy Reynolds wrote:

    > On Sat, 01 Apr 2006 19:28:43 +0000, W. Watson wrote:
    >
    >
    >>OK, I used the nm command on both files, and below is a short list of each
    >>file. Maybe there's something in there that suggests why they (the *.o
    >>files) are obviously different.

    >
    >
    > I repeat my earlier advice. Check all this using "rpm -Va" and
    > re-install problem RPM's.
    >
    > Cheers

    Thanks for the advice, but, because of limits on my time and skills, I'm
    going to take a completely different solution. And it is a total solution.
    It happens there is another version of this that is absolutely fool proof. I
    was doing this work for a friend. It's beyond my skill level, so I'm going
    to tell him to use the other version despite one drawback. If hooked into a
    network, it may allow security leaks. I'm afraid he'll just have to tough it
    out and use it outside his network. It's all specifically designed to
    operate one application. He'll just have to work out as an independent station.


    Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
    (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
    Obz Site: 39 15' 7" N, 121 2' 32" W, 2700 feet
    --
    "It is with things that you can neither see nor feel
    that it is important to guard against flights of
    imagination." -- Antoine Lavoisier, Chemist, 1743-1794

    Web Page:

  9. Re: insmod Stall

    "W. Watson" wrote in message
    news:R2YXf.11486$Bj7.815@newsread2.news.pas.earthl ink.net

    > Wayne T. Watson (Watson Adventures, Prop., Nevada City, CA)
    > (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
    > Obz Site: 39 15' 7" N, 121 2' 32" W, 2700 feet


    Why do you include the above static content in every post? Static content
    belongs in a signature, which should by Usenet standards be limited to 4
    lines.


+ Reply to Thread