Re: cat /dev/mem, cat /dev/ram ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 09, 2007 at 08:39:20AM -0500, Christopher Reder wrote:
> 
> > When I try a cat /dev/ram0 , the cursor will blink like it is working and
> I
> > can see that the kernel hasn't crashed.  Eventually, it fails as well, but
> > on a null virtual address.  I have the output below and have cut it short
> so
> > as to not include too much.  Can someone tell me if this is normal and if
> it
> > isn't, what could be the cause of it (setup issue with kernel etc).  I am
> > running 2.6.20, with the AT91 patches.
> 
> /dev/ram0 is a ramdisk, usually not very useful because it only
> contains a small part of the memory.
> 
> > # cat /dev/ram0
> 
> Uhm, try cat /dev/ram0 > /dev/null
> 
> Without the redirect cat will spew the contents on the tty which can
> really upset your terminal emulator and shell.
> 
> 
> Erik - 
> I did use devmem2 and can access memory locations on the arm.  The issue for
> me, it seems, is like the arm doesn't know what the boundaries are or that
> they are not setup properly.  In effect, it *seems* like it thinks there are
> 10 locations, lets say, and something is setup to only have 8, and when it
> accesses the 9th, it's bogus.  

What do you mean with "boundaries"? What locations do you mean? Could
you give an example?

> I wasn't too worried about it throwing up stuff to the terminal when I tried
> the original.  I just wanted to see if it wouldn't crash.  So, you're
> suggestion was also good and yes, it crashes at the same spot.  I'll include
> the output below.  The reason I picked on this is because it is crashing in
> the same way that other programs have been crashing on me so I thought it
> may be a good and easy thing that if I can get this to work, the others
> should as well.  Anything else I could try to see if things are setup
> correctly?

OK, same place, so it might not be RAM related. Well, it still can. If
the ramdisk is always mapped at the same place (which it most probably
will) and that place is somehow corrpupt, things will go wrong. Could
you upgrade to a newer kernel and see if that solves the problem?


Erik

- -- 
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGvD+E/PlVHJtIto0RAo6kAJ9Z10y/FWVvghVMNowooUw2cjkXhwCfR5A2
p1CHR0V8fIks0GIK+96VuGc=
=L1v1
-----END PGP SIGNATURE-----

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux