2.5.50 hang when copying files, handwritten trace included

2.5.50 hang when copying files, handwritten trace included

[Helge Hafting]

2.5.50 hung when copying 800M.
mke2fs on a 10G partition, then try to copy
the entire /home there. Source and destionation
was on the same disk. After a while, this happened:

EIP: wake_up_forked_process+0xb8/0x18c
EAX: 5a5a5a5a   (suspicious)

trace:
do_fork
kernel_thread
pdflush
kernel_thread_helper
start_one_pdflush_thread
pdflush
__pdflush
__pdflush
background_writeout
kernel_thread_helper


The machine has 512M ram. It is a pentium IV 2.4GHz.
The kernel is compiled with smp (hoping for hyperthreading
but it haven't happened yet), preempt, devfs support (but
devfs isn't mounted anywhere currently) and IDE driver
for the SIS 5513.  

Both filesystems are ext2. The machine was in
single-user mode at the time.  I can reliably
reproduce this if a more detailed oops 
will help in debugging. I have 2G of swap space
on another IDE drive.

compiled with gcc 2.95.4 from debian testing

ide controller:
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]

I'm using dma, irq unmasking, 32-bit io and multiple 
sector transfers.

Helge Hafting

Re: 2.5.50 hang when copying files, handwritten trace included

[Andrew Morton]

Helge Hafting wrote:
> 
> 2.5.50 hung when copying 800M.
> mke2fs on a 10G partition, then try to copy
> the entire /home there. Source and destionation
> was on the same disk. After a while, this happened:
> 
> EIP: wake_up_forked_process+0xb8/0x18c
> EAX: 5a5a5a5a   (suspicious)
> 
> trace:
> do_fork
> kernel_thread
> pdflush
> kernel_thread_helper
> start_one_pdflush_thread
> pdflush
> __pdflush
> __pdflush
> background_writeout
> kernel_thread_helper
> 

Yes please - if you could gather sufficient info to enable
us to determine what eax is pointing at in wake_up_forked_process(),
that would help.  Presumably it's the new process, which is rather
bizarre.

Also, does disabling preemption make it stop?

Thanks.

Re: 2.5.50 hang when copying files, handwritten trace included

[Helge Hafting]

Andrew Morton wrote:

> Yes please - if you could gather sufficient info to enable
> us to determine what eax is pointing at in wake_up_forked_process(),
> that would help.  Presumably it's the new process, which is rather
> bizarre.

Here's all the details.  Please tell if there is anything more I can
do with it. I simply don't know how to find "what line number in the
code"
or which variable maps to what register. But I have done programming
before and can follow instructions. Note that the .o files for this
build isn't around - I have patched the source tree after
booting but before this happened.

The first part probably scrolled off the screen, here is what I got:

EIP: 0060:[<c0119238>] Not tainted
EFLAGS: 00010086
EIP is at wake_up_forked_process+0xb8/0x18c
eax: 5a5a5a5a  ebx: c151da80  ecx: 0159f48d  edx: 00000000
esi: c0469d00  edi: 51eb851f  ebp: dfdd5f18  esp: dfdd5f08
ds:0068  es:0068  ss:0068

Process pdflush (pid:7 threadinfo=dfdd4000 task=c151ce00)

Stack: 00000000 c151da80 00000000 c0469d00 dfdd5fe4 c011e62a
       00000000 00000000 dfdd5f70 000002f2 000001dc 00000db4
       00000000 00000000 c0106fa1 00800f00 00000000 dfdd5f70
       00000000 00000000 00000000 dfdd5fd8 c03c53d4 dfdd4000

Call trace:

[<c011e62a>] do_fork+0xe2/0x138
[<c0106fa1>] kernel_thread+0x79/0x90
[<c01455b8>] pdflush+0x0/0x14
[<c0106f1c>] kernel_thread_helper+0x0/0xc
[<c0145719>] start_one_pdflush_thread+0x11/0x5
[<c01455b8>] pdflush+0x0/0x14
[<c01454d8>] __pdflush+0x0/0x14
[<c01455b8>] pdflush+0x0/0x14
[<c01455c3>] pdflush+0xb/0x14
[<c01459b8>] background_writeout+0x0/0xbc
[<c0106f21>] kernel_thread_helper+0x5/0xc

Code 89 50 0c 8b 55 fc a1 84
     58 4c c0 2b 43 30 8b 7a
     20 83 7b 18



> Also, does disabling preemption make it stop?

I'll run a test - later.

Helge Hafting