Re: jprobe bug?

[William Cohen <wcohen at redhat dot com>]

Martin Hunt wrote:
> > To avoid having to mess with the various address I converted the example 
> > back to a dtr script. I have attached the script to this email. The 
> > script seemed to install okay. Does the address used in the module look 
> > okay? I don't have a version of that kernel built.
>
>
> I started with a dtr script like the one you attached.  It causes the
> crash too. Then I tried just the basic C code I sent and it still
> happened.
>
> I've been running more tests this morning. It looks like you must have 2
> CPUs (or 1 with hyperthreading enabled) and run the SMP kernel to
> reproduce.
>
> CPU           kernel   bug?
> ------------------------
> Xeon/EM64T    UP       NO
> 2 Xeon/EM64T  SMP      YES
> P4/HT         UP       NO
> P4/HT         SMP      YES
> P4/NoHT       SMP      NO

That explains why I didn't encounter the problem on my AMD64 machine. It 
only has one processor.  I have a memory impoverished dual processor 
pentium III machine. It is running a 2.6.10-1.741_FCsmp kernel. I tried 
the same experiment and it seems to be hung.  For a while the shiftlock 
worked and the update applet flashed, but it seems to be stuck at this 
point.

-Will

> I'm using both 2.6.10-1.741_FC3 and 2.6.10-1.753_FC3.  problems appear
> in both.
>
> Ouch! My P4 box (hyperthreading with SMP kernel) just lost vertical sync
> and crashed hard.
>
> The easiest method to reproduce is to run and exit Firefox a couple of
> times.  I've never had it run twice without hanging.  Keep trying and
> your system should crash.
>
> Most dumps don't look useful.  This one (from my P4 test system) might
> be.
>
> ----
>
> Jan 31 13:57:53 dragon kernel: Unable to handle kernel paging request
> at 
> virtual address 002031d3
> Jan 31 13:57:53 dragon kernel:  printing eip:
> Jan 31 13:57:53 dragon kernel: e8d36280
> Jan 31 13:57:53 dragon kernel: *pde = 35da5001
> Jan 31 13:57:53 dragon kernel: Oops: 0002 [#1]
> Jan 31 13:57:53 dragon kernel: SMP
> Jan 31 13:57:53 dragon kernel: Modules linked in: dtr(U) parport_pc lp 
> parport autofs4 sunrpc dm_mod video button battery ac nvidia(U) md5
> ipv6 
> ohci1394 ieee1394 uhci_hcd ehci_hcd hw_random i2c_i801 i2c_core 
> emu10k1_gp gameport snd_emu10k1 snd_rawmidi snd_seq_device 
> snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer 
> snd_page_alloc snd_util_mem snd_hwdep snd soundcore e1000 ext3 jbd 
> ata_piix libata sd_mod scsi_mod
> Jan 31 13:57:53 dragon kernel: CPU:    1
> Jan 31 13:57:53 dragon kernel: EIP:    0060:[<e8d36280>]    Tainted: 
> P      VLI
> Jan 31 13:57:53 dragon kernel: EFLAGS: 00213282   (2.6.10-1.741_FC3smp)
> Jan 31 13:57:53 dragon kernel: EIP is at 0xe8d36280
> Jan 31 13:57:53 dragon kernel: eax: 00000000   ebx: eba442e0   ecx: 
> edfcf318   edx: 00203200
> Jan 31 13:57:53 dragon kernel: esi: eba44000   edi: c0160f77   ebp: 
> 00000000   esp: f5a08f00
> Jan 31 13:57:53 dragon kernel: ds: 007b   es: 007b   ss: 0068
> Jan 31 13:57:54 dragon kernel: Process X (pid: 4988,
> threadinfo=f5a08000 
> task=f4c73530)
> Jan 31 13:57:54 dragon kernel: Stack: 00000001 c0161367 00000000 
> Jan 31 13:57:54 dragon kernel: 001fffff 00000000 00000000 00000000
> Jan 31 13:57:54 dragon kernel:        00000015 001fffff f73821cc 
> f73821ac f738218c f738222c f738220c f73821ec
> Jan 31 13:57:54 dragon gconfd (hunt-5320): Received signal 15, shutting 
> down cleanly
> Jan 31 13:57:54 dragon kernel:        000dc2f3 00000055 00000000 
> f5a08f8c f5a08f90 00000055 c0160f95 eba44000
> Jan 31 13:57:54 dragon kernel: Call Trace:
> Jan 31 13:57:54 dragon kernel:  [<c0161367>] do_select+0x298/0x2ac
> Jan 31 13:57:54 dragon gconfd (hunt-5320): Exiting
> Jan 31 13:57:54 dragon kernel:  [<c0160f95>] __pollwait+0x0/0x95
> Jan 31 13:57:54 dragon kernel:  [<c016169b>] sys_select+0x30d/0x49e
> Jan 31 13:57:54 dragon kernel:  [<c012194c>] sys_gettimeofday+0x25/0x55
> Jan 31 13:57:54 dragon kernel:  [<c0103c97>] syscall_call+0x7/0xb