public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* NAND flash driver x86 port problem
@ 2001-09-12  6:55 Kim Jong-chan
  2001-09-13  5:53 ` Self Answer & NAND driver wait queue init problem Kim Jong-chan
  0 siblings, 1 reply; 3+ messages in thread
From: Kim Jong-chan @ 2001-09-12  6:55 UTC (permalink / raw)
  To: linux-mtd

Recent days, I have ported MTD NAND flash driver to x86, using GeodeGX board.
Module loading is ok. But, when I try to access NAND device, The Kernel says 
what follows and go away...
Using ksymoops, I found that kernel dies in __wake_up.
But I don't know actually which variable causes Null pointer dereferencing.
If I remove all wake_up in nand.c intentionally, all works file. But, I think
that's not a solution.  
Tested kernel includes 
2.4.9(vanilla) 
2.4.2(redhat) + mtd snapshot(20010906)
2.4.2_hhl20(hard hat linux)
all above kernel shows the same phenomenon. 

Here goes oops message

Unable to handle kernel NULL pointer dereference at virtual address 00000000    
 printing eip:                                                                  
c010eeb3                                                                        
*pde = 00000000                                                                 
Oops: 0000                                                                      
CPU:    0                                                                       
EIP:    0010:[<c010eeb3>]                                                       
EFLAGS: 00010013                                                                
eax: c12eddf4   ebx: 00000000   ecx: 00000001   edx: c12eddf8                   
esi: 00000001   edi: fffffff8   ebp: c6c6fefc   esp: c6c6fee0                   
ds: 0018   es: 0018   ss: 0018                                                  
Process mke2fs (pid: 570, stackpage=c6c6f000)                                   
Stack: c12eddf8 00000001 00000282 00000003 00000001 00000001 c12edddc c028d7c8  
       c881282d 00000000 c6c6e000 00000000 00000000 00000000 c6c6e000 00000000  
       00000000 c76c5628 c76c5620 00000000 fffffff4 c01a9dba c12edd60 c6d37bc0  
Call Trace: [<c881282d>] [<c01a9dba>] [<c0134c52>] [<c012e4a9>] [<c012d4e5>]    
   [<c012d533>] [<c0106d23>]                                                    
                                                                                
Code: 8b 1b 8b 4f 04 8b 01 85 45 f0 74 54 31 c0 9c 5e fa c7 01 00               
Kernel panic: Aiee, killing interrupt handler!                                  
In interrupt handler - not syncing                 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Self Answer & NAND driver wait queue init problem
  2001-09-12  6:55 NAND flash driver x86 port problem Kim Jong-chan
@ 2001-09-13  5:53 ` Kim Jong-chan
  2002-01-22 14:30   ` Elizabeth Clarke
  0 siblings, 1 reply; 3+ messages in thread
From: Kim Jong-chan @ 2001-09-13  5:53 UTC (permalink / raw)
  To: linux-mtd

Finally, I've solved the problem.
The answer is that wq of struct nand_chip is not initialized.
So I suggest... nand_scan() in nand.c

    /* Initialize state and spinlock */
    this->state = FL_READY;
    spin_lock_init(&this->chip_lock);

    /* Initialize wait queue : fixed by Adelinux */
>   init_waitqueue_head(&this->wq);

    /* De-select the device */
    nand_deselect ();

I've looked up MTD drivers code of other chips. And I think wq must be 
initialized. Otherwise, wake_up will kill the system.

On Wed, Sep 12, 2001 at 03:55:04PM +0900, Kim Jong-chan wrote:
> Recent days, I have ported MTD NAND flash driver to x86, using GeodeGX board.
> Module loading is ok. But, when I try to access NAND device, The Kernel says 
> what follows and go away...
> Using ksymoops, I found that kernel dies in __wake_up.
> But I don't know actually which variable causes Null pointer dereferencing.
> If I remove all wake_up in nand.c intentionally, all works file. But, I think
> that's not a solution.  
> Tested kernel includes 
> 2.4.9(vanilla) 
> 2.4.2(redhat) + mtd snapshot(20010906)
> 2.4.2_hhl20(hard hat linux)
> all above kernel shows the same phenomenon. 
> 
> Here goes oops message
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000000    
>  printing eip:                                                                  
> c010eeb3                                                                        
> *pde = 00000000                                                                 
> Oops: 0000                                                                      
> CPU:    0                                                                       
> EIP:    0010:[<c010eeb3>]                                                       
> EFLAGS: 00010013                                                                
> eax: c12eddf4   ebx: 00000000   ecx: 00000001   edx: c12eddf8                   
> esi: 00000001   edi: fffffff8   ebp: c6c6fefc   esp: c6c6fee0                   
> ds: 0018   es: 0018   ss: 0018                                                  
> Process mke2fs (pid: 570, stackpage=c6c6f000)                                   
> Stack: c12eddf8 00000001 00000282 00000003 00000001 00000001 c12edddc c028d7c8  
>        c881282d 00000000 c6c6e000 00000000 00000000 00000000 c6c6e000 00000000  
>        00000000 c76c5628 c76c5620 00000000 fffffff4 c01a9dba c12edd60 c6d37bc0  
> Call Trace: [<c881282d>] [<c01a9dba>] [<c0134c52>] [<c012e4a9>] [<c012d4e5>]    
>    [<c012d533>] [<c0106d23>]                                                    
>                                                                                 
> Code: 8b 1b 8b 4f 04 8b 01 85 45 f0 74 54 31 c0 9c 5e fa c7 01 00               
> Kernel panic: Aiee, killing interrupt handler!                                  
> In interrupt handler - not syncing                 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Self Answer & NAND driver wait queue init problem
  2001-09-13  5:53 ` Self Answer & NAND driver wait queue init problem Kim Jong-chan
@ 2002-01-22 14:30   ` Elizabeth Clarke
  0 siblings, 0 replies; 3+ messages in thread
From: Elizabeth Clarke @ 2002-01-22 14:30 UTC (permalink / raw)
  To: linux-mtd

Kim Jong-chan wrote back in september last year!:
> Finally, I've solved the problem.
> The answer is that wq of struct nand_chip is not initialized.
> So I suggest... nand_scan() in nand.c
> 
>     /* Initialize state and spinlock */
>     this->state = FL_READY;
>     spin_lock_init(&this->chip_lock);
> 
>     /* Initialize wait queue : fixed by Adelinux */
> >   init_waitqueue_head(&this->wq);
> 
>     /* De-select the device */
>     nand_deselect ();
> 
> I've looked up MTD drivers code of other chips. And I think wq must be
> initialized. Otherwise, wake_up will kill the system.

I've just been caught by this too, so the/a fix didn't get into CVS...
Is Kim's fix a good one, if so can someone check it in please? If it
isn't what is the Right Thing to do?....


Beth

-- 
Chief Engineer - Software
Amino Communications Ltd
01954 784523 (Direct Line)

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-01-22 14:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-12  6:55 NAND flash driver x86 port problem Kim Jong-chan
2001-09-13  5:53 ` Self Answer & NAND driver wait queue init problem Kim Jong-chan
2002-01-22 14:30   ` Elizabeth Clarke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox