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

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:

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. :-)

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:

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

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

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:

"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.