public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* Unable to handle kernel paging request at virtualaddress80000013
  2003-03-27 15:20     ` Henrik Nordstrom
@ 2003-03-27 16:58       ` Eric DEJONC
  2003-03-27 20:19         ` Thomas Gleixner
  0 siblings, 1 reply; 8+ messages in thread
From: Eric DEJONC @ 2003-03-27 16:58 UTC (permalink / raw)
  To: linux-mtd

Thank you all for your help,
I gave the vmlinux file but  compiled with the cross compiler I  think it was
the right think to do, i gave too the system.map and the sykms. The output
seems to denote that the problem comes from the jffs2, driver?

I'd be gratefull to you if you could give me your opinion.

Best regards,
Eric

Internal error: Oops: c1623003
CPU: 0
pc : [<c0095ab4>]    lr : [<80000093>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
sp : c0be3e9c  ip : 80000013  fp : c0be3eec
r10: c0b6b07c  r9 : c1f5392c  r8 : c0b6b21c
Warning (Oops_set_i370_regs): garbage 'r9 : c1f5392c  r8 : c0b6b21c ' at end of
i370 register line ignored
r7 : c0b9a340  r6 : 00000000  r5 : c0b9b100  r4 : c0be3eb8
r3 : 00000044  r2 : 003c0050  r1 : 0001ffb0  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  Segment user
Control: C162317F  Table: C162317F  DAC: 00000015
Process lash (pid: 41, stackpage=c1609360)
Stack: (0xc0be3e8c to 0xc0be4000)
3e80:                            80000093 c0095ab4 80000093 ffffffff 003c000c
3ea0: c0be3eb8 c0be3ebc c0be3ec0 00000007 c0b6b1e0 c0be15e0 00000044 0001ffb0
3ec0: 003c0050 000001a4 c0b6b07c 00000000 c0be15e0 c0be3f60 c0be2000 00000242
3ee0: c0be3f0c c0be3ef0 c006e864 c00958a4 c0be15e0 c0be1560 000001b6 c1f50000
3f00: c0be3f5c c0be3f10 c006ea38 c006e7dc c0042b58 c0be3f20 c0024e80 c0be3f68
3f20: 00000000 00000000 00000002 000001b6 c0be15e0 00000241 00000003 000001b6
3f40: c1f50000 c001d824 c0be2000 00000241 c0be3f8c c0be3f60 c005c778 c006e898
3f60: c0be1560 c02323a0 c1f50005 00000007 329f54fd 00000010 00000000 00000241
3f80: c0be3fac c0be3f90 c005cb88 c005c750 02066eb8 bffffe34 02066e48 00000005
3fa0: 00000000 c0be3fb0 c001d6a0 c005cb50 02066eb8 c0025660 02066e72 00000241
3fc0: 000001b6 00000001 02066eb8 bffffe34 02066e48 00000000 00000000 bffffe24
3fe0: 00000241 bffffee8 400ae1a0 bffffdc4 02021650 400ae1a4 20000010 02066e72
Backtrace: frame pointer underflow
Function entered at [<c0095898>] from [<c006e864>]
Function entered at [<c006e7d0>] from [<c006ea38>]
 r7 = C1F50000  r6 = 000001B6  r5 = C0BE1560  r4 = C0BE15E0
Function entered at [<c006e88c>] from [<c005c778>]
Function entered at [<c005c744>] from [<c005cb88>]
 r4 = 00000241
Function entered at [<c005cb44>] from [<c001d6a0>]
 r7 = 00000005  r6 = 02066E48  r5 = BFFFFE34  r4 = 02066EB8
Code: e50b1030 e10fc000 e38ce080 e121f00e (e59ce000)

>>EIP; c0095ab4 <jffs2_create+21c/58c>   <=====
>>r10; c0b6b07c <_end+996d24/664dd08>
Trace; c0095898 <jffs2_create+0/58c>
Trace; c006e864 <vfs_create+94/bc>
Trace; c006e7d0 <vfs_create+0/bc>
Trace; c006ea38 <open_namei+1ac/79c>
Trace; c006e88c <open_namei+0/79c>
Trace; c005c778 <filp_open+34/50>
Trace; c005c744 <filp_open+0/50>
Trace; c005cb88 <sys_open+44/88>
Trace; c005cb44 <sys_open+0/88>
Trace; c001d6a0 <ret_fast_syscall+0/38>
Code;  c0095aa4 <jffs2_create+20c/58c>
00000000 <_EIP>:
Code;  c0095aa4 <jffs2_create+20c/58c>
   0:   30 10                     xor    %dl,(%eax)
Code;  c0095aa6 <jffs2_create+20e/58c>
   2:   0b e5                     or     %ebp,%esp
Code;  c0095aa8 <jffs2_create+210/58c>
   4:   00 c0                     add    %al,%al
Code;  c0095aaa <jffs2_create+212/58c>
   6:   0f e1 80 e0 8c e3 0e      psraw  0xee38ce0(%eax),%mm0
Code;  c0095ab1 <jffs2_create+219/58c>
   d:   f0 21 e1                  lock and %esp,%ecx
Code;  c0095ab4 <jffs2_create+21c/58c>   <=====
  10:   00 e0                     add    %ah,%al   <=====
Code;  c0095ab6 <jffs2_create+21e/58c>
  12:   9c                        pushf
Code;  c0095ab7 <jffs2_create+21f/58c>
  13:   e5 00                     in     $0x0,%eax

Henrik Nordstrom a ?crit :

> See linux/Documentation/oops-tracing.txt
>
> tor 2003-03-27 klockan 15.16 skrev Eric DEJONC:
> > How can I decode the oops?
> >
> > David Woodhouse a ?crit :
> >
> > > You didn't bother to decode the oops. I can't be bothered to speculate.
> > >
> > > --
> > > dwmw2
> >
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> --
> Henrik Nordstrom <hno@marasystems.com>
> MARA Systems AB
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

* Unable to handle kernel paging request at virtualaddress80000013
  2003-03-27 16:58       ` Unable to handle kernel paging request at virtualaddress80000013 Eric DEJONC
@ 2003-03-27 20:19         ` Thomas Gleixner
  2003-03-31  7:37           ` Eric DEJONC
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Gleixner @ 2003-03-27 20:19 UTC (permalink / raw)
  To: linux-mtd

On Thursday 27 March 2003 17:58, Eric DEJONC wrote:
> Thank you all for your help,
> I gave the vmlinux file but  compiled with the cross compiler I  think it
> was the right think to do, i gave too the system.map and the sykms. The
> output seems to denote that the problem comes from the jffs2, driver?

Could you please try the following:

1. Get current MTD source from MTD-CVS or pick a snapshot.
2. read INSTALL in the base directory of MTD soruce
3. use install.sh in mtd/patches to update your kernel
4. compile and try again
5. report results

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

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

* Unable to handle kernel paging request at virtualaddress80000013
  2003-03-27 20:19         ` Thomas Gleixner
@ 2003-03-31  7:37           ` Eric DEJONC
  2003-03-31  9:02             ` Thomas Gleixner
  0 siblings, 1 reply; 8+ messages in thread
From: Eric DEJONC @ 2003-03-31  7:37 UTC (permalink / raw)
  To: linux-mtd

Hi,

 I have a question....
  What is the physical start adress of flash mapping, and where can I find it.
I get different results if I change this value. In the
arch/arm/machsa1100/trizeps.c, its is written:

static struct map_desc trizeps_io_desc[] __initdata = {
 /* Defines in trizeps.h */
 /* r = read   w = write   c = cache   b = buffer */
 /* virtual     physical    length      domain     r  w  c  b */
 { 0xe8000000, 0x00000000, 0x01000000, DOMAIN_IO, 0, 1, 0, 0 }, /* Flash bank
0, neccessary for mtd */

 { 0xF0000000l, 0x30000000l, 0x00800000l, DOMAIN_IO, 1, 1, 0, 0 },
 { 0xF2000000l, 0x38000000l, 0x00800000l, DOMAIN_IO, 1, 1, 0, 0 },
 LAST_DESC
};

Does it mean that I have to put 0 to the physical start adress of flash
mapping?


I patched the kernel, Here is the error I get when I try to mount the flash
disk.
thank's  in advance
Eric


>>EIP; c00fd654 <cfi_intelext_read_fact_prot_reg+18/94>   <=====
>>r10; ffffffff <END_OF_CODE+397b6148/????>
Trace; c00fd63c <cfi_intelext_read_fact_prot_reg+0/94>
Trace; c009eba8 <jffs2_scan_empty+e4/218>
Trace; c009eac4 <jffs2_scan_empty+0/218>
Trace; c009e27c <jffs2_scan_eraseblock+54/89c>
Trace; c009e228 <jffs2_scan_eraseblock+0/89c>
Trace; c009e02c <jffs2_scan_medium+60/25c>
Trace; c009dfcc <jffs2_scan_medium+0/25c>
Trace; c00a115c <jffs2_build_filesystem+18/1ec>
Trace; c00a1144 <jffs2_build_filesystem+0/1ec>
Trace; c009cffc <jffs2_fill_super+2f4/448>
Trace; c009cd08 <jffs2_fill_super+0/448>
Trace; c0066be8 <get_sb_bdev+29c/310>
Trace; c006694c <get_sb_bdev+0/310>
Trace; c009d2dc <jffs2_get_sb+1c/28>
Trace; c009d2c0 <jffs2_get_sb+0/28>
Trace; c0066de8 <do_kern_mount+58/f4>
Trace; c0066d90 <do_kern_mount+0/f4>
Trace; c007f924 <do_add_mount+94/184>
Trace; c007f890 <do_add_mount+0/184>
Trace; c007fc64 <do_mount+178/18c>
Trace; c007faec <do_mount+0/18c>
Trace; c00804b0 <sys_mount+9c/e4>
Trace; c0080414 <sys_mount+0/e4>
Trace; c001d6a0 <ret_fast_syscall+0/38>
Code;  c00fd644 <cfi_intelext_read_fact_prot_reg+8/94>
00000000 <_EIP>:
Code;  c00fd644 <cfi_intelext_read_fact_prot_reg+8/94>
   0:   04 b0                     add    $0xb0,%al
Code;  c00fd646 <cfi_intelext_read_fact_prot_reg+a/94>
   2:   4c                        dec    %esp
Code;  c00fd647 <cfi_intelext_read_fact_prot_reg+b/94>
   3:   e2 00                     loop   5 <_EIP+0x5> c00fd649
<cfi_intelext_read_fact_prot_reg+d/94>
Code;  c00fd649 <cfi_intelext_read_fact_prot_reg+d/94>
   5:   70 a0                     jo     ffffffa7 <_EIP+0xffffffa7> c00fd5eb
<cfi_intelext_read_user_prot_reg+47/98>
Code;  c00fd64b <cfi_intelext_read_fact_prot_reg+f/94>
   7:   e1 10                     loope  19 <_EIP+0x19> c00fd65d
<cfi_intelext_read_fact_prot_reg+21/94>
Code;  c00fd64d <cfi_intelext_read_fact_prot_reg+11/94>
   9:   d0 4d e2                  rorb   0xffffffe2(%ebp)
Code;  c00fd650 <cfi_intelext_read_fact_prot_reg+14/94>
   c:   84 c0                     test   %al,%al
Code;  c00fd652 <cfi_intelext_read_fact_prot_reg+16/94>
   e:   97                        xchg   %eax,%edi
Code;  c00fd653 <cfi_intelext_read_fact_prot_reg+17/94>   <=====
   f:   e5 38                     in     $0x38,%eax   <=====
Code;  c00fd655 <cfi_intelext_read_fact_prot_reg+19/94>
  11:   00 9c e5 00 00 00 00      add    %bl,0x0(%ebp,8)






Thomas Gleixner a ?crit :

> On Thursday 27 March 2003 17:58, Eric DEJONC wrote:
> > Thank you all for your help,
> > I gave the vmlinux file but  compiled with the cross compiler I  think it
> > was the right think to do, i gave too the system.map and the sykms. The
> > output seems to denote that the problem comes from the jffs2, driver?
>
> Could you please try the following:
>
> 1. Get current MTD source from MTD-CVS or pick a snapshot.
> 2. read INSTALL in the base directory of MTD soruce
> 3. use install.sh in mtd/patches to update your kernel
> 4. compile and try again
> 5. report results
>
> --
> Thomas
> ________________________________________________________________________
> linutronix - competence in embedded & realtime linux
> http://www.linutronix.de
> mail: tglx at linutronix.de
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

* Unable to handle kernel paging request at virtualaddress80000013
  2003-03-31  7:37           ` Eric DEJONC
@ 2003-03-31  9:02             ` Thomas Gleixner
  2003-03-31  9:03               ` Eric DEJONC
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Gleixner @ 2003-03-31  9:02 UTC (permalink / raw)
  To: linux-mtd

On Monday 31 March 2003 09:37, Eric DEJONC wrote:
> Hi,
>
>  I have a question....
>   What is the physical start adress of flash mapping, and where can I find
> it. I get different results if I change this value. In the
> arch/arm/machsa1100/trizeps.c, its is written:
The physical address is defined by your board design. It depends on the 
chipselect, addressdecoding...
The virtual address is the address which is used inside the kernel driver 
code. This address is translated by the MMU into a physical address.
e.g.
MTD driver uses virtual address 0xf0000000 according to chip-mapping. So a 
read from 0xf0000000 is a read from the physical address 0x30000000, which is 
the physical hardware address of the flash chip.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de

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

* Unable to handle kernel paging request at virtualaddress80000013
  2003-03-31  9:02             ` Thomas Gleixner
@ 2003-03-31  9:03               ` Eric DEJONC
  0 siblings, 0 replies; 8+ messages in thread
From: Eric DEJONC @ 2003-03-31  9:03 UTC (permalink / raw)
  To: linux-mtd

ok,
thank you for help, but I still can't mount the jffs2:
I don't understand at all, the error seems to come from the jeddec_probe_chip: I
have not selected in the menuconfig something that contains Jedec!
I have an Intel strataflash chip!



/ # mount -t jffs2 /dev/mtdb2 /mnt
mtdblock_open
jffs2: read_super for device mtdblock(31,2)
jffs2_scan_eraseblock(): Scanning block at 0x0
Unable to handle kernel NULL pointer dereference at virtual address 00000038
pgd = c1424000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: c1427005

here is the decode:
>>r10; ffffffff <END_OF_CODE+397bf3ec/????>
Trace; c00fa5fc <jedec_probe_chip+6f8/f10>
Trace; c009cba8 <jffs2_scan_empty+e4/218>
Trace; c009cac4 <jffs2_scan_empty+0/218>
Trace; c009c27c <jffs2_scan_eraseblock+54/89c>
Trace; c009c228 <jffs2_scan_eraseblock+0/89c>
Trace; c009c02c <jffs2_scan_medium+60/25c>
Trace; c009bfcc <jffs2_scan_medium+0/25c>
Trace; c009f15c <jffs2_build_filesystem+18/1ec>
Trace; c009f144 <jffs2_build_filesystem+0/1ec>
Trace; c009affc <jffs2_fill_super+2f4/448>
Trace; c009ad08 <jffs2_fill_super+0/448>
Trace; c0064be8 <get_sb_bdev+29c/310>
Trace; c006494c <get_sb_bdev+0/310>
Trace; c009b2dc <jffs2_get_sb+1c/28>
Trace; c009b2c0 <jffs2_get_sb+0/28>
Trace; c0064de8 <do_kern_mount+58/f4>
Trace; c0064d90 <do_kern_mount+0/f4>
Trace; c007d924 <do_add_mount+94/184>
Trace; c007d890 <do_add_mount+0/184>
Trace; c007dc64 <do_mount+178/18c>
Trace; c007daec <do_mount+0/18c>
Trace; c007e4b0 <sys_mount+9c/e4>
Trace; c007e414 <sys_mount+0/e4>
Trace; c001b6a0 <ret_fast_syscall+0/38>
Code;  c00fa604 <jedec_probe_chip+700/f10>
00000000 <_EIP>:
Code;  c00fa604 <jedec_probe_chip+700/f10>
   0:   04 b0                     add    $0xb0,%al
Code;  c00fa606 <jedec_probe_chip+702/f10>
   2:   4c                        dec    %esp
Code;  c00fa607 <jedec_probe_chip+703/f10>
   3:   e2 00                     loop   5 <_EIP+0x5> c00fa609
<jedec_probe_chip+705/f10>
Code;  c00fa609 <jedec_probe_chip+705/f10>
   5:   70 a0                     jo     ffffffa7 <_EIP+0xffffffa7> c00fa5ab
<jedec_probe_chip+6a7/f10>
Code;  c00fa60b <jedec_probe_chip+707/f10>
   7:   e1 10                     loope  19 <_EIP+0x19> c00fa61d
<jedec_probe_chip+719/f10>
Code;  c00fa60d <jedec_probe_chip+709/f10>
   9:   d0 4d e2                  rorb   0xffffffe2(%ebp)
Code;  c00fa610 <jedec_probe_chip+70c/f10>
   c:   84 c0                     test   %al,%al
Code;  c00fa612 <jedec_probe_chip+70e/f10>
   e:   97                        xchg   %eax,%edi
Code;  c00fa613 <jedec_probe_chip+70f/f10>   <=====
   f:   e5 38                     in     $0x38,%eax   <=====
Code;  c00fa615 <jedec_probe_chip+711/f10>
  11:   00 9c e5 00 00 00 00      add    %bl,0x0(%ebp,8)







Thomas Gleixner a ?crit :

> On Monday 31 March 2003 09:37, Eric DEJONC wrote:
> > Hi,
> >
> >  I have a question....
> >   What is the physical start adress of flash mapping, and where can I find
> > it. I get different results if I change this value. In the
> > arch/arm/machsa1100/trizeps.c, its is written:
> The physical address is defined by your board design. It depends on the
> chipselect, addressdecoding...
> The virtual address is the address which is used inside the kernel driver
> code. This address is translated by the MMU into a physical address.
> e.g.
> MTD driver uses virtual address 0xf0000000 according to chip-mapping. So a
> read from 0xf0000000 is a read from the physical address 0x30000000, which is
> the physical hardware address of the flash chip.
>
> --
> Thomas
> ________________________________________________________________________
> linutronix - competence in embedded & realtime linux
> http://www.linutronix.de
> mail: tglx at linutronix.de
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

* Unable to handle kernel paging request at virtualaddress80000013
@ 2004-03-25 19:02 Patrick Kam
  2004-03-25 19:39 ` Eric Hammerle
  0 siblings, 1 reply; 8+ messages in thread
From: Patrick Kam @ 2004-03-25 19:02 UTC (permalink / raw)
  To: linux-mtd

Hi Eric, I run into the same problem as you had, but my system is much
simplier.

I've gone thru all the corespondings posted about this problem, but I don't
see any clear answer or solutions. How do you get your problem solved?

Would you like to help?

Thanks


Pat.

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

* Re: Unable to handle kernel paging request at virtualaddress80000013
  2004-03-25 19:02 Unable to handle kernel paging request at virtualaddress80000013 Patrick Kam
@ 2004-03-25 19:39 ` Eric Hammerle
  2004-03-25 20:04   ` David Woodhouse
  0 siblings, 1 reply; 8+ messages in thread
From: Eric Hammerle @ 2004-03-25 19:39 UTC (permalink / raw)
  To: linux-mtd

> Hi Eric, I run into the same problem as you had, but my system is much
> simplier.

I'm not sure which Eric you're referring to, but if it's any help, I fixed
my
alignment problem by forcing a four byte alignment of the name field in
the definition of the struct jffs2_full_dirent in file nodelist.h.

I suppose a diff would look something like this:

- unsigned char name[0];
+ unsigned char name[0] __attribute__ ((align(4)));

I'm not sure if this is the recommended fix for the alignment issues, but it
worked for me.

If, of course, you were referring to the other Eric on this board, ignore
this
post, but anyone with an ARM7TDMI might want to look this way.

-E

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

* Re: Unable to handle kernel paging request at virtualaddress80000013
  2004-03-25 19:39 ` Eric Hammerle
@ 2004-03-25 20:04   ` David Woodhouse
  0 siblings, 0 replies; 8+ messages in thread
From: David Woodhouse @ 2004-03-25 20:04 UTC (permalink / raw)
  To: Eric Hammerle; +Cc: linux-mtd

On Thu, 2004-03-25 at 14:39 -0500, Eric Hammerle wrote:
> 
> I suppose a diff would look something like this:
> 
> - unsigned char name[0];
> + unsigned char name[0] __attribute__ ((align(4)));
> 
> I'm not sure if this is the recommended fix for the alignment issues, but it
> worked for me.

That'll work but at a cost of taking up extra RAM. If you're going to
try that, make sure you also include the latest patch I committed to
v1.98 of file.c. That eliminates another unaligned write.

You might do better to use get_unaligned() in the flash chip driver when
reading from the buffer though.

-- 
dwmw2

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

end of thread, other threads:[~2004-03-25 20:05 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-25 19:02 Unable to handle kernel paging request at virtualaddress80000013 Patrick Kam
2004-03-25 19:39 ` Eric Hammerle
2004-03-25 20:04   ` David Woodhouse
  -- strict thread matches above, loose matches on Subject: below --
2003-03-27 14:00 Unable to handle kernel paging request at virtual address 80000013 Eric DEJONC
2003-03-27 14:12 ` David Woodhouse
2003-03-27 14:16   ` Unable to handle kernel paging request at virtual address80000013 Eric DEJONC
2003-03-27 15:20     ` Henrik Nordstrom
2003-03-27 16:58       ` Unable to handle kernel paging request at virtualaddress80000013 Eric DEJONC
2003-03-27 20:19         ` Thomas Gleixner
2003-03-31  7:37           ` Eric DEJONC
2003-03-31  9:02             ` Thomas Gleixner
2003-03-31  9:03               ` Eric DEJONC

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