From: mark g. <mar...@th...> - 2005-01-24 05:36:12
|
I just finished building my first root filesystem for my gumstix by following the gumstix.org instructions. The build worked, but after I programmed the flash Iget the following issue. Are there any tips or ideas on what the problem is? Thanks, --mgross 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 0x000091bc pgd = c3c10000 [000091bc] *pgd=a03ad011, *pte=a034905f, *ppte=a034902b |
From: Darren G. <ts...@ya...> - 2005-01-25 17:12:24
|
I'm sometimes had problems on the first boot after flashing a new root, and after repeating the flash process, everything worked fine. On Jan 23, 2005, at 9:36 PM, mark gross wrote: > I just finished building my first root filesystem for my gumstix by > following the gumstix.org instructions. > > The build worked, but after I programmed the flash Iget the following > issue. Are there any tips or ideas on what the problem is? > > Thanks, > > --mgross > > 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 0x000091bc > pgd = c3c10000 > [000091bc] *pgd=a03ad011, *pte=a034905f, *ppte=a034902b > > > > ------------------------------------------------------- > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: mark g. <mar...@th...> - 2005-01-27 02:45:52
|
Darren Gibbs wrote: > I'm sometimes had problems on the first boot after flashing a new > root, and after repeating the flash process, everything worked fine. > Thats a bit scary. Do you still see problems from time to time? --mgross > On Jan 23, 2005, at 9:36 PM, mark gross wrote: > >> I just finished building my first root filesystem for my gumstix by >> following the gumstix.org instructions. >> >> The build worked, but after I programmed the flash Iget the following >> issue. Are there any tips or ideas on what the problem is? >> >> Thanks, >> >> --mgross >> >> 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 0x000091bc >> pgd = c3c10000 >> [000091bc] *pgd=a03ad011, *pte=a034905f, *ppte=a034902b > |
From: Darren G. <ts...@ya...> - 2005-01-27 04:54:43
|
It's happened to me twice if I remember correctly... I have probably re-flashed my gumstix 20 times at the most. I don't think it was pilot error. When I had a problem with a crash right after "Freeing init memory", I tried rebooting several times, but no difference . After re-flashing with the same image, I had no more problems. On Jan 26, 2005, at 6:45 PM, mark gross wrote: > Darren Gibbs wrote: > >> I'm sometimes had problems on the first boot after flashing a new >> root, and after repeating the flash process, everything worked fine. >> > Thats a bit scary. Do you still see problems from time to time? > > --mgross > >> On Jan 23, 2005, at 9:36 PM, mark gross wrote: >> >>> I just finished building my first root filesystem for my gumstix by >>> following the gumstix.org instructions. >>> >>> The build worked, but after I programmed the flash Iget the >>> following issue. Are there any tips or ideas on what the problem >>> is? >>> >>> Thanks, >>> >>> --mgross >>> >>> 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 0x000091bc >>> pgd = c3c10000 >>> [000091bc] *pgd=a03ad011, *pte=a034905f, *ppte=a034902b >> > > > > ------------------------------------------------------- > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2005-01-27 05:59:26
|
Hi, On Wed, 26 Jan 2005 20:54:46 -0800, Darren Gibbs <ts...@ya...> wrote: > It's happened to me twice if I remember correctly... I have probably > re-flashed my gumstix 20 times at the most. I don't think it was pilot > error. When I had a problem with a crash right after "Freeing init > memory", I tried rebooting several times, but no difference . After > re-flashing with the same image, I had no more problems. This is directed mostly to Craig. On one of the platforms that I use at work (ARM-926 running linux 2.4 with a backported newer MTD), we found that when we write a JFFS2 file system we had to make sure that we erased the flash pages beyond the end of the jffs2 image that we downloaded. I believe that failing to erase these extra pages caused JFFS2 to get confused (we ran into this about a year ago, and the details are fuzzy now :) I don't know if u-boot provides this feature (the extra erasing) or not, so I thought I'd throw it out as a possible problem. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Craig H. <cr...@hu...> - 2005-01-27 15:56:42
|
On Jan 26, 2005, at 9:59 PM, Dave Hylands wrote: > This is directed mostly to Craig. On one of the platforms that I use > at work (ARM-926 running linux 2.4 with a backported newer MTD), we > found that when we write a JFFS2 file system we had to make sure that > we erased the flash pages beyond the end of the jffs2 image that we > downloaded. > > I believe that failing to erase these extra pages caused JFFS2 to get > confused (we ran into this about a year ago, and the details are fuzzy > now :) > > I don't know if u-boot provides this feature (the extra erasing) or > not, so I thought I'd throw it out as a possible problem. Hmm, could be. I normally do an era 1:2-31 then cp.b ... $filesize for copying the root_fs image to flash. So the stuff after the image should be erased. Is anyone not erasing the full 2-31 before writing the flash image, who's then running into this problem? C |
From: Ralph M. <rj...@me...> - 2005-01-27 23:22:28
|
Craig Hughes writes: > On Jan 26, 2005, at 9:59 PM, Dave Hylands wrote: > > > This is directed mostly to Craig. On one of the platforms that I use > > at work (ARM-926 running linux 2.4 with a backported newer MTD), we > > found that when we write a JFFS2 file system we had to make sure that > > we erased the flash pages beyond the end of the jffs2 image that we > > downloaded. > > > > I believe that failing to erase these extra pages caused JFFS2 to get > > confused (we ran into this about a year ago, and the details are fuzzy > > now :) > > > > I don't know if u-boot provides this feature (the extra erasing) or > > not, so I thought I'd throw it out as a possible problem. > > Hmm, could be. I normally do an era 1:2-31 then cp.b ... $filesize for > copying the root_fs image to flash. So the stuff after the image > should be erased. Is anyone not erasing the full 2-31 before writing > the flash image, who's then running into this problem? No, I also always do an "era 1:2-31" before flashing and still get the problems. I just tried r311, which seems to be the last one using 2.6.9, and it is also working fine. I will try r312 next and see what happens ... |
From: Ralph M. <rj...@me...> - 2005-01-28 00:33:54
|
Ralph Metzler writes: > Craig Hughes writes: > > On Jan 26, 2005, at 9:59 PM, Dave Hylands wrote: > > > > > This is directed mostly to Craig. On one of the platforms that I use > > > at work (ARM-926 running linux 2.4 with a backported newer MTD), we > > > found that when we write a JFFS2 file system we had to make sure that > > > we erased the flash pages beyond the end of the jffs2 image that we > > > downloaded. > > > > > > I believe that failing to erase these extra pages caused JFFS2 to get > > > confused (we ran into this about a year ago, and the details are fuzzy > > > now :) > > > > > > I don't know if u-boot provides this feature (the extra erasing) or > > > not, so I thought I'd throw it out as a possible problem. > > > > Hmm, could be. I normally do an era 1:2-31 then cp.b ... $filesize for > > copying the root_fs image to flash. So the stuff after the image > > should be erased. Is anyone not erasing the full 2-31 before writing > > the flash image, who's then running into this problem? > > No, I also always do an "era 1:2-31" before flashing and still get the > problems. > > I just tried r311, which seems to be the last one using 2.6.9, and it > is also working fine. > I will try r312 next and see what happens ... OK, r312 crashes: [...] TCP: Hash tables configured (established 4096 bind 8192) VFS: Mounted root (jffs2 filesystem). Freeing init memory: 56K Unhandled fault: imprecise external abort (0xc06) at 0x0000975c pgd = c3c04000 [0000975c] *pgd=a03a8011, *pte=a034505f, *ppte=a034502b Unhandled fault: (0x807) at 0xbedf7ffc Unable to handle kernel NULL pointer dereference at virtual address kwidth) [...] |
From: Craig H. <cr...@hu...> - 2005-01-28 06:02:25
|
On Jan 27, 2005, at 4:33 PM, Ralph Metzler wrote: > OK, r312 crashes: How about HEAD? (r344) C |
From: Ralph M. <rj...@me...> - 2005-01-28 10:15:03
|
Craig Hughes writes: > On Jan 27, 2005, at 4:33 PM, Ralph Metzler wrote: > > > OK, r312 crashes: > > How about HEAD? (r344) I just tried it and it seems to have the same problems :-( 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 (0xc06) at 0x4000d0f0 pgd = c3c08000 [4000d0f0] *pgd=a03ac011, *pte=a037305f, *ppte=a037302b Unable to handle kernel paging request at virtual address c0217e44 pgd = c3c14000 [c0217e44] *pgd=a020042e(bad) Internal error: Oops: 80d [#1] Modules linked in: CPU: 0 PC is at kmem_cache_free+0x30/0x5c LR is at do_munmap+0x330/0x350 pc : [<c004b510>] lr : [<c00546c0>] Not tainted sp : c3c09f24 ip : 0000000e fp : c3c09f40 r10: c0009df0 r9 : c0009b5c r8 : 40007000 [...] |
From: Craig H. <cr...@hu...> - 2005-01-28 20:30:53
|
Ralph, can you please copy and paste the whole Oops trace -- not enough info in there to tell where the failure's happening. Thanks C On Jan 28, 2005, at 2:14 AM, Ralph Metzler wrote: > Craig Hughes writes: >> On Jan 27, 2005, at 4:33 PM, Ralph Metzler wrote: >> >>> OK, r312 crashes: >> >> How about HEAD? (r344) > > > I just tried it and it seems to have the same problems :-( > > > 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 (0xc06) at 0x4000d0f0 > pgd = c3c08000 > [4000d0f0] *pgd=a03ac011, *pte=a037305f, *ppte=a037302b > Unable to handle kernel paging request at virtual address c0217e44 > pgd = c3c14000 > [c0217e44] *pgd=a020042e(bad) > Internal error: Oops: 80d [#1] > Modules linked in: > CPU: 0 > PC is at kmem_cache_free+0x30/0x5c > LR is at do_munmap+0x330/0x350 > pc : [<c004b510>] lr : [<c00546c0>] Not tainted > sp : c3c09f24 ip : 0000000e fp : c3c09f40 > r10: c0009df0 r9 : c0009b5c r8 : 40007000 > [...] > > > ------------------------------------------------------- > 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Ralph M. <rj...@me...> - 2005-01-28 15:08:20
|
Craig Hughes writes: > On Jan 27, 2005, at 4:33 PM, Ralph Metzler wrote: > > > OK, r312 crashes: > > How about HEAD? (r344) > Could you provide your working r344 image somewhere? This way we can see if it is really the build process or some other problem. I also tried r344 on another gumstix my brother got delivered just this week and it has the same problem. |
From: Craig H. <cr...@hu...> - 2005-01-28 22:49:52
|
On Jan 28, 2005, at 7:07 AM, Ralph Metzler wrote: > Could you provide your working r344 image somewhere? This way we can > see if it is really the build process or some other problem. http://azazel.rungie.com/craig/root_fs_arm.r344 C |
From: Ralph M. <rj...@me...> - 2005-01-29 00:40:17
|
Craig Hughes writes: > On Jan 28, 2005, at 7:07 AM, Ralph Metzler wrote: > > > Could you provide your working r344 image somewhere? This way we can > > see if it is really the build process or some other problem. > > http://azazel.rungie.com/craig/root_fs_arm.r344 OK, does not work either, must be something else. I'll try some kernel debugging next. Here is what I did to test your image (I called the file root344): 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 GUM> mmcinit Trying MMC *********************************************** * MMC found. Card desciption is: * * Manufacturer ID = ffff4d * * HW/FW Revision = 0x08 0x03 * * Product Name = * * Serial Number = 215a30 * * Month = 12 Year = 2004 * *********************************************** CSD_STRUCTURE = 2, MMC_PROT=3 TAAC=7f (80000000ns), NSAC=0 TRAN = 2a (20000000bps) CCC=1f5, READ_BL_LEN=9 (512) C_SIZE=f4f, C_SIZE_MULT=4 (64) TOTAL MMC SIZE=128417792 MMC_RDTO = 25000 GUM> fatload mmc 1 a2000000 root344 reading root344 2805296 bytes read GUM> era 1:2-31 Erase Flash Sectors 2-31 in Bank # 1 .............................. done GUM> cp.b a2000000 40000 ${filesize} Copy to Flash... done (unplug/plug-in power for gumstix) 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: 722690 bytes loaded to 0xa2000000 ## Booting image at a2000000 ... Image Name: uImage Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 722626 Bytes = 705.7 kB Load Address: a0008000 Entry Point: a0008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... Uncompressing Linux................................................. done, boot. Linux version 2.6.10gum (craig@azazel) (gcc version 3.4.2) #1 Thu Jan 27 20:20:5 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=cd 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 (1226K code, 224K data, 60K 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: 60K Unhandled fault: imprecise external abort (0x406) at 0x4000d0f0 pgd = c3c14000 [4000d0f0] *pgd=a03b7011, *pte=a037b05f, *ppte=a037b02b Unable to handle kernel paging request at virtual address cc334ca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc334ca7 pgd = cc334ca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc334ca7 pgd = cc334ca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Alignment trap: not handling instruction ee072f9a at [<c001e060>] Unhandled fault: alignment exception (0x013) at 0xcc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33cca7 pgd = cc33cca7 Unable to handle kernel paging request at virtual address cc33ffaf Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec Unable to handle kernel paging request at virtual address 1a6098ec [...] (keeps going a while ...) |
From: Craig H. <cr...@hu...> - 2005-01-29 01:02:35
|
On Jan 28, 2005, at 4:40 PM, Ralph Metzler wrote: > Unable to handle kernel paging request at virtual address cc334ca7 > ....etc.... Hmm -- this now looks a lot less like a jffs2 error, and more like some other problem. I'm curious as to why this is happening on your board (and other peoples) but not on mine. I'll pull a "new" F board from the bins in shipping tomorrow and try this image on one of those, rather than my older-batch F board. C |