gumstix

mark gross writes:
 > I've looked over the similar bug report 
 > https://sourceforge.net/mailarchive/forum.php?thread_id=6382316&forum_id=38940
 > 
 > I've checked the u-boot versions, they are good.  I got my gumstix 
 > 400Mhz-f last week.
 > 
 > root file system r162 from sourceforge works fine, where the build from 
 > the trunk tip crashes at boot time.
 > 
 > Does anyone know what the problem with the trunk tip is?
 > 
 > Or, if its just my gumstix (or just me) could I have a bad flash part?  
 > It does seem to be hanging in the JFFS2 code.


I have the same problem with r342 with very similar crash messages. I
also tried r306 last night after reading the same message you mention
above and it is working fine. r162 also works fine.

Since some people seem to have no problems with r342 are there some
batches of gumstix with slightly different parts which do not like 
one of the changes between r306 and r342? Or do we all have defective 
memories?

If I have the time I will do a binary search to find the release where
it breaks, but this can take a while ....

On Jan 25, 2005, at 1:43 AM, Ralph Metzler wrote:

> mark gross writes:
>> I've looked over the similar bug report
>> https://sourceforge.net/mailarchive/forum.php? 
>> thread_id=6382316&forum_id=38940
>>
>> I've checked the u-boot versions, they are good.  I got my gumstix
>> 400Mhz-f last week.
>>
>> root file system r162 from sourceforge works fine, where the build  
>> from
>> the trunk tip crashes at boot time.
>>
>> Does anyone know what the problem with the trunk tip is?
>>
>> Or, if its just my gumstix (or just me) could I have a bad flash part?
>> It does seem to be hanging in the JFFS2 code.
>
>
> I have the same problem with r342 with very similar crash messages. I
> also tried r306 last night after reading the same message you mention
> above and it is working fine. r162 also works fine.
>
> Since some people seem to have no problems with r342 are there some
> batches of gumstix with slightly different parts which do not like
> one of the changes between r306 and r342? Or do we all have defective
> memories?
>
> If I have the time I will do a binary search to find the release where
> it breaks, but this can take a while ....

One change I made recently in the trunk is to update the mtd-utils used  
by the build.  I did this because of an error almost exactly like the  
one you're showing, where the JFFS created by the buildroot was said to  
be corrupt by the kernel, even though u-boot thought it was just fine.   
In 2.6.10, the JFFS2 driver in the kernel had some changes which I  
think make it a lot more sensitive to "bad" filesystem images than it  
had been.  For me, the problem went away with the mtd-utils update, and  
some changes to the device-table.txt file which mkfs.jffs2 uses.  I  
think thought there are still some pretty bad bugs in mtd-utils which  
cause it to create "bad" jffs2 images, and this is now showing itself  
due to the changes in the kernel jffs2 driver.  I thiink the solution  
is probably to go in and fix mtd-utils to produce correct images (which  
as a side-benefit I believe will make the images smaller, since the  
stupid tool is copying files in the image so they're located in two or  
more places in some cases).  I'll take a look at this with fairly high  
priority, since it seems to be causing problems for several of you out  
there.  I can't promise a fix in the immediate future though, because I  
have quite a bit of other stuff on my plate at the moment.  Might be  
worth checking out any mailing list etc for the mtd-utils project to  
see if they're discussing this issue -- must have cropped up for other  
people with the new kernel.  What seems a little odd to me is that the  
kernel developers are apparently not using mtd-utils to create their  
jffs2 filesystems, or they'd surely have noticed this before releasing  
2.6.10...

C

Ralph Metzler wrote:

>mark gross writes:
> > I've looked over the similar bug report 
> > https://sourceforge.net/mailarchive/forum.php?thread_id=6382316&forum_id=38940
> > 
> > I've checked the u-boot versions, they are good.  I got my gumstix 
> > 400Mhz-f last week.
> > 
> > root file system r162 from sourceforge works fine, where the build from 
> > the trunk tip crashes at boot time.
> > 
> > Does anyone know what the problem with the trunk tip is?
> > 
> > Or, if its just my gumstix (or just me) could I have a bad flash part?  
> > It does seem to be hanging in the JFFS2 code.
>
>
>I have the same problem with r342 with very similar crash messages. I
>also tried r306 last night after reading the same message you mention
>above and it is working fine. r162 also works fine.
>
>Since some people seem to have no problems with r342 are there some
>batches of gumstix with slightly different parts which do not like 
>one of the changes between r306 and r342? Or do we all have defective 
>memories?
>
>If I have the time I will do a binary search to find the release where
>it breaks, but this can take a while ....
>
>  
>
I'll bet its the build that uses 2.6.10 kernel.

--mgross

Craig Hughes wrote:

> On Jan 25, 2005, at 1:43 AM, Ralph Metzler wrote:
>
>> mark gross writes:
>>
>>> I've looked over the similar bug report
>>> https://sourceforge.net/mailarchive/forum.php? 
>>> thread_id=6382316&forum_id=38940
>>>
>>> I've checked the u-boot versions, they are good.  I got my gumstix
>>> 400Mhz-f last week.
>>>
>>> root file system r162 from sourceforge works fine, where the build  
>>> from
>>> the trunk tip crashes at boot time.
>>>
>>> Does anyone know what the problem with the trunk tip is?
>>>
>>> Or, if its just my gumstix (or just me) could I have a bad flash part?
>>> It does seem to be hanging in the JFFS2 code.
>>
>>
>>
>> I have the same problem with r342 with very similar crash messages. I
>> also tried r306 last night after reading the same message you mention
>> above and it is working fine. r162 also works fine.
>>
>> Since some people seem to have no problems with r342 are there some
>> batches of gumstix with slightly different parts which do not like
>> one of the changes between r306 and r342? Or do we all have defective
>> memories?
>>
>> If I have the time I will do a binary search to find the release where
>> it breaks, but this can take a while ....
>
>
> One change I made recently in the trunk is to update the mtd-utils 
> used  by the build.  I did this because of an error almost exactly 
> like the  one you're showing, where the JFFS created by the buildroot 
> was said to  be corrupt by the kernel, even though u-boot thought it 
> was just fine.   In 2.6.10, the JFFS2 driver in the kernel had some 
> changes which I  think make it a lot more sensitive to "bad" 
> filesystem images than it  had been.  For me, the problem went away 
> with the mtd-utils update, and  some changes to the device-table.txt 
> file which mkfs.jffs2 uses.  I  think thought there are still some 
> pretty bad bugs in mtd-utils which  cause it to create "bad" jffs2 
> images, and this is now showing itself  due to the changes in the 
> kernel jffs2 driver.  I thiink the solution  is probably to go in and 
> fix mtd-utils to produce correct images (which  as a side-benefit I 
> believe will make the images smaller, since the  stupid tool is 
> copying files in the image so they're located in two or  more places 
> in some cases).  I'll take a look at this with fairly high  priority, 
> since it seems to be causing problems for several of you out  there.  
> I can't promise a fix in the immediate future though, because I  have 
> quite a bit of other stuff on my plate at the moment.  Might be  worth 
> checking out any mailing list etc for the mtd-utils project to  see if 
> they're discussing this issue -- must have cropped up for other  
> people with the new kernel.  What seems a little odd to me is that 
> the  kernel developers are apparently not using mtd-utils to create 
> their  jffs2 filesystems, or they'd surely have noticed this before 
> releasing  2.6.10...
>
> C
>
So if I patch my build with a new mtd_ulits I may have better luck?  
What is the URL for the mtd tar balls?

The nagging question I have is why is this problem effecting some folks 
but not others, like yourself perhaps? 

I'm building my root fs on a Mandrake 10.1 system.  What are folks whom 
are having good luck building there root_fs_arm on?

--mgross

On Jan 26, 2005, at 7:14 PM, mark gross wrote:
> The nagging question I have is why is this problem effecting some 
> folks but not others, like yourself perhaps?
> I'm building my root fs on a Mandrake 10.1 system.  What are folks 
> whom are having good luck building there root_fs_arm on?

SUSE 9.2

On Jan 27, 2005, at 12:28 PM, Darren Gibbs wrote:

>
> On Jan 26, 2005, at 7:14 PM, mark gross wrote:
>> The nagging question I have is why is this problem effecting some 
>> folks but not others, like yourself perhaps?
>> I'm building my root fs on a Mandrake 10.1 system.  What are folks 
>> whom are having good luck building there root_fs_arm on?
>
> SUSE 9.2

Works good for me on latest gentoo

C

On Jan 26, 2005, at 6:54 PM, mark gross wrote:

> I'll bet its the build that uses 2.6.10 kernel.

I think this is us:

http://lists.infradead.org/pipermail/linux-mtd/2004-November/010939.html

There's a patch in there which I'll check now.  I haven't been seeing 
the problem recently though, so I may need to get someone else to test 
it for me once I've got the thing built.  If someone who's seeing this 
problem is online and available to try this out, please could you IM me 
on AIM at hugh3scr

Thanks

C

On Jan 26, 2005, at 7:14 PM, mark gross wrote:

> So if I patch my build with a new mtd_ulits I may have better luck?  
> What is the URL for the mtd tar balls?

I just committed updates which might fix this problem.  Basically, 
newer version of MTD, and also copying the MTD jffs2 driver into the 
kernel tree before building the kernel.  It works for me, but then the 
old one worked for me too.  Please let me know if this does not solve 
the problem, for those of you who are having problems.

C

Hi,

SUSE 9.1 works also - but haven't compiled the latest build.
I'm a bit worried that my device will break...

Will eventually buy a Mac Mini to do my development for the gum.
Has anyone a howto for Mac OSX?

Regards
Robert
----- Original Message ----- 
From: "Craig Hughes" <craig@...>
To: <gumstix-users@...>
Sent: Thursday, January 27, 2005 11:23 PM
Subject: Re: [Gumstix-users] trunk tip builds but fails to run.


> On Jan 27, 2005, at 12:28 PM, Darren Gibbs wrote:
> 
>>
>> On Jan 26, 2005, at 7:14 PM, mark gross wrote:
>>> The nagging question I have is why is this problem effecting some 
>>> folks but not others, like yourself perhaps?
>>> I'm building my root fs on a Mandrake 10.1 system.  What are folks 
>>> whom are having good luck building there root_fs_arm on?
>>
>> SUSE 9.2
> 
> Works good for me on latest gentoo
> 
> C

Hi Craig,

I tried a new and clean set of stuff for gumstix-buildroot (r344), and 
it failed upon bootup for me.  I'm compiling on Fedora Core 2 (with most 
updates).  The errors seemed a little different as far as their content 
goes, but it happens at exactly the same place in the boot sequence 
(i.e. right after mounting the jffs2 partition and freeing init 
memory).  Here's my error for today:

<snip>
Creating 2 MTD partitions on "Gumstix Flash ROM":
0x00000000-0x00040000 : "Bootloader"
0x00040000-0x00400000 : "RootFS"
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 56K
/sbin/init: can't resolve symbol 'reboot'
Unable to handle kernel paging request at virtual address ffffffc4
pgd = c3c14000
[ffffffc4] *pgd=a0002001, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1]
<snip>

If you want to send my your rootfs image, I can try it out and see if it 
works on my board.  That might give a clue as to whether the problem is 
related to differences in board hardware or build environment.

Thanks,

Jim Walters

Craig Hughes wrote:

> On Jan 26, 2005, at 7:14 PM, mark gross wrote:
>
>> So if I patch my build with a new mtd_ulits I may have better luck?  
>> What is the URL for the mtd tar balls?
>
>
> I just committed updates which might fix this problem.  Basically, 
> newer version of MTD, and also copying the MTD jffs2 driver into the 
> kernel tree before building the kernel.  It works for me, but then the 
> old one worked for me too.  Please let me know if this does not solve 
> the problem, for those of you who are having problems.
>
> C
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

Craig Hughes wrote:

> On Jan 26, 2005, at 6:54 PM, mark gross wrote:
>
>> I'll bet its the build that uses 2.6.10 kernel.
>
>
> I think this is us:
>
> http://lists.infradead.org/pipermail/linux-mtd/2004-November/010939.html
>
> There's a patch in there which I'll check now.  I haven't been seeing 
> the problem recently though, so I may need to get someone else to test 
> it for me once I've got the thing built.  If someone who's seeing this 
> problem is online and available to try this out, please could you IM 
> me on AIM at hugh3scr
>
> Thanks
>
> C 

I tried to build it last night, but my code base was hacked up a bit 
from my own experiments and the svn update + make failed.  So rather 
than debug that I nucked my tree and pulled down a fresh one.  I just 
kicked off a build on the 344 tip.  It won't be finished until I get 
back from work.

I'll let you know what happens.

On Jan 28, 2005, at 6:35 AM, Jim Walters wrote:

> <snip>
> Creating 2 MTD partitions on "Gumstix Flash ROM":
> 0x00000000-0x00040000 : "Bootloader"
> 0x00040000-0x00400000 : "RootFS"
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind 8192)
> VFS: Mounted root (jffs2 filesystem).
> Freeing init memory: 56K
> /sbin/init: can't resolve symbol 'reboot'
> Unable to handle kernel paging request at virtual address ffffffc4
> pgd = c3c14000
> [ffffffc4] *pgd=a0002001, *pte=00000000, *ppte=00000000
> Internal error: Oops: 7 [#1]
> <snip>

Jim,

can you please post the complete Oops trace -- hard to tell from just 
this snippet what's going wrong where.

Thanks

C

On Jan 28, 2005, at 6:39 AM, mark gross wrote:

> Craig Hughes wrote:
>
>> On Jan 26, 2005, at 6:54 PM, mark gross wrote:
>>
>>> I'll bet its the build that uses 2.6.10 kernel.
>>
>>
>> I think this is us:
>>
>> http://lists.infradead.org/pipermail/linux-mtd/2004-November/ 
>> 010939.html
>>
>> There's a patch in there which I'll check now.  I haven't been seeing  
>> the problem recently though, so I may need to get someone else to  
>> test it for me once I've got the thing built.  If someone who's  
>> seeing this problem is online and available to try this out, please  
>> could you IM me on AIM at hugh3scr
>>
>> Thanks
>>
>> C
>
> I tried to build it last night, but my code base was hacked up a bit  
> from my own experiments and the svn update + make failed.  So rather  
> than debug that I nucked my tree and pulled down a fresh one.  I just  
> kicked off a build on the 344 tip.  It won't be finished until I get  
> back from work.
>
> I'll let you know what happens.

NP.  I'm so used to my 10-minute builds that I forget it can take a lot  
longer :)

btw a useful trick which I use is to keep the source/dl directory with  
all the tarballs in it in some shared place and symlink it anytime I  
create a new buildroot tree, so that I don't have to keep redoing all  
the downloads.

C

Hi Craig,

I re-ran the boot image that gives me errors, and it looks different 
this time.  In fact, each time I power down and back up again there's a 
completely different address, and sometimes even different error texts.  
Sometimes, it keeps looping with the same oops dump and never fully 
panics and stops.  Here's the full list of one that stops eventually:

U-Boot 1.1.1 (Oct  3 2004 - 21:30:21)
                                     
*** Welcome to Gumstix ***
                          
U-Boot code: A3F00000 -> A3F1B01C  BSS: -> A3F4CB54
RAM Configuration:
Bank #0: a0000000 64 MB
erase_region_count = 32 erase_region_size = 131072
Flash:  4 MB
Hit any key to stop autoboot:  0
### JFFS2 loading 'boot/uImage' to 0xa2000000
Scanning JFFS2 FS: ..... done.
### JFFS2 load complete: 702828 bytes loaded to 0xa2000000
## Booting image at a2000000 ...
   Image Name:   uImage
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    702764 Bytes = 686.3 kB
   Load Address: a0008000
   Entry Point:  a0008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
                                    
Starting kernel ...
                   
Uncompressing Linux................................................ 
done, booting the kernel.
Linux version 2.6.10gum (root@...) (gcc version 3.4.2) 
#1 Fri Jan 28 06:56:39 CST 2005
CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE)
CPU: D VIVT undefined 5 cache
CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Machine: The Gumstix Platform
Memory policy: ECC disabled, Data cache writeback
Memory clock: 99.53MHz (*27)
Run Mode clock: 398.13MHz (*4)
Turbo Mode clock: 398.13MHz (*1.0, inactive)
Built 1 zonelists
Kernel command line: console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 
reboot=cold,hard video=pxafb:mode:800x600-16,active
PID hash table entries: 512 (order: 9, 8192 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 64MB = 64MB total
Memory: 63360KB available (1182K code, 224K data, 56K init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
PXA CPU frequency change support initialized
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
ttyS0 at MMIO 0x40100000 (irq = 15) is a FFUART
ttyS1 at MMIO 0x40200000 (irq = 14) is a BTUART
ttyS2 at MMIO 0x40700000 (irq = 13) is a STUART
ttyS3 at MMIO 0x41600000 (irq = 0) is a HWUART
io scheduler noop registered
elevator: using noop as default io scheduler
physmap flash device: 400000 at 0
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth)
Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank
 Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Using static partitions on Gumstix Flash ROM
Creating 2 MTD partitions on "Gumstix Flash ROM":
0x00000000-0x00040000 : "Bootloader"
0x00040000-0x00400000 : "RootFS"
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
VFS: Mounted root (jffs2 filesystem).
Freeing init memory: 56K
Unhandled fault: imprecise external abort (0x406) at 0x00096d08
pgd = c3c10000
[00096d08] *pgd=a03ad011, *pte=a3c160ff, *ppte=a3c1603f
kernel BUG at mm/rmap.c:483!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 807 [#1]
Modules linked in:
CPU: 0
PC is at __bug+0x40/0x54
LR is at 0x1
pc : [<c001b1d4>]    lr : [<00000001>]    Not tainted
sp : c02f3d9c  ip : 60000093  fp : c02f3dac
r10: a02c005f  r9 : c3c1d000  r8 : 0003f000
r7 : 40038000  r6 : 00022000  r5 : 00000000  r4 : 00000000
r3 : 00000000  r2 : 00000000  r1 : 60000013  r0 : 00000001
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A3C1C000  DAC: 00000015
Process init (pid: 61, stack limit = 0xc02f2190)
Stack: (0xc02f3d9c to 0xc02f4000)
3d80:                                                                
c017d800
3da0: c02f3dc0 c02f3db0 c0056ee8 c001b1a0 c017d800 c02f3e28 c02f3dc4 
c0050efc
3dc0: c0056e90 c3c0b968 40238000 40077000 c3c1d000 40077000 c016a424 
0003f000
3de0: 40077000 00000000 0000000e 00344000 00000000 c0009b50 c000dae0 
c02f3e3c
3e00: c000dae0 00000000 00000001 00000001 0000000b c02f2000 c02f3fb0 
c02f3e58
3e20: c02f3e2c c0055190 c0050b68 ffffffff c02f3e38 00000000 0000007c 
c016a424
3e40: c000dae0 c000db0c c0282060 c02f3e6c c02f3e5c c00289f0 c0055138 
c000dae0
3e60: c02f3e8c c02f3e70 c002c834 c00289bc c0282260 c02f3fb0 0000000b 
c02f2000
3e80: c02f3ea0 c02f3e90 c002d31c c002c69c 0000000b c02f3ecc c02f3ea4 
c0035d6c
3ea0: c002d294 c02f2000 00000000 c02f3fb0 00000000 00000000 c02f3ef0 
4007f15c
3ec0: c02f3fac c02f3ed0 c0019f98 c0035aa8 1f0daf84 c017e820 c017fce0 
4007f000
3ee0: c0282260 c02f3ef0 c0051950 c0056d0c 0000000b 00000000 00030001 
1f0daf84
3f00: c017e820 c017fce0 4007f000 c02f3f18 c02f3f1c c0052460 c0051718 
c3c1d000
3f20: a03410df c3c1c000 00001000 c0282060 ffffffeb 4007f8d0 c0009a54 
c000dae0
3f40: c02f3fb0 c0282060 c02f3f88 c02f3f58 c001cd4c c001cb1c c02f3fb0 
c000db0c
3f60: 000000f5 c02f3fec c0141380 1f0daf84 c02f3fb0 00000ae8 4007f15c 
c02f3fac
3f80: c02f3f8c ffffffff c02f3fec 0000000a 0000397f 00000000 c02f2000 
4007f15c
3fa0: 00000000 c02f3fb0 c00168ec c0019f3c befff668 befff66c 4005aff8 
00000000
3fc0: 1f0daf84 befff5dc 0000000a 00000001 000981a0 00000ae8 4007f15c 
00000000
3fe0: 4005af84 befff4b0 4005b018 4005b004 20000010 ffffffff 00000000 
00000000
Backtrace:
[<c001b194>] (__bug+0x0/0x54) from [<c0056ee8>] (page_remove_rmap+0x64/0x94)
 r4 = C017D800
[<c0056e84>] (page_remove_rmap+0x0/0x94) from [<c0050efc>] 
(unmap_vmas+0x3a0/0x58c)
 r4 = C017D800
[<c0050b5c>] (unmap_vmas+0x0/0x58c) from [<c0055190>] (exit_mmap+0x64/0x16c)
[<c005512c>] (exit_mmap+0x0/0x16c) from [<c00289f0>] (mmput+0x40/0xa8)
 r6 = C0282060  r5 = C000DB0C  r4 = C000DAE0
[<c00289b0>] (mmput+0x0/0xa8) from [<c002c834>] (do_exit+0x1a4/0xbc0)
 r4 = C000DAE0
[<c002c690>] (do_exit+0x0/0xbc0) from [<c002d31c>] (do_group_exit+0x94/0x9c)
[<c002d288>] (do_group_exit+0x0/0x9c) from [<c0035d6c>] 
(get_signal_to_deliver+0x2d0/0x2f4)
 r4 = 0000000B
[<c0035a9c>] (get_signal_to_deliver+0x0/0x2f4) from [<c0019f98>] 
(do_signal+0x68/0x4b8)
[<c0019f30>] (do_signal+0x0/0x4b8) from [<c00168ec>] 
(work_pending+0x1c/0x24)
Code: 1b003feb e59f0014 eb003fe9 e3a03000 (e5833000)
 <2>kernel BUG at mm/mmap.c:708!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c3c28000
[00000000] *pgd=a03ac011, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#2]
Modules linked in:
CPU: 0
PC is at __bug+0x40/0x54
LR is at 0x1
pc : [<c001b1d4>]    lr : [<00000001>]    Not tainted
sp : c3c09ea8  ip : 60000093  fp : c3c09eb8
r10: c0171ae0  r9 : c000d6a0  r8 : c03e4c4c
r7 : 4007f000  r6 : c03e4c4c  r5 : c000859c  r4 : 00000000
r3 : 00000000  r2 : 00000000  r1 : 60000013  r0 : 00000001
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A3C28000  DAC: 00000015
Process  (pid: 0, stack limit = 0xc3c08190)
Stack: (0xc3c09ea8 to 0xc3c0a000)
9ea0:                   c03e4c4c c3c09ed8 c3c09ebc c0053e08 c001b1a0 
00000002
9ec0: c03e49ac c03e4c4c c017e820 c3c09eec c3c09edc c00566f0 c0053d74 
c000d6a0
9ee0: c3c09f18 c3c09ef0 c00517c4 c00566dc a03410df c3c189fc c03e4c4c 
4007f000
9f00: 00000800 c000d6a0 c3c29000 c3c09f54 c3c09f1c c0052460 c0051718 
c3c29000
9f20: a03410df c3c28000 00001000 c033dd00 ffffffeb 4007f8d0 c03e4c4c 
c000d6a0
9f40: c3c09fb0 0000080f c3c09f88 c3c09f58 c001cc74 c0052284 40044278 
c000d6cc
9f60: 0000080f c3c09fec c01413f8 4007f8d0 c3c09fb0 00000ae8 4000c108 
c3c09fac
9f80: c3c09f8c c001cee0 c001cbd0 ffffffff c3c09fec 400409a3 0000397f 
00098400
9fa0: 00000000 c3c09fb0 c0016858 c001ceb0 4005af84 400409aa 00000012 
00000000
9fc0: 4005af84 4007f8d0 400409a3 00098504 00098400 00000ae8 4000c108 
00000000
9fe0: 4003f338 befff6c8 40005298 40003b60 20000010 ffffffff 00000000 
00000000
Backtrace:
[<c001b194>] (__bug+0x0/0x54) from [<c0053e08>] 
(find_mergeable_anon_vma+0xa0/0x114)
 r4 = C03E4C4C
[<c0053d68>] (find_mergeable_anon_vma+0x0/0x114) from [<c00566f0>] 
(anon_vma_prepare+0x20/0x98)
 r5 = C017E820  r4 = C03E4C4C
[<c00566d0>] (anon_vma_prepare+0x0/0x98) from [<c00517c4>] 
(do_wp_page+0xb8/0x358)
 r4 = C000D6A0
[<c005170c>] (do_wp_page+0x0/0x358) from [<c0052460>] 
(handle_mm_fault+0x1e8/0x258)
[<c0052278>] (handle_mm_fault+0x0/0x258) from [<c001cc74>] 
(do_page_fault+0xb0/0x1e0)
[<c001cbc4>] (do_page_fault+0x0/0x1e0) from [<c001cee0>] 
(do_DataAbort+0x3c/0xa0)
[<c001cea4>] (do_DataAbort+0x0/0xa0) from [<c0016858>] 
(ret_from_exception+0x0/0x10)
 r8 = 00098400  r7 = 0000397F  r6 = 400409A3  r5 = C3C09FEC
 r4 = FFFFFFFF
Code: 1b003feb e59f0014 eb003fe9 e3a03000 (e5833000)
 <1>Unable to handle kernel NULL pointer dereference at virtual address 
00000000pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 7 [#3]
Modules linked in:
CPU: 0
PC is at scheduler_tick+0x1fc/0x4cc
LR is at scheduler_tick+0x24/0x4cc
pc : [<c00275e8>]    lr : [<c0027410>]    Not tainted
sp : c3c09cd4  ip : c016acb8  fp : c3c09cfc
r10: 00000000  r9 : c0168b30  r8 : c016a810
r7 : 00000000  r6 : 00000000  r5 : c033dd00  r4 : 00000000
r3 : 00000093  r2 : 00000000  r1 : 00000093  r0 : 00000001
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A3C28000  DAC: 00000015
Process  (pid: 0, stack limit = 0x00000190)
Stack: (0xc3c09cd4 to 0x00002000)
Backtrace:
[<c00273ec>] (scheduler_tick+0x0/0x4cc) from [<c001feb0>] 
(pxa_timer_interrupt+0x28/0x6c)
[<c001fe88>] (pxa_timer_interrupt+0x0/0x6c) from [<c001745c>] 
(__do_irq+0x4c/0x88)
 r5 = 00000000  r4 = C0141BD8
[<c0017410>] (__do_irq+0x0/0x88) from [<c00176a0>] (do_level_IRQ+0x68/0xb8)
 r8 = 60000013  r7 = C001B570  r6 = C3C09D8C  r5 = 00000013
 r4 = C0168EC0
[<c0017638>] (do_level_IRQ+0x0/0xb8) from [<c001773c>] 
(asm_do_IRQ+0x4c/0x150)
 r6 = C3C08000  r5 = F2D00000  r4 = C3C09DC0
[<c00176f0>] (asm_do_IRQ+0x0/0x150) from [<c0016560>] (__irq_svc+0x20/0x60)
[<c001b29c>] (die+0x0/0x32c) from [<c001cafc>] (__do_kernel_fault+0x6c/0x80)
[<c001ca90>] (__do_kernel_fault+0x0/0x80) from [<c001cd8c>] 
(do_page_fault+0x1c8/0x1e0)
 r7 = C03E4760  r6 = 00000000  r5 = FFFFFFEC  r4 = C033DD00
[<c001cbc4>] (do_page_fault+0x0/0x1e0) from [<c001cee0>] 
(do_DataAbort+0x3c/0xa0)
[<c001cea4>] (do_DataAbort+0x0/0xa0) from [<c001651c>] 
(__dabt_svc+0x3c/0x60)
 r8 = C03E4C4C  r7 = 4007F000  r6 = C03E4C4C  r5 = C3C09E94
 r4 = FFFFFFFF
[<c001b194>] (__bug+0x0/0x54) from [<c0053e08>] 
(find_mergeable_anon_vma+0xa0/0x114)
 r4 = C03E4C4C
[<c0053d68>] (find_mergeable_anon_vma+0x0/0x114) from [<c00566f0>] 
(anon_vma_prepare+0x20/0x98)
 r5 = C017E820  r4 = C03E4C4C
[<c00566d0>] (anon_vma_prepare+0x0/0x98) from [<c00517c4>] 
(do_wp_page+0xb8/0x358)
 r4 = C000D6A0
[<c005170c>] (do_wp_page+0x0/0x358) from [<c0052460>] 
(handle_mm_fault+0x1e8/0x258)
[<c0052278>] (handle_mm_fault+0x0/0x258) from [<c001cc74>] 
(do_page_fault+0xb0/0x1e0)
[<c001cbc4>] (do_page_fault+0x0/0x1e0) from [<c001cee0>] 
(do_DataAbort+0x3c/0xa0)
[<c001cea4>] (do_DataAbort+0x0/0xa0) from [<c0016858>] 
(ret_from_exception+0x0/0x10)
 r8 = 00098400  r7 = 0000397F  r6 = 400409A3  r5 = C3C09FEC
 r4 = FFFFFFFF
Code: e5952004 e10f1000 e3813080 e121f003 (e5923000)
 <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
                                                                


Craig Hughes wrote:

> On Jan 28, 2005, at 6:35 AM, Jim Walters wrote:
>
>> <snip>
>> Creating 2 MTD partitions on "Gumstix Flash ROM":
>> 0x00000000-0x00040000 : "Bootloader"
>> 0x00040000-0x00400000 : "RootFS"
>> NET: Registered protocol family 2
>> IP: routing cache hash table of 512 buckets, 4Kbytes
>> TCP: Hash tables configured (established 4096 bind 8192)
>> VFS: Mounted root (jffs2 filesystem).
>> Freeing init memory: 56K
>> /sbin/init: can't resolve symbol 'reboot'
>> Unable to handle kernel paging request at virtual address ffffffc4
>> pgd = c3c14000
>> [ffffffc4] *pgd=a0002001, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 7 [#1]
>> <snip>
>
>
> Jim,
>
> can you please post the complete Oops trace -- hard to tell from just 
> this snippet what's going wrong where.
>
> Thanks
>
> C
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

Just to let you all know, that I've had a melt down on my home boxen
while migrating to FC3, I was having too many flakiness with Mandrake
10.1 image from cheapbytes.  

Safety tip:  Don't use crappy install media on systems with questionable
CDROM's.  When I'm back up, I'll grab the trunk tip build and the test
root_fs.

--mgross

On Fri, 2005-01-28 at 19:44 -0600, Jim Walters wrote:
> Hi Craig,
> 
> I re-ran the boot image that gives me errors, and it looks different 
> this time.  In fact, each time I power down and back up again there's a 
> completely different address, and sometimes even different error texts.  
> Sometimes, it keeps looping with the same oops dump and never fully 
> panics and stops.  Here's the full list of one that stops eventually:
> 
> U-Boot 1.1.1 (Oct  3 2004 - 21:30:21)
>                                      
> *** Welcome to Gumstix ***
>                           
> U-Boot code: A3F00000 -> A3F1B01C  BSS: -> A3F4CB54
> RAM Configuration:
> Bank #0: a0000000 64 MB
> erase_region_count = 32 erase_region_size = 131072
> Flash:  4 MB
> Hit any key to stop autoboot:  0
> ### JFFS2 loading 'boot/uImage' to 0xa2000000
> Scanning JFFS2 FS: ..... done.
> ### JFFS2 load complete: 702828 bytes loaded to 0xa2000000
> ## Booting image at a2000000 ...
>    Image Name:   uImage
>    Image Type:   ARM Linux Kernel Image (gzip compressed)
>    Data Size:    702764 Bytes = 686.3 kB
>    Load Address: a0008000
>    Entry Point:  a0008000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
>                                     
> Starting kernel ...
>                    
> Uncompressing Linux................................................ 
> done, booting the kernel.
> Linux version 2.6.10gum (root@...) (gcc version 3.4.2) 
> #1 Fri Jan 28 06:56:39 CST 2005
> CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE)
> CPU: D VIVT undefined 5 cache
> CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
> CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
> Machine: The Gumstix Platform
> Memory policy: ECC disabled, Data cache writeback
> Memory clock: 99.53MHz (*27)
> Run Mode clock: 398.13MHz (*4)
> Turbo Mode clock: 398.13MHz (*1.0, inactive)
> Built 1 zonelists
> Kernel command line: console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 
> reboot=cold,hard video=pxafb:mode:800x600-16,active
> PID hash table entries: 512 (order: 9, 8192 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 64MB = 64MB total
> Memory: 63360KB available (1182K code, 224K data, 56K init)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> CPU: Testing write buffer coherency: ok
> NET: Registered protocol family 16
> PXA CPU frequency change support initialized
> NetWinder Floating Point Emulator V0.97 (double precision)
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> ttyS0 at MMIO 0x40100000 (irq = 15) is a FFUART
> ttyS1 at MMIO 0x40200000 (irq = 14) is a BTUART
> ttyS2 at MMIO 0x40700000 (irq = 13) is a STUART
> ttyS3 at MMIO 0x41600000 (irq = 0) is a HWUART
> io scheduler noop registered
> elevator: using noop as default io scheduler
> physmap flash device: 400000 at 0
> phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
>  Intel/Sharp Extended Query Table at 0x0031
> Using buffer write method
> cfi_cmdset_0001: Erase suspend on write enabled
> cmdlinepart partition parsing not available
> RedBoot partition parsing not available
> Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth)
> Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank
>  Intel/Sharp Extended Query Table at 0x0031
> Using buffer write method
> cfi_cmdset_0001: Erase suspend on write enabled
> Using static partitions on Gumstix Flash ROM
> Creating 2 MTD partitions on "Gumstix Flash ROM":
> 0x00000000-0x00040000 : "Bootloader"
> 0x00040000-0x00400000 : "RootFS"
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind 8192)
> VFS: Mounted root (jffs2 filesystem).
> Freeing init memory: 56K
> Unhandled fault: imprecise external abort (0x406) at 0x00096d08
> pgd = c3c10000
> [00096d08] *pgd=a03ad011, *pte=a3c160ff, *ppte=a3c1603f
> kernel BUG at mm/rmap.c:483!
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 807 [#1]
> Modules linked in:
> CPU: 0
> PC is at __bug+0x40/0x54
> LR is at 0x1
> pc : [<c001b1d4>]    lr : [<00000001>]    Not tainted
> sp : c02f3d9c  ip : 60000093  fp : c02f3dac
> r10: a02c005f  r9 : c3c1d000  r8 : 0003f000
> r7 : 40038000  r6 : 00022000  r5 : 00000000  r4 : 00000000
> r3 : 00000000  r2 : 00000000  r1 : 60000013  r0 : 00000001
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 397F  Table: A3C1C000  DAC: 00000015
> Process init (pid: 61, stack limit = 0xc02f2190)
> Stack: (0xc02f3d9c to 0xc02f4000)
> 3d80:                                                                
> c017d800
> 3da0: c02f3dc0 c02f3db0 c0056ee8 c001b1a0 c017d800 c02f3e28 c02f3dc4 
> c0050efc
> 3dc0: c0056e90 c3c0b968 40238000 40077000 c3c1d000 40077000 c016a424 
> 0003f000
> 3de0: 40077000 00000000 0000000e 00344000 00000000 c0009b50 c000dae0 
> c02f3e3c
> 3e00: c000dae0 00000000 00000001 00000001 0000000b c02f2000 c02f3fb0 
> c02f3e58
> 3e20: c02f3e2c c0055190 c0050b68 ffffffff c02f3e38 00000000 0000007c 
> c016a424
> 3e40: c000dae0 c000db0c c0282060 c02f3e6c c02f3e5c c00289f0 c0055138 
> c000dae0
> 3e60: c02f3e8c c02f3e70 c002c834 c00289bc c0282260 c02f3fb0 0000000b 
> c02f2000
> 3e80: c02f3ea0 c02f3e90 c002d31c c002c69c 0000000b c02f3ecc c02f3ea4 
> c0035d6c
> 3ea0: c002d294 c02f2000 00000000 c02f3fb0 00000000 00000000 c02f3ef0 
> 4007f15c
> 3ec0: c02f3fac c02f3ed0 c0019f98 c0035aa8 1f0daf84 c017e820 c017fce0 
> 4007f000
> 3ee0: c0282260 c02f3ef0 c0051950 c0056d0c 0000000b 00000000 00030001 
> 1f0daf84
> 3f00: c017e820 c017fce0 4007f000 c02f3f18 c02f3f1c c0052460 c0051718 
> c3c1d000
> 3f20: a03410df c3c1c000 00001000 c0282060 ffffffeb 4007f8d0 c0009a54 
> c000dae0
> 3f40: c02f3fb0 c0282060 c02f3f88 c02f3f58 c001cd4c c001cb1c c02f3fb0 
> c000db0c
> 3f60: 000000f5 c02f3fec c0141380 1f0daf84 c02f3fb0 00000ae8 4007f15c 
> c02f3fac
> 3f80: c02f3f8c ffffffff c02f3fec 0000000a 0000397f 00000000 c02f2000 
> 4007f15c
> 3fa0: 00000000 c02f3fb0 c00168ec c0019f3c befff668 befff66c 4005aff8 
> 00000000
> 3fc0: 1f0daf84 befff5dc 0000000a 00000001 000981a0 00000ae8 4007f15c 
> 00000000
> 3fe0: 4005af84 befff4b0 4005b018 4005b004 20000010 ffffffff 00000000 
> 00000000
> Backtrace:
> [<c001b194>] (__bug+0x0/0x54) from [<c0056ee8>] (page_remove_rmap+0x64/0x94)
>  r4 = C017D800
> [<c0056e84>] (page_remove_rmap+0x0/0x94) from [<c0050efc>] 
> (unmap_vmas+0x3a0/0x58c)
>  r4 = C017D800
> [<c0050b5c>] (unmap_vmas+0x0/0x58c) from [<c0055190>] (exit_mmap+0x64/0x16c)
> [<c005512c>] (exit_mmap+0x0/0x16c) from [<c00289f0>] (mmput+0x40/0xa8)
>  r6 = C0282060  r5 = C000DB0C  r4 = C000DAE0
> [<c00289b0>] (mmput+0x0/0xa8) from [<c002c834>] (do_exit+0x1a4/0xbc0)
>  r4 = C000DAE0
> [<c002c690>] (do_exit+0x0/0xbc0) from [<c002d31c>] (do_group_exit+0x94/0x9c)
> [<c002d288>] (do_group_exit+0x0/0x9c) from [<c0035d6c>] 
> (get_signal_to_deliver+0x2d0/0x2f4)
>  r4 = 0000000B
> [<c0035a9c>] (get_signal_to_deliver+0x0/0x2f4) from [<c0019f98>] 
> (do_signal+0x68/0x4b8)
> [<c0019f30>] (do_signal+0x0/0x4b8) from [<c00168ec>] 
> (work_pending+0x1c/0x24)
> Code: 1b003feb e59f0014 eb003fe9 e3a03000 (e5833000)
>  <2>kernel BUG at mm/mmap.c:708!
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c3c28000
> [00000000] *pgd=a03ac011, *pte=00000000, *ppte=00000000
> Internal error: Oops: 807 [#2]
> Modules linked in:
> CPU: 0
> PC is at __bug+0x40/0x54
> LR is at 0x1
> pc : [<c001b1d4>]    lr : [<00000001>]    Not tainted
> sp : c3c09ea8  ip : 60000093  fp : c3c09eb8
> r10: c0171ae0  r9 : c000d6a0  r8 : c03e4c4c
> r7 : 4007f000  r6 : c03e4c4c  r5 : c000859c  r4 : 00000000
> r3 : 00000000  r2 : 00000000  r1 : 60000013  r0 : 00000001
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 397F  Table: A3C28000  DAC: 00000015
> Process  (pid: 0, stack limit = 0xc3c08190)
> Stack: (0xc3c09ea8 to 0xc3c0a000)
> 9ea0:                   c03e4c4c c3c09ed8 c3c09ebc c0053e08 c001b1a0 
> 00000002
> 9ec0: c03e49ac c03e4c4c c017e820 c3c09eec c3c09edc c00566f0 c0053d74 
> c000d6a0
> 9ee0: c3c09f18 c3c09ef0 c00517c4 c00566dc a03410df c3c189fc c03e4c4c 
> 4007f000
> 9f00: 00000800 c000d6a0 c3c29000 c3c09f54 c3c09f1c c0052460 c0051718 
> c3c29000
> 9f20: a03410df c3c28000 00001000 c033dd00 ffffffeb 4007f8d0 c03e4c4c 
> c000d6a0
> 9f40: c3c09fb0 0000080f c3c09f88 c3c09f58 c001cc74 c0052284 40044278 
> c000d6cc
> 9f60: 0000080f c3c09fec c01413f8 4007f8d0 c3c09fb0 00000ae8 4000c108 
> c3c09fac
> 9f80: c3c09f8c c001cee0 c001cbd0 ffffffff c3c09fec 400409a3 0000397f 
> 00098400
> 9fa0: 00000000 c3c09fb0 c0016858 c001ceb0 4005af84 400409aa 00000012 
> 00000000
> 9fc0: 4005af84 4007f8d0 400409a3 00098504 00098400 00000ae8 4000c108 
> 00000000
> 9fe0: 4003f338 befff6c8 40005298 40003b60 20000010 ffffffff 00000000 
> 00000000
> Backtrace:
> [<c001b194>] (__bug+0x0/0x54) from [<c0053e08>] 
> (find_mergeable_anon_vma+0xa0/0x114)
>  r4 = C03E4C4C
> [<c0053d68>] (find_mergeable_anon_vma+0x0/0x114) from [<c00566f0>] 
> (anon_vma_prepare+0x20/0x98)
>  r5 = C017E820  r4 = C03E4C4C
> [<c00566d0>] (anon_vma_prepare+0x0/0x98) from [<c00517c4>] 
> (do_wp_page+0xb8/0x358)
>  r4 = C000D6A0
> [<c005170c>] (do_wp_page+0x0/0x358) from [<c0052460>] 
> (handle_mm_fault+0x1e8/0x258)
> [<c0052278>] (handle_mm_fault+0x0/0x258) from [<c001cc74>] 
> (do_page_fault+0xb0/0x1e0)
> [<c001cbc4>] (do_page_fault+0x0/0x1e0) from [<c001cee0>] 
> (do_DataAbort+0x3c/0xa0)
> [<c001cea4>] (do_DataAbort+0x0/0xa0) from [<c0016858>] 
> (ret_from_exception+0x0/0x10)
>  r8 = 00098400  r7 = 0000397F  r6 = 400409A3  r5 = C3C09FEC
>  r4 = FFFFFFFF
> Code: 1b003feb e59f0014 eb003fe9 e3a03000 (e5833000)
>  <1>Unable to handle kernel NULL pointer dereference at virtual address 
> 00000000pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 7 [#3]
> Modules linked in:
> CPU: 0
> PC is at scheduler_tick+0x1fc/0x4cc
> LR is at scheduler_tick+0x24/0x4cc
> pc : [<c00275e8>]    lr : [<c0027410>]    Not tainted
> sp : c3c09cd4  ip : c016acb8  fp : c3c09cfc
> r10: 00000000  r9 : c0168b30  r8 : c016a810
> r7 : 00000000  r6 : 00000000  r5 : c033dd00  r4 : 00000000
> r3 : 00000093  r2 : 00000000  r1 : 00000093  r0 : 00000001
> Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  Segment user
> Control: 397F  Table: A3C28000  DAC: 00000015
> Process  (pid: 0, stack limit = 0x00000190)
> Stack: (0xc3c09cd4 to 0x00002000)
> Backtrace:
> [<c00273ec>] (scheduler_tick+0x0/0x4cc) from [<c001feb0>] 
> (pxa_timer_interrupt+0x28/0x6c)
> [<c001fe88>] (pxa_timer_interrupt+0x0/0x6c) from [<c001745c>] 
> (__do_irq+0x4c/0x88)
>  r5 = 00000000  r4 = C0141BD8
> [<c0017410>] (__do_irq+0x0/0x88) from [<c00176a0>] (do_level_IRQ+0x68/0xb8)
>  r8 = 60000013  r7 = C001B570  r6 = C3C09D8C  r5 = 00000013
>  r4 = C0168EC0
> [<c0017638>] (do_level_IRQ+0x0/0xb8) from [<c001773c>] 
> (asm_do_IRQ+0x4c/0x150)
>  r6 = C3C08000  r5 = F2D00000  r4 = C3C09DC0
> [<c00176f0>] (asm_do_IRQ+0x0/0x150) from [<c0016560>] (__irq_svc+0x20/0x60)
> [<c001b29c>] (die+0x0/0x32c) from [<c001cafc>] (__do_kernel_fault+0x6c/0x80)
> [<c001ca90>] (__do_kernel_fault+0x0/0x80) from [<c001cd8c>] 
> (do_page_fault+0x1c8/0x1e0)
>  r7 = C03E4760  r6 = 00000000  r5 = FFFFFFEC  r4 = C033DD00
> [<c001cbc4>] (do_page_fault+0x0/0x1e0) from [<c001cee0>] 
> (do_DataAbort+0x3c/0xa0)
> [<c001cea4>] (do_DataAbort+0x0/0xa0) from [<c001651c>] 
> (__dabt_svc+0x3c/0x60)
>  r8 = C03E4C4C  r7 = 4007F000  r6 = C03E4C4C  r5 = C3C09E94
>  r4 = FFFFFFFF
> [<c001b194>] (__bug+0x0/0x54) from [<c0053e08>] 
> (find_mergeable_anon_vma+0xa0/0x114)
>  r4 = C03E4C4C
> [<c0053d68>] (find_mergeable_anon_vma+0x0/0x114) from [<c00566f0>] 
> (anon_vma_prepare+0x20/0x98)
>  r5 = C017E820  r4 = C03E4C4C
> [<c00566d0>] (anon_vma_prepare+0x0/0x98) from [<c00517c4>] 
> (do_wp_page+0xb8/0x358)
>  r4 = C000D6A0
> [<c005170c>] (do_wp_page+0x0/0x358) from [<c0052460>] 
> (handle_mm_fault+0x1e8/0x258)
> [<c0052278>] (handle_mm_fault+0x0/0x258) from [<c001cc74>] 
> (do_page_fault+0xb0/0x1e0)
> [<c001cbc4>] (do_page_fault+0x0/0x1e0) from [<c001cee0>] 
> (do_DataAbort+0x3c/0xa0)
> [<c001cea4>] (do_DataAbort+0x0/0xa0) from [<c0016858>] 
> (ret_from_exception+0x0/0x10)
>  r8 = 00098400  r7 = 0000397F  r6 = 400409A3  r5 = C3C09FEC
>  r4 = FFFFFFFF
> Code: e5952004 e10f1000 e3813080 e121f003 (e5923000)
>  <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
>                                                                 
> 
> 
> Craig Hughes wrote:
> 
> > On Jan 28, 2005, at 6:35 AM, Jim Walters wrote:
> >
> >> <snip>
> >> Creating 2 MTD partitions on "Gumstix Flash ROM":
> >> 0x00000000-0x00040000 : "Bootloader"
> >> 0x00040000-0x00400000 : "RootFS"
> >> NET: Registered protocol family 2
> >> IP: routing cache hash table of 512 buckets, 4Kbytes
> >> TCP: Hash tables configured (established 4096 bind 8192)
> >> VFS: Mounted root (jffs2 filesystem).
> >> Freeing init memory: 56K
> >> /sbin/init: can't resolve symbol 'reboot'
> >> Unable to handle kernel paging request at virtual address ffffffc4
> >> pgd = c3c14000
> >> [ffffffc4] *pgd=a0002001, *pte=00000000, *ppte=00000000
> >> Internal error: Oops: 7 [#1]
> >> <snip>
> >
> >
> > Jim,
> >
> > can you please post the complete Oops trace -- hard to tell from just 
> > this snippet what's going wrong where.
> >
> > Thanks
> >
> > C
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> > Tool for open source databases. Create drag-&-drop reports. Save time
> > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> > Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> > _______________________________________________
> > gumstix-users mailing list
> > gumstix-users@...
> > https://lists.sourceforge.net/lists/listinfo/gumstix-users
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

On Sat, 2005-01-29 at 07:17 -0800, mark gross wrote:
> Just to let you all know, that I've had a melt down on my home boxen
> while migrating to FC3, I was having too many flakiness with Mandrake
> 10.1 image from cheapbytes.  
> 
> Safety tip:  Don't use crappy install media on systems with
> questionable
> CDROM's.  When I'm back up, I'll grab the trunk tip build and the test
> root_fs.
> 
> 

Now that I have my systems coming back on line, the svn.rungie.com is
acting up :(

--mgross

On Jan 29, 2005, at 10:32 AM, mark gross wrote:

> Now that I have my systems coming back on line, the svn.rungie.com is
> acting up :(

The server whos CPU and mobo failed last weekend is having another bad 
weekend.  Time to route things around it...  as though I didn't have 
enough to work on :)

C