* [PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
From: Marcelo Tosatti @ 2005-07-20 6:29 UTC (permalink / raw)
To: Anton Wöllert, linuxppc-embedded
Anton,
Can you please test the following which is equivalent to your=20
suggest changes, the only difference being the location, contained=20
inside flush_dcache_icache_page(). After confirmation that it works
we can send up to the kernel maintainers.
We should still try to understand why this is happening, possibly=20
matching it to a published CPU errata bug, or inform Freescale
otherwise.
I've written that entry down in the 8xx TODO list.
Thanks!
-------------
On 8xx, in the case where a pagefault happens for a process who's not
the owner of the vma in question (ptrace for instance), the flush=20
operation is performed via the physical address.
Unfortunately, that results in a strange, unexplainable "icbi"=20
instruction fault, most likely due to a CPU bug (see oops below).
Avoid that by flushing the page via its kernel virtual address.=20
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C000543C LR: C000B060 SP: C0F35DF0 REGS: c0f35d40 TRAP: 0300 Not tai=
nted
MSR: 00009022 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 10
DAR: 00000010, DSISR: C2000000
TASK =3D c0ea8430[761] 'gdbserver' THREAD: c0f34000
Last syscall: 26
GPR00: 00009022 C0F35DF0 C0EA8430 00F59000 00000100 FFFFFFFF 00F58000
00000001
GPR08: C021DAEF C0270000 00009032 C0270000 22044024 10025428 01000800
00000001
GPR16: 007FFF3F 00000001 00000000 7FBC6AC0 00F61022 00000001 C0839300
C01E0000
GPR24: 00CD0889 C082F568 3000AC18 C02A7A00 C0EA15C8 00F588A9 C02ACB00
C02ACB00
NIP [c000543c] __flush_dcache_icache_phys+0x38/0x54
LR [c000b060] flush_dcache_icache_page+0x20/0x30
Call trace:
[c000b154] update_mmu_cache+0x7c/0xa4
[c005ae98] do_wp_page+0x460/0x5ec
[c005c8a0] handle_mm_fault+0x7cc/0x91c
[c005ccec] get_user_pages+0x2fc/0x65c
[c0027104] access_process_vm+0x9c/0x1d4
[c00076e0] sys_ptrace+0x240/0x4a4
[c0002bd0] ret_from_syscall+0x0/0x44
From: Anton W=F6llert <a.woellert@gmail.com>=20
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
--- a/arch/ppc/mm/init.c.orig 2005-07-20 03:05:44.000000000 -0300
+++ b/arch/ppc/mm/init.c 2005-07-20 03:05:46.000000000 -0300
@@ -577,6 +577,9 @@
#ifdef CONFIG_BOOKE
__flush_dcache_icache(kmap(page));
kunmap(page);
+#elif CONFIG_8xx
+ /* On 8xx there is no need to kmap since highmem is not supported */
+ __flush_dcache_icache(page_address(page));=20
#else
__flush_dcache_icache_phys(page_to_pfn(page) << PAGE_SHIFT);
#endif
^ permalink raw reply
* Re: OLS 2005 attendees
From: Grant Likely @ 2005-07-20 19:23 UTC (permalink / raw)
To: PPC64-dev List, Linux PPC Dev, linuxppc-embedded
In-Reply-To: <52642f46a4231ff4111424b0565ddcde@penguinppc.org>
For OLS2005 attendees:
We are planning to hold a BOF for embedded PPC tomorrow for all who
are interested. (Thursday July 21). Meet in the downstairs at 7:00pm
Cheers,
g.
^ permalink raw reply
* Re: Meet at OLS2005
From: David Ho @ 2005-07-20 20:33 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
In-Reply-To: <528646bc050720121713d62225@mail.gmail.com>
Grant, The CE Linux forum is holding a embedded linux BOF at Les
Suites at the same time. It is probably more ARM based, but it will
have lots of interested talks about XIP, PM suspend/resume, etc.
Not sure if you are interested to attend there as well.
David
On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> I talked to Kumar on the last break. We're going to have the
> ppcembedded BOF on Thursday at 7:00 in the downstairs lounge. I'm
> about to post an announcement on the mailing list. Let everyone know
>=20
> g.
>=20
> On 7/20/05, David Ho <davidkwho@gmail.com> wrote:
> > btw, Marcelo is asking when/where the ppc BOF will take place, I'm in
> > Room C again from 3-4pm, the last talk ran late. Maybe meet at the
> > Sofas outside Room C at 4pm.
> > Can talk about ppc BOF, I'm interested.
> >
> > David
> >
> > On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> > > I just got back online after lunch, so I probably missed you; I'm
> > > available between now and the next session. At the moment I'm on the
> > > 3rd floor at the DConf BOF. I'll have my email up that whole time
> > > also.
> > >
> > > Cheers
> > > g.
> > >
> > > On 7/20/05, David Ho <davidkwho@gmail.com> wrote:
> > > > Do you want to meet up now? I'm at Room C at the bottom floor. The=
re
> > > > are a bunch of sofas outside so it might be a better place to
> > > > chill/chat.
> > > >
> > > > David
> > > >
> > > > On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> > > > > David, Kumar;
> > > > >
> > > > > I'd like to meet both of you today, but as I don't know what eith=
er of
> > > > > you look like it's hard to track you down :-)
> > > > >
> > > > > When you get this, could you please either call me on my cell (40=
3)
> > > > > 399-0195 or email me back?
> > > > >
> > > > > At the moment, I'm in the NLKD session in Room A. (Middle sectio=
n,
> > > > > 4th row back, dark blue tee-shirt.)
> > > > >
> > > > > Thanks,
> > > > > g.
> > > > >
> > > >
> > >
> > >
> > > --
> > > "Why do musicians compose symphonies and poets write poems? They do i=
t
> > > because life wouldn't have any meaning for them if they didn't.
> > > That's why I draw cartoons. It's my life."
> > >
> > > -- Charles Shultz
> > >
> >
>=20
>=20
> --
> "Why do musicians compose symphonies and poets write poems? They do it
> because life wouldn't have any meaning for them if they didn't.
> That's why I draw cartoons. It's my life."
>=20
> -- Charles Shultz
>
^ permalink raw reply
* Re: OLS 2005 attendees
From: Grant Likely @ 2005-07-20 21:51 UTC (permalink / raw)
To: PPC64-dev List, Linux PPC Dev, linuxppc-embedded
In-Reply-To: <528646bc050720122361ec0551@mail.gmail.com>
Change of plans; we are going to meet 1/2 hour earlier so we can
decide as a group whether or not to just head over to the CELinux
forum or just meet amongst ourselves.
The CElinux forum is holding their BOF at Les Suites at 7:00
g.
On 7/20/05, Grant Likely <glikely@gmail.com> wrote:
> For OLS2005 attendees:
>=20
> We are planning to hold a BOF for embedded PPC tomorrow for all who
> are interested. (Thursday July 21). Meet in the downstairs at 7:00pm
>=20
> Cheers,
> g.
>=20
--=20
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life."
-- Charles Shultz
^ permalink raw reply
* Re: AW: AW: initrd rootfs ramdisk
From: T Ziomek @ 2005-07-20 22:05 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: tomz
In-Reply-To: <20050720203355.027CF67CF6@ozlabs.org>
On Wed, 6 Jul 2005 d.grab@hima.com wrote:
>
> i solved my problem with u-boot and linux. Now i have my rootfs ramdisk
> mounted and functioning. But one output is weird.
Can I ask what what you had to change to get your initrd RAM disk working?
I'm having a very similar problem.
Thanks, Tom Ziomek
--
/"\ ASCII Ribbon Campaign | Email to user 'CTZ001'
\ / | at 'email.mot.com'
X Against HTML |
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH] 8xx: avoid icbi misbehaviour in __flush_dcache_icache_phys
From: Anton Wöllert @ 2005-07-20 23:34 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050720062859.GA8477@dmt.cnet>
Marcelo Tosatti wrote:
> Can you please test the following which is equivalent to your
> suggest changes, the only difference being the location, contained
> inside flush_dcache_icache_page(). After confirmation that it works
> we can send up to the kernel maintainers.
of course, i can do that :).
> We should still try to understand why this is happening, possibly
> matching it to a published CPU errata bug, or inform Freescale
> otherwise.
i think so too. as far as i understand it, the thing with the previous
__flush_dcache_icache&tlbie patch was that __flush_dcache_icache should
try to call dcbst on every address on a cache-line-boundary that could
reference the page to give the cpu a hint, so that the next write-access
to this page will be more effective, right? but while trying to do the
dcbst, the TLB is looked up for the addresses for a faster translation.
but here the old TLB-Entry exists, that says invalid Page or something
like that, right? So it should be invalidated before, right?
Question, normally the dcbst should cause a TLB-Error-Exception, that
than should do reload the TLB-Entry automatically, doesn't this work
because of the dcb*-errata (btw. where can i found that?). And the
__flush_dcache_icache should do a dcbst 4096/16=256 times, but there are
just 64 cache-lines à 16Byte (1Kb DCache), so shouldn't be 3/4 of that
routine redundant? and also, as it seems to me, the whole dcache will be
*flushed* or better dcbst'd trough this routine. is that right?
please correct me!
so, now the __flush_dcache_icache_phys(). this is just called, when the
memory-mapping of the vma is not same as the one of that from the
current process. this should be the case with ptrace. couldn't now be
done the same as above? maybe no because the address is the virtual
address as seen from the ptraced process? and so that will *flush* the
pages from the ptraced process (that doesn't exists yet?, because they
were just created for the tracing process?).
so the pte, that was created for the tracing process is used. from that,
the physical address is calculated (how is this done, whats the magic
about the pfn-stuff etc, i didn't really understand that :( ). now
__flush_dcache_icache_phys is used, because the [d|i]cache uses physical
address tags and so the data-mmu could be turned off to flush these entries.
so to understand the things further, i have to understand which
addresses are used with dcbst and icbi. there is
page=pfn_to_page(pte_pfn(pte)) and (page_to_pfn(page) << PAGE_SHIFT).
but what are these values or where do they point. any hints to the
pfn&pte stuff? unfortunately i didn't have much time the last days to
understand this more deeply...
>
> On 8xx, in the case where a pagefault happens for a process who's not
> the owner of the vma in question (ptrace for instance), the flush
> operation is performed via the physical address.
>
> Unfortunately, that results in a strange, unexplainable "icbi"
> instruction fault, most likely due to a CPU bug (see oops below).
where do you know, that "icbi" is the bad?
Anton
^ permalink raw reply
* help
From: 戴红刚 @ 2005-07-21 5:59 UTC (permalink / raw)
To: linuxppc-embedded
can you give me the driver of isp1362, thanks a lot.
^ permalink raw reply
* Re: boot failure help needed
From: Susheel Raj @ 2005-07-21 7:18 UTC (permalink / raw)
To: David Wolfe; +Cc: linuxppc-embedded
In-Reply-To: <20050719153508.GB32476@orthanc.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
Hi David,
I have never done patch (I am a kid, help me grow
:-). the directories look a bit different to me as
compared that in the patch. PWD gives me this
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc$ pwd
/home/nuguru/linux_2_4_21_5200/arch/ppc
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc$ ls
4xx_io 8xx_io Makefile boot configs
iSeries lib mgt_io platforms xmon
8260_io CVS amiga config.in defconfig
kernel math-emu mm vmlinux.lds
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc$
I dont see the 5xxx_io .. but everything in mgt_io has
output files
nuguru@SW-server:~/linux_2_4_21_5200/arch/ppc/mgt_io$
ls
CVS Makefile fec.c fec.o psc.c
sc_task.impl.S sdma.o
Config.in bestcomm fec.h mgt_io.o psc.o sdma.c
sdma_5100.c
the bestcomm directory doesnt have "capi" folder in ..
Attaching the bestcomm folder on my system, and daring
to ask to send me a patch for this one.
If you feel that it will take more of your time can
you please suggest me some other options :-)
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
[-- Attachment #2: 489967008-bestcomm.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 36780 bytes --]
^ permalink raw reply
* AW: AW: AW: initrd rootfs ramdisk
From: David Grab @ 2005-07-21 7:30 UTC (permalink / raw)
To: 'T Ziomek', linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0507201702510.2672@holyoke.labs.mot.com>
>> i solved my problem with u-boot and linux. Now i have my rootfs ramdisk
>> mounted and functioning. But one output is weird.
>Can I ask what what you had to change to get your initrd RAM disk working?
>I'm having a very similar problem.
Sure! :)
1. I used the ramdisk provided by ELDK from www.denx.de. A good description
is here
http://www.denx.de/twiki/bin/view/DULG/RootFileSystemDesignAndBuilding
2. Write ramdisk into flash at any address.
3. Configuring u-boot for command line parameters in
/u-boot/include/configs/<board.h>. These definitions i have made. BOOTARGS
are the command line parameters which u-boot passes to linux. BOOTCOMMAND is
not really necessary, but you only type bootd and not "bootm
<linux_flash_address> <ramdisk_flash_address>". So you don?t spend much time
for typing. ;) BOOTDELAY is disabled, because i actually don?t want an
autoboot of the linux kernel.
#define CONFIG_BOOTARGS "console=ttyS1,115200 root=/dev/ram rw"
#define CONFIG_BOOTCOMMAND "bootm ff000000 ff800000" /* autoboot command
*/
#define CONFIG_BOOTDELAY -1 /* disable autoboot?? */
4. Now configuring linux kernel for ramdisk support. Following options are
needed.
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=""
Enables command line parameters in linux kernel.
I also set following options to enable ramdisk support. Maybe there are some
more options which don?t concerns to ramdisk support.
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVPTS_FS_XATTR is not set
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
That?s all i think.
Best regards,
David
^ permalink raw reply
* RE: help
From: Jordan, Kyle @ 2005-07-21 11:39 UTC (permalink / raw)
To: ???; +Cc: linuxppc-embedded
>=20
>=20
> can you give me the driver of isp1362, thanks a lot.
>=20
I have a driver for the isp1362 in host controller mode for a 2.4.x
kernel. However, isochronous endpoints are not working with it. I
think there is another driver for the 2.6.x kernel out there. Which
kernel are you using?
- Kyle
^ permalink raw reply
* Re: Problem mounting ramdisk image
From: Wolfgang Denk @ 2005-07-21 12:46 UTC (permalink / raw)
To: "Häpe, Sebastian, HRD/AB"
Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <2D9AB865A49FD511914700105A0EF6790252BDCE@morse.smart.lfk.eads.net>
In message <2D9AB865A49FD511914700105A0EF6790252BDCE@morse.smart.lfk.eads.net> you wrote:
>
> I have a litte problem with an initrd-image on a custom board:
It is considered a good idea to search a bit in the mailing list
archives before posting. If you had done so, you should have found
several similar requests before (even within the last few days) and
saved us all the effort to reiterate the whole thing again.
> Now the following effects occur:
>
> - if i do not tell the kernel which filesystem I have in my image (only
> entering: 'root=/dev/ram rw init=/bin/busybox')
You do not tell it to the kernel, and you don't tell us. This is not
really helpful. So what is it? ext2?
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 > blocksize
> RAMDISK: Compressed image found at block 0
Good.
> Freeing initrd memory: 709k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
Did you enable ext2 support in your kernel configuration?
> - if I tell the kernel to use TMPFS or RAMFS (rootfs=tmpfs or
> rootfs=ramfs), the error is
You get what you ask for: garbage in, garbage out.
> My distribution (ELinOS) creates two files, 'Image.gz' and > 'Image.initrd'.
> If I extract Image.gz, the full filesystem is extracted.
> How can I check wheather the 'Image.initrd' file is correct?
How should we know which commands your distribution uses to build
these images? They can contain anything.
> (U-Boot tells me it is correct if I enter 'imi [address of image]')
Grrrghh.. I wich you had posted complete information at least for a
single of your questions. And which sort of image type is reported by
U-Boot?
> Or does anyone did have the same problem? Have I forgotten any kernel
> options?
Yes, many people have asked the same before. It's all in the archives.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When in doubt, mumble; when in trouble, delegate; when in charge,
ponder. -- James H. Boren
^ permalink raw reply
* I need help with L2 cache on 440GX rev C
From: Nick Hennenfent @ 2005-07-21 12:44 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
I have an embedded 440GX rev C runnng at about 500Mhz.
I am using a 2.4.20 linux kernel.
I borrowed Matt Porter's code from the 2.6 kernels in
order to enable the L2 cache. The code compiles and
runs ok, but the cache does not seem to be enabled!!!
I ran some tests with/without the L2 cache code and
there is no difference.
(A qsort of 1 million random integers takes 2 seconds).
Is there some other magic trick to enable that cache????
Any help is much appreciated.
Thanks,
Nick Hennenfent
[-- Attachment #2: Type: text/html, Size: 954 bytes --]
^ permalink raw reply
* Re: I need help with L2 cache on 440GX rev C
From: Eugene Surovegin @ 2005-07-21 13:18 UTC (permalink / raw)
To: Nick Hennenfent; +Cc: linuxppc-embedded
In-Reply-To: <A3008858EC44C34382A7E3935C24615E01074D3B@egtf001.egt.intra>
On Thu, Jul 21, 2005 at 08:44:46AM -0400, Nick Hennenfent wrote:
>
> I have an embedded 440GX rev C runnng at about 500Mhz.
> I am using a 2.4.20 linux kernel.
> I borrowed Matt Porter's code from the 2.6 kernels in
> order to enable the L2 cache. The code compiles and
> runs ok, but the cache does not seem to be enabled!!!
> I ran some tests with/without the L2 cache code and
> there is no difference.
> (A qsort of 1 million random integers takes 2 seconds).
> Is there some other magic trick to enable that cache????
No, there is no magic involved. 2.6 code (ibm440gx_l2c_enable())
works just fine.
Make sure your firmware doesn't enable L2C itself, in this case kernel
enable code isn't needed at all, and you won't see any difference if
you remove it.
2.6 has /proc/cpuinfo has a 440GX-specific handler
(ibm440gx_show_cpuinfo()), you can put something similar into your 2.4
kernel to see actual L2C state.
--
Eugene
^ permalink raw reply
* swap_dup: Bad swap file entry 00480020
From: bogdan antonovici @ 2005-07-21 15:29 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, ppckernel
Hi,
I have an MPC860 system, 16M flash, 16M SDRAM, no disk, just kernel
support for ramdisk. root fs is nfs mounted.
I get messages like the one bellow:
swap_dup: Bad swap file entry 00480020
VM: killing process chat
swap_free: Bad swap file entry 00480020
and after a while a get an oops:
Oops: kernel access of bad area, sig: 11
NIP: C0045154 XER: 20000000 LR: C0045464 SP: C0CBBE60 REGS: c0cbbdb0
TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00E9A01C, DSISR: C0000000
TASK = c0cba000[36] 'pppd' Last syscall: 142
last math 00000000 last altivec 00000000
GPR00: C0045464 C0CBBE60 C0CBA000 C0CBBE88 C01DE8C0 00000000 C010E2B8
0000001F
GPR08: C0CBA000 00000000 C0C4E03C 00000001 84444448 100B0C5C 10040000
10040000
GPR16: 10040000 10040000 10040000 10040000 C0CBBEF8 00000000 00000001
7FFFFFFF
GPR24: 00000004 00000001 00000145 C0CBBED8 00000004 C0E9A000 C0E9A008
00E9A008
Call backtrace:
C0087D84 C0045464 C0045858 C0009448 C00041DC 1001DB84 10006F24
10006A8C 0FE4BDA0 00000000
At the time of swap messages i was running a proprietary driver, my
application and few daemons.
ps
PID Uid VmSize Stat Command
1 root 584 S init
2 root SW [keventd]
3 root SWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
7 root SW [rpciod]
9 root 760 S -ash
21 root 616 S sectionmond
22 root 608 S sectionmond
23 root 608 S sectionmond
24 root 608 S sectionmond
25 root 612 S sectionmond
26 root 608 S sectionmond
30 root 1304 S /ppcnetsnmp/sbin/snmpd
39 root 916 S pppd /dev/ttyS1 19200 defaultroute demand idle
5 192.
109 root 680 R ps
I look on the net for some clues but it's quite confusing, i noticed
many emails on swap_dup/swap_free error messages but i couldn't figure
out what should i search for.
I tested the ram with mtest from pppboot2.0.
Has any of you an idea what is all about?
Thank you
Bogdan
^ permalink raw reply
* Re: swap_dup: Bad swap file entry 00480020
From: Bogdan Antonovici @ 2005-07-21 18:14 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, ppckernel, linuxppc-embedded
In-Reply-To: <1a928a85f53f5dcd972161356611a312@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
I wasn't so worry about the driver because the same driver worked with a different application without seeing these kind of messages or oopses.
Dan, from your answer i understand that the swap code discovers a corruption in tables but why is swap code run when swap wasn't activated?
I will try to have a look on the driver code.
Bogdan
----- Original Message -----
From: Dan Malek
To: bogdan antonovici
Cc: linuxppc-dev ; linuxppc-embedded@ozlabs.org ; ppckernel
Sent: Thursday, July 21, 2005 12:59 PM
Subject: Re: swap_dup: Bad swap file entry 00480020
On Jul 21, 2005, at 11:29 AM, bogdan antonovici wrote:
> At the time of swap messages i was running a proprietary driver, my
> application and few daemons.
Looks like your driver may have written over some of the page
tables in the kernel space.
> I look on the net for some clues but it's quite confusing, i noticed
> many emails on swap_dup/swap_free error messages but i couldn't figure
> out what should i search for.
Those messages are likely due to a bug with swapping to disk
that has been in some 2.4 kernels, but I don't believe that is
the case here, since you don't have a disk or swapping enabled.
-- Dan
[-- Attachment #2: Type: text/html, Size: 2693 bytes --]
^ permalink raw reply
* Re: swap_dup: Bad swap file entry 00480020
From: Dan Malek @ 2005-07-21 17:59 UTC (permalink / raw)
To: bogdan antonovici; +Cc: linuxppc-dev, ppckernel, linuxppc-embedded
In-Reply-To: <1121959795.800.18.camel@rd-lab>
On Jul 21, 2005, at 11:29 AM, bogdan antonovici wrote:
> At the time of swap messages i was running a proprietary driver, my
> application and few daemons.
Looks like your driver may have written over some of the page
tables in the kernel space.
> I look on the net for some clues but it's quite confusing, i noticed
> many emails on swap_dup/swap_free error messages but i couldn't figure
> out what should i search for.
Those messages are likely due to a bug with swapping to disk
that has been in some 2.4 kernels, but I don't believe that is
the case here, since you don't have a disk or swapping enabled.
-- Dan
^ permalink raw reply
* Re: AW: AW: AW: initrd rootfs ramdisk
From: T Ziomek @ 2005-07-21 21:12 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <000501c58dc6$22246a20$f201a8c0@SN7606>
On Thu, 21 Jul 2005, David Grab wrote:
>
>>> i solved my problem with u-boot and linux. Now i have my rootfs ramdisk
>>> mounted and functioning. But one output is weird.
>
>> Can I ask what what you had to change to get your initrd RAM disk working?
>> I'm having a very similar problem.
>
> Sure! :)
Sigh...found it, after weeks of on-and-off work... Our board has 64 MB of
RAM but I'm passing "mem=32M" to the kernel because we want our app to man-
age the high 32 MB.
U-Boot defaults to copying an initrd into the highest available RAM. That
put it in an area outside of Linux's knowledge, D'OH. All I had to do was
set U-Boot's 'initrd_high' env var and things work.
Thanks for the info anyway; I've saved it.
Tom
--
/"\ ASCII Ribbon Campaign | Email to user 'CTZ001'
\ / | at 'email.mot.com'
X Against HTML |
/ \ in e-mail & news |
^ permalink raw reply
* Re: AW: AW: AW: initrd rootfs ramdisk
From: Wolfgang Denk @ 2005-07-21 23:33 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0507211609080.2672@holyoke.labs.mot.com>
In message <Pine.WNT.4.61.0507211609080.2672@holyoke.labs.mot.com> you wrote:
>
> Sigh...found it, after weeks of on-and-off work... Our board has 64 MB of
> RAM but I'm passing "mem=32M" to the kernel because we want our app to man-
> age the high 32 MB.
>
> U-Boot defaults to copying an initrd into the highest available RAM. That
> put it in an area outside of Linux's knowledge, D'OH. All I had to do was
> set U-Boot's 'initrd_high' env var and things work.
Note: if you want the content of this reserved area to survice
warmboots you can enable the "protected RAM" feature in U-Boot
(CONFIG_PRAM), and it will not touch this area at all. Useful for
things like pramfs for example :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Never worry about theory as long as the machinery does what it's
supposed to do. - R. A. Heinlein
^ permalink raw reply
* Unauthorized transactions on your account
From: security @ 2005-07-21 22:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 14309 bytes --]
^ permalink raw reply
* MPC860 Linux-2.6.12.2 wu-ftpd error
From: Sangmoon Kim @ 2005-07-22 2:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm porting linux-2.6.12.2 on a custom MPC860 board.
It boots okay, but whenever I connect to it through ftp,
I get the following error.
[dogoil@genesis ~]$ ftp 192.168.0.3
Connected to 192.168.0.3.
220 kvme316 FTP server (Version wu-2.6.1(1) Mon Mar 7 07:50:41 MET 2005)
ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (192.168.0.3:dogoil): dogoil
331 Password required for dogoil.
Password:
421 Service not available, remote server has closed connection
Login failed.
No control connection for command: No such file or directory
ftp>
It goes well with linuxppc_2_4_devel (gotten from denx few days ago)
and the same disk image.
On a custom MPC8245 board there is no such problem.
Is it the problem of linux-2.6.12.2?
Did I get something wrong?
Best regards,
Sangmoon Kim
^ permalink raw reply
* please help me !about the idedisk driver!
From: lonelobo @ 2005-07-22 9:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
we have a embeded system .The achitecture is MPC8245+intel82371southbrige+ide hard disk.Now the question is as follow:The ide hard disk can work well int the pio mode,but
in DMA mode it can not work ! The debuge information printed is "DMA time out!" when the driver start the DMA transe process,The hard disk did not generate the interruption.The hard disk had tested to support DMA!
[-- Attachment #2: Type: text/html, Size: 819 bytes --]
^ permalink raw reply
* Experiences with Debian Sarge on MPC8xx ?
From: Raphael Bossek @ 2005-07-22 9:11 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: debian-embedded
Hi,
Debian GNU/Linux v3.1 (Sarge) is out so give it a try on my MPC850
running Debian v3.0 for more then 1 year with Denx's 2.4.20 kernel.
It failed with more or less the same reason as described May 2004
in this posting
http://lists.debian.org/debian-embedded/2004/05/msg00032.html
Things changed since May 2004 but the problem seams to be. I'm using
100% binary compatible Debian GNU/Linux 3.0 (Woody) without any
problems on my MPC860 board with kernel FPU emulation enabled. This
math-emu implementation seams to be stable enought to work with libc6
2.2.5 and very many server application and large C++ application at high
load (our stress tests are really horrible for the compleate system!).
I've also heard from people on IRC that 100% Sarge works for them on
FPU-less MPC boards without trouble. So while I'm investigating the
problem would like to hear some more respond on this issue from
people who spend more time on getting Sarge running with 100% Debian
v3.1 (Sarge) on their MPC8xx environment.
The -msoft-float advice is not what I'm looking for. I'm not sure if
the FPU is responsible for the problem. Maybe the Debian libc6 2.3.2
package is missing something important for the MPC8xx PowerPC (the
cache-line-size is 4 for Debian's libc on PowerPC by default). The
big advantage using a standard distribution is the big number of
precompiled packages. I do not intent to recompile more then 18000
due to this first failed tests.
--
Raphael Bossek
^ permalink raw reply
* DMA-transfer on 440ep
From: extabe @ 2005-07-22 9:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having problem with DMA on the EBC bus on the PPC440ep preocessor. Previously we have the dma code working on the PPC405gpr.
We are doing a read and write from pheriperal to memory and the system hangs a short time after enabling the dma channel.
Using linux 2.4.20 and the same kernel-dma code as for 405 (patched ppc4xx_dma.c/sgdma.c).
Changes i've made for the 440ep:
* the GPIO multiplexing for DMA is setup correctly (at least i'm getting a DMAreq on the channel).
* the EBC is 16 bits instead of 32 (PW_16 in dma setup).
* the irqs are on different numbers. (dma irq works)
Also if i do a memory to memory transfer just for debugging, the dma works as far as not hanging, but no data has changed in the destination memory when the transfer is done...
* Are there more setup to be made to get the dma controller to be enabled?
* What is the DMA2P30_ADR register good for?
What am i missing?
^ permalink raw reply
* Re: Experiences with Debian Sarge on MPC8xx ?
From: Wolfgang Denk @ 2005-07-22 9:50 UTC (permalink / raw)
To: Raphael Bossek; +Cc: debian-embedded, linuxppc-embedded
In-Reply-To: <42E0B826.2070800@gmx.de>
Dear Raphael,
in message <42E0B826.2070800@gmx.de> you wrote:
>
> Debian GNU/Linux v3.1 (Sarge) is out so give it a try on my MPC850
> running Debian v3.0 for more then 1 year with Denx's 2.4.20 kernel.
>
> It failed with more or less the same reason as described May 2004
> in this posting
> http://lists.debian.org/debian-embedded/2004/05/msg00032.html
>
> Things changed since May 2004 but the problem seams to be. I'm using
> 100% binary compatible Debian GNU/Linux 3.0 (Woody) without any
> problems on my MPC860 board with kernel FPU emulation enabled. This
> math-emu implementation seams to be stable enought to work with libc6
> 2.2.5 and very many server application and large C++ application at high
> load (our stress tests are really horrible for the compleate system!).
I guess you are aware that the FPU emulation is a nightmare perfor-
mance-wise - you take a kernel exception for each and every FP
instruction. FP execution is several orders faster when you use
soft-float (which, of course, requires all soft-float libraries,
too).
> I've also heard from people on IRC that 100% Sarge works for them on
> FPU-less MPC boards without trouble. So while I'm investigating the
> problem would like to hear some more respond on this issue from
> people who spend more time on getting Sarge running with 100% Debian
> v3.1 (Sarge) on their MPC8xx environment.
This is probably not a FP issue but may be related to the cache line
size and/or the infamous "dcbz" misbehaviour. The standard fix
(removing memset.S when building glibc) has been discussed many times
before; see for example the patches / build scripts for our EDK or
Dan Kegel's crosstool.
> The -msoft-float advice is not what I'm looking for. I'm not sure if
> the FPU is responsible for the problem. Maybe the Debian libc6 2.3.2
> package is missing something important for the MPC8xx PowerPC (the
> cache-line-size is 4 for Debian's libc on PowerPC by default). The
4 what? Bytes?
> big advantage using a standard distribution is the big number of
> precompiled packages. I do not intent to recompile more then 18000
> due to this first failed tests.
You don't intend to use 18000 packages on your embedded system either
;-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Free markets select for winning solutions." - Eric S. Raymond
^ permalink raw reply
* AMCC 440EP (Bamboo board) support?
From: Frank Lautenbach @ 2005-07-22 9:47 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Did anyone bring up linux already on this kind of board? If yes, please
let me know. If not, any hints how to start from scratch
starting with a kernel tree are higly welcome!
Regards,
Frank
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox