Re: Linux 2.6.x on 8xx status

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Song Sam wrote:
> "Smith, Craig" <craig.d.smith@siemens.com> wrote:
>  
> 
>>Right now, I just want to know if I should expect to
>>see funny behavior from this particular source tree
>>on an 8xx platform or should it work OK? Thanks so 
>>much.
> 
> 
> Well, as I have tested so far, 2.6.x can only work
> right on 8xx with RAMDISK root file system. As for
> NFS, still no luck.

Well it could have fooled me since I have it running
right here...

Don't use the old etherner driver.


> 
> Best regards,
> 
> Sam
> 
> _________________________________________________________
> Do You Yahoo!?
> 150万曲MP3疯狂搜，带您闯入音乐殿堂
> http://music.yisou.com/
> 美女明星应有尽有，搜遍美图、艳图和酷图
> http://image.yisou.com
> 1G就是1000兆，雅虎电邮自助扩容！
> http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Song Sam]

"Smith, Craig" <craig.d.smith@siemens.com> wrote:
 
> Right now, I just want to know if I should expect to
> see funny behavior from this particular source tree
> on an 8xx platform or should it work OK? Thanks so 
> much.

Well, as I have tested so far, 2.6.x can only work
right on 8xx with RAMDISK root file system. As for
NFS, still no luck.

Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Song Sam]

Pantelis Antoniou <panto@intracom.gr> wrote：
> > Well, as I have tested so far, 2.6.x can only work
> > right on 8xx with RAMDISK root file system. As for
> > NFS, still no luck.
> 
> Well it could have fooled me since I have it running
> right here...
> 
> Don't use the old etherner driver.

After following your instruction, I tested fec_8xx
driver on RPXlite DW.
Changes were made as follows:
1. Mask __fw_getenv and 'ethaddr' code in
fec_8xx-netta.c to avoid compiling error 'undefined
reference to __fw_getenv';
2. Replace NETTA as RPXLITE in ..fec_8xx/Makefile &&
Kconfig;

Yeah, the result is so close to work right on RPXlite
DW. So great, a lot improvement. But still a pity...

---------------------------------------------------

U-Boot 1.1.2 (Aug 31 2004 - 09:47:03)

CPU:   PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB
D-Cache
Board: RPXlite_DW
DRAM:  64 MB
FLASH: 16 MB
Hit any key to stop autoboot:  0
u-boot>run net_nfs
Using SCC ETHERNET device
TFTP from server 172.16.115.6; our IP address is
172.16.115.7
Filename 'uImage.rpx26nfs919'.
Load address: 0x200000
Loading:
#################################################################
done
Bytes transferred = 726996 (b17d4 hex)
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.9-rc2
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    726932 Bytes = 709.9 kB
   Load Address: 00000000
   Entry Point:  00000000
   Uncompressing Kernel Image ... OK
Linux version 2.6.9-rc2 (root@shu.edu.net) (gcc
version 3.2.2 20030217 (Yellow Dog Linux 3.0
3.2.2-2a_1)) #1 Sun Sep 19 02:33:02 CST 2004
Built 1 zonelists
Kernel command line: root=/dev/nfs rw
nfsroot=172.16.115.6:/workspace/myfilesystem/target/
ip=172.16.115.7:172.16.115.6:172.16.115.254:255.255.255.0::eth0:off
panic=1
PID hash table entries: 512 (order: 9, 8192 bytes)
Decrementer Frequency = 180000000/60
Dentry cache hash table entries: 16384 (order: 4,
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 63104k available (1272k kernel code, 288k
data, 72k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
NET: Registered protocol family 16
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART
ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
fec_8xx.c:v0.1 (May 6, 2004)
FEC Reset timeout!
fec_8xx: eth0 No PHY detected!
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind
8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
FEC Reset timeout!
IP-Config: Complete:
      device=eth0, addr=172.16.115.7,
mask=255.255.255.0, gw=172.16.115.254,
     host=172.16.115.7, domain=, nis-domain=(none),
     bootserver=172.16.115.6, rootserver=172.16.115.6,
rootpath=
Looking up port of RPC 100003/2 on 172.16.115.6
portmap: server 172.16.115.6 not responding, timed out
Root-NFS: Unable to get nfsd port number from server,
using default
Looking up port of RPC 100005/1 on 172.16.115.6
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
portmap: server 172.16.115.6 not responding, timed out
Root-NFS: Unable to get mountd port number from
server, using default
NETDEV WATCHDOG: eth0: transmit timed out
[snip]
NETDEV WATCHDOG: eth0: transmit timed out
mount: server 172.16.115.6 not responding, timed out
Root-NFS: Server returned error -5 while mounting
/workspace/myfilesystem/target/
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or
unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(2,0)
 <0>Rebooting in 1 seconds..<6>NETDEV WATCHDOG: eth0:
transmit timed out
-----------------------------------------------

Idea?

Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Song Sam wrote:
> Pantelis Antoniou <panto@intracom.gr> wrote：
> 
>>>Well, as I have tested so far, 2.6.x can only work
>>>right on 8xx with RAMDISK root file system. As for
>>>NFS, still no luck.
>>
>>Well it could have fooled me since I have it running
>>right here...
>>
>>Don't use the old etherner driver.
> 
> 
> After following your instruction, I tested fec_8xx
> driver on RPXlite DW.
> Changes were made as follows:
> 1. Mask __fw_getenv and 'ethaddr' code in
> fec_8xx-netta.c to avoid compiling error 'undefined
> reference to __fw_getenv';
> 2. Replace NETTA as RPXLITE in ..fec_8xx/Makefile &&
> Kconfig;
> 
> Yeah, the result is so close to work right on RPXlite
> DW. So great, a lot improvement. But still a pity...
> 
> ---------------------------------------------------
> 
> U-Boot 1.1.2 (Aug 31 2004 - 09:47:03)
> 
> CPU:   PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB
> D-Cache
> Board: RPXlite_DW
> DRAM:  64 MB
> FLASH: 16 MB
> Hit any key to stop autoboot:  0
> u-boot>run net_nfs
> Using SCC ETHERNET device
> TFTP from server 172.16.115.6; our IP address is
> 172.16.115.7
> Filename 'uImage.rpx26nfs919'.
> Load address: 0x200000
> Loading:
> #################################################################
> done
> Bytes transferred = 726996 (b17d4 hex)
> ## Booting image at 00200000 ...
>    Image Name:   Linux-2.6.9-rc2
>    Image Type:   PowerPC Linux Kernel Image (gzip
> compressed)
>    Data Size:    726932 Bytes = 709.9 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Uncompressing Kernel Image ... OK
> Linux version 2.6.9-rc2 (root@shu.edu.net) (gcc
> version 3.2.2 20030217 (Yellow Dog Linux 3.0
> 3.2.2-2a_1)) #1 Sun Sep 19 02:33:02 CST 2004
> Built 1 zonelists
> Kernel command line: root=/dev/nfs rw
> nfsroot=172.16.115.6:/workspace/myfilesystem/target/
> ip=172.16.115.7:172.16.115.6:172.16.115.254:255.255.255.0::eth0:off
> panic=1
> PID hash table entries: 512 (order: 9, 8192 bytes)
> Decrementer Frequency = 180000000/60
> Dentry cache hash table entries: 16384 (order: 4,
> 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768
> bytes)
> Memory: 63104k available (1272k kernel code, 288k
> data, 72k init, 0k highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096
> bytes)
> NET: Registered protocol family 16
> Serial: CPM driver $Revision: 0.01 $
> ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART
> ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART
> RAMDISK driver initialized: 16 RAM disks of 4096K size
> 1024 blocksize
> loop: loaded (max 8 devices)
> fec_8xx.c:v0.1 (May 6, 2004)
> FEC Reset timeout!
> fec_8xx: eth0 No PHY detected!
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 4096 bind
> 8192)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> FEC Reset timeout!
> IP-Config: Complete:
>       device=eth0, addr=172.16.115.7,
> mask=255.255.255.0, gw=172.16.115.254,
>      host=172.16.115.7, domain=, nis-domain=(none),
>      bootserver=172.16.115.6, rootserver=172.16.115.6,
> rootpath=
> Looking up port of RPC 100003/2 on 172.16.115.6
> portmap: server 172.16.115.6 not responding, timed out
> Root-NFS: Unable to get nfsd port number from server,
> using default
> Looking up port of RPC 100005/1 on 172.16.115.6
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> NETDEV WATCHDOG: eth0: transmit timed out
> portmap: server 172.16.115.6 not responding, timed out
> Root-NFS: Unable to get mountd port number from
> server, using default
> NETDEV WATCHDOG: eth0: transmit timed out
> [snip]
> NETDEV WATCHDOG: eth0: transmit timed out
> mount: server 172.16.115.6 not responding, timed out
> Root-NFS: Server returned error -5 while mounting
> /workspace/myfilesystem/target/
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "nfs" or
> unknown-block(2,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(2,0)
>  <0>Rebooting in 1 seconds..<6>NETDEV WATCHDOG: eth0:
> transmit timed out
> -----------------------------------------------
> 
> Idea?
> 
> Best regards,
> 
> Sam

Ahem, the new ethernet driver is for the FEC not the SCC.

By the bootload messages RPXlite uses the SCC ethernet.

I'm afraid someone has to step up and fix the old ethernet
driver. I don't have any hardware that uses it.

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Song Sam]

Pantelis Antoniou <panto@intracom.gr> wrote：
> Ahem, the new ethernet driver is for the FEC not the
> SCC.

Oh, I misused the driver but got the improvement. A
little strange...

> By the bootload messages RPXlite uses the SCC
> ethernet.

Yeah, RPXlite uses SCC2 as Ethernet Controller.

Thanks for pointing out the key problem.

Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Tom Rini]

On Fri, Sep 17, 2004 at 12:55:51PM +0300, Pantelis Antoniou wrote:
> Song Sam wrote:
> > "Smith, Craig" <craig.d.smith@siemens.com> wrote:
> >  
> > 
> >>Right now, I just want to know if I should expect to
> >>see funny behavior from this particular source tree
> >>on an 8xx platform or should it work OK? Thanks so 
> >>much.
> > 
> > 
> > Well, as I have tested so far, 2.6.x can only work
> > right on 8xx with RAMDISK root file system. As for
> > NFS, still no luck.
> 
> Well it could have fooled me since I have it running
> right here...
> 
> Don't use the old etherner driver.

Note that the old SCC enet driver, in linuxppc-2.5 at least is 'OK'.
Not that it couldn't do with a cleanup and netdev person audit, but it's
functional enough for me and my rpxlite to mount a root fs.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: Linux 2.6.x on 8xx status

[Robert P. J. Day]

On Mon, 20 Sep 2004, Tom Rini wrote:

> Note that the old SCC enet driver, in linuxppc-2.5 at least is 'OK'.
> Not that it couldn't do with a cleanup and netdev person audit, but it's
> functional enough for me and my rpxlite to mount a root fs.

sorry to jump into this conversation late -- which "2.6.x" source tree 
is being used here?

for quite some time, i've just used the linuxppx-2.5 tree at 
ppc.bkbits.net.  but when someone refers to a 2.6.x tree, which one 
specifically is this?  just the latest BK update from www.kernel.org?
or is this a PPC-specific tree?

rday

Re: Linux 2.6.x on 8xx status

[Tom Rini]

On Mon, Sep 20, 2004 at 02:02:43PM -0400, Robert P. J. Day wrote:

> On Mon, 20 Sep 2004, Tom Rini wrote:
> 
> >Note that the old SCC enet driver, in linuxppc-2.5 at least is 'OK'.
> >Not that it couldn't do with a cleanup and netdev person audit, but it's
> >functional enough for me and my rpxlite to mount a root fs.
> 
> sorry to jump into this conversation late -- which "2.6.x" source tree 
> is being used here?

As I said, linuxppc-2.5 is where the working driver is right now.

> for quite some time, i've just used the linuxppx-2.5 tree at 
> ppc.bkbits.net.  but when someone refers to a 2.6.x tree, which one 
> specifically is this?  just the latest BK update from www.kernel.org?
> or is this a PPC-specific tree?

The only trees that matter here are linuxppc-2.5 (on ppc.bkbits.net) and
linux-2.6 (on linux.bkbits.net).  Everthing else "2.6.x" is a snapshot
of one form or another of the linux-2.6 tree.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: Linux 2.6.x on 8xx status

[Song Sam]

Tom Rini <trini@kernel.crashing.org> wrote：
> Note that the old SCC enet driver, in linuxppc-2.5
> at least is 'OK'.
> Not that it couldn't do with a cleanup and netdev
> person audit, but it's
> functional enough for me and my rpxlite to mount a
> root fs.
> 
> -- 
> Tom Rini
> http://gate.crashing.org/~trini/

Uh, I tried it again on lastest bk pull but still in
vain. What's the problem could be?

--------------------------------------------------
u-boot>set bootfile uImage.rpx26scc2
u-boot>run net_nfs
Using SCC ETHERNET device
TFTP from server 172.16.115.6; our IP address is
172.16.115.7
Filename 'uImage.rpx26scc2'.
Load address: 0x200000
Loading:
####################################################
done
Bytes transferred = 735617 (b3981 hex)
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.9-rc2
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    735553 Bytes = 718.3 kB
   Load Address: 00000000
   Entry Point:  00000000
   Uncompressing Kernel Image ... OK
Linux version 2.6.9-rc2 (root@shu.edu.net) (gcc
version 3.2.2 20030217 (Yellow Dog Linux 3.0
3.2.2-2a_1)) #1 Tue Sep 21 09:11:09 CST 2004
Built 1 zonelists
Kernel command line: root=/dev/nfs rw
nfsroot=172.16.115.6:/workspace/myfilesystem/target/
ip=172.16.115.7:172.16.115.6:172.16.115.254:255.255.255.0::eth0:off
panic=1
PID hash table entries: 512 (order: 9, 8192 bytes)
Decrementer Frequency = 180000000/60
Dentry cache hash table entries: 16384 (order: 4,
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 63104k available (1292k kernel code, 292k
data, 72k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
NET: Registered protocol family 16
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART
ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
eth0: CPM ENET Version 0.2 on SCC2, 00:10:ec:00:37:5b
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind
8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
      device=eth0, addr=172.16.115.7,
mask=255.255.255.0, gw=172.16.115.254,
     host=172.16.115.7, domain=, nis-domain=(none),
     bootserver=172.16.115.6, rootserver=172.16.115.6,
rootpath=
Looking up port of RPC 100003/2 on 172.16.115.6
Looking up port of RPC 100005/1 on 172.16.115.6
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 72k init
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0008D98 LR: C000DDAC SP: C0299E00 REGS: c0299d50
TRAP: 0300    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 0FFC9BD4, DSISR: C2000000
TASK = c028fba0[1] 'init' THREAD: c0298000Last
syscall: 6
GPR00: C018ACA0 C0299E00 C028FBA0 0FFC9000 00000100
00003C55 0FFC9000 C0396F24
GPR08: C0190000 C018ACA0 00000000 00078AA0 01160040
1001EE38 03FB1900 00000000
GPR16: 007FFF91 00000000 7FFFF640 007FFF00 00000073
00000001 0FFC9000 C018ACA0
GPR24: 00000000 00000000 C01890FC 00000000 0FFC9BD4
03C55889 C022BAA0 C022BAA0
Call trace: [c003d0e4]  [c003d460]  [c000d35c] 
[c0006608]
Kernel panic - not syncing: Attempted to kill init!
 <0>Rebooting in 1 seconds..

U-Boot 1.1.2 (Aug 31 2004 - 09:47:03)

CPU:   PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB
D-Cache
Board: RPXlite_DW
DRAM:  64 MB
FLASH: 16 MB
Hit any key to stop autoboot:  0
u-boot>

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.9-rc2
# Tue Sep 21 09:04:50 2004
#
CONFIG_MMU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_HOTPLUG is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_EMBEDDED=y
# CONFIG_KALLSYMS is not set
CONFIG_FUTEX=y
# CONFIG_EPOLL is not set
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor
#
# CONFIG_6xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
CONFIG_8xx=y
# CONFIG_E500 is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_CPU_FREQ is not set
CONFIG_EMBEDDEDBOOT=y
CONFIG_NOT_COHERENT_CACHE=y

#
# Platform options
#
CONFIG_RPXLITE=y
# CONFIG_RPXCLASSIC is not set
# CONFIG_BSEIP is not set
# CONFIG_FADS is not set
# CONFIG_TQM823L is not set
# CONFIG_TQM850L is not set
# CONFIG_TQM855L is not set
# CONFIG_TQM860L is not set
# CONFIG_FPS850L is not set
# CONFIG_SPD823TS is not set
# CONFIG_IVMS8 is not set
# CONFIG_IVML24 is not set
# CONFIG_SM850 is not set
# CONFIG_HERMES_PRO is not set
# CONFIG_IP860 is not set
# CONFIG_LWMON is not set
# CONFIG_PCU_E is not set
# CONFIG_CCM is not set
# CONFIG_LANTEC is not set
# CONFIG_MBX is not set
# CONFIG_WINCEPT is not set
CONFIG_SERIAL_CONSOLE=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_HIGHMEM is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_CMDLINE_BOOL is not set

#
# Bus options
#
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
# CONFIG_PCI_QSPAN is not set

#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set

#
# Default settings for advanced configuration options
are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x00400000

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD 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_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support
#

#
# I2O device support
#

#
# Macintosh device drivers
#

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_NETFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_FEC_8XX is not set

#
# Ethernet (1000 Mbit)
#

#
# Ethernet (10000 Mbit)
#

#
# Token Ring devices
#

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
CONFIG_SERIAL_CPM_SCC1=y
# CONFIG_SERIAL_CPM_SCC2 is not set
# CONFIG_SERIAL_CPM_SCC3 is not set
# CONFIG_SERIAL_CPM_SCC4 is not set
CONFIG_SERIAL_CPM_SMC1=y
# CONFIG_SERIAL_CPM_SMC2 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=y
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_SYSFS is not set
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
# CONFIG_EXPORTFS is not set
CONFIG_SUNRPC=y
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_MSDOS_PARTITION is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# MPC8xx CPM Options
#
CONFIG_SCC_ENET=y
# CONFIG_SCC1_ENET is not set
CONFIG_SCC2_ENET=y
# CONFIG_SCC3_ENET is not set
# CONFIG_FEC_ENET is not set
# CONFIG_ENET_BIG_BUFFERS is not set
# CONFIG_8xx_UART is not set

#
# Generic MPC8xx Options
#
CONFIG_8xx_COPYBACK=y
# CONFIG_8xx_CPU6 is not set
# CONFIG_UCODE_PATCH is not set

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC32 is not set
# CONFIG_LIBCRC32C is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
---------------------------------------------------

Best regards, 

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Song Sam wrote:

>  Tom Rini <trini@kernel.crashing.org> wrote：
>
> > Note that the old SCC enet driver, in linuxppc-2.5 at least is
> > 'OK'. Not that it couldn't do with a cleanup and netdev person
> > audit, but it's functional enough for me and my rpxlite to mount a
> > root fs.
> >
> > -- Tom Rini http://gate.crashing.org/~trini/
>
>
>  Uh, I tried it again on lastest bk pull but still in vain. What's the
>  problem could be?
>
Well it works OK until it gets to start init.

Then it crashes the way it is supposed to :).

Tom I think it's the problem we are talking about.

Song please try this...

Song Sam wrote:

>  Tom Rini <trini@kernel.crashing.org> wrote：
>
> > Note that the old SCC enet driver, in linuxppc-2.5 at least is
> > 'OK'. Not that it couldn't do with a cleanup and netdev person
> > audit, but it's functional enough for me and my rpxlite to mount a
> > root fs.
> >
> > -- Tom Rini http://gate.crashing.org/~trini/
>
>
>  Uh, I tried it again on lastest bk pull but still in vain. What's the
>  problem could be?
>
Well it works OK until it gets to start init.

Then it crashes the way it is supposed to :).

Tom I think it's the problem we are talking about.

Song please try this...

Regards

Pantelis

--- linuxppc_2.5/arch/ppc/mm/init.c 2004-08-26 10:21:00.000000000 +0300
+++ linuxppc_2.5-intracom/arch/ppc/mm/init.c 2004-08-26 
10:34:00.000000000 +0300
@@ -632,9 +632,10 @@
struct page *page = pfn_to_page(pfn);
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
- if (vma->vm_mm == current->active_mm)
- __flush_dcache_icache((void *) address);
- else
+ if (vma->vm_mm == current->active_mm) {
+ _tlbie(address);
+ __flush_dcache_icache((void *)address);
+ } else
flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
}

Re: Linux 2.6.x on 8xx status

[Song Sam]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312, Size: 4998 bytes --]

Pantelis Antoniou <panto@intracom.gr> wrote£º
> Well it works OK until it gets to start init.
> 
> Then it crashes the way it is supposed to :).
> 
> Tom I think it's the problem we are talking about.
> 
> Song please try this...

Guess what? It WORKED!!! Just one more line make it.
Could you pls tell us the theory in it if not too
complicated? :-)

Well Done!

----------------------------------------------------

u-boot>run net_nfs
Using SCC ETHERNET device
TFTP from server 172.16.115.33; our IP address is
172.16.115.7
Filename 'uImage.rpx26scc2pa'.
Load address: 0x200000
Loading:
#################################################################
        
#################################################################
         ##############
done
Bytes transferred = 735596 (b396c hex)
## Booting image at 00200000 ...
   Image Name:   Linux-2.6.9-rc2
   Image Type:   PowerPC Linux Kernel Image (gzip
compressed)
   Data Size:    735532 Bytes = 718.3 kB
   Load Address: 00000000
   Entry Point:  00000000
   Uncompressing Kernel Image ... OK
Linux version 2.6.9-rc2 (root@shu.edu.net) (gcc
version 3.2.2 20030217 (Yellow Dog Linux 3.0
3.2.2-2a_1)) #1 Tue Sep 21 15:10:34 CST 2004
Built 1 zonelists
Kernel command line: root=/dev/nfs rw
nfsroot=172.16.115.33:/opt/eldk/ppc_8xx
ip=172.16.115.7:172.16.115.33:172.16.115.254:255.255.255.0::eth0:off
panic=1
PID hash table entries: 512 (order: 9, 8192 bytes)
Decrementer Frequency = 180000000/60
Dentry cache hash table entries: 16384 (order: 4,
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 63104k available (1292k kernel code, 292k
data, 72k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
NET: Registered protocol family 16
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART
ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
eth0: CPM ENET Version 0.2 on SCC2, 00:10:ec:00:37:5b
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind
8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
      device=eth0, addr=172.16.115.7,
mask=255.255.255.0, gw=172.16.115.254,
     host=172.16.115.7, domain=, nis-domain=(none),
     bootserver=172.16.115.33,
rootserver=172.16.115.33, rootpath=
Looking up port of RPC 100003/2 on 172.16.115.33
Looking up port of RPC 100005/1 on 172.16.115.33
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 72k initýN??: version
2.84 booting
                Welcome to DENX Embedded Linux
Environment
                Press 'I' to enter interactive
startup.
Building the cache [  OK  ]
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our
search for an access method.
Setting clock : Wed Dec 31 19:44:24 EST 1969 [  OK  ]
Setting hostname 172.16.115.7:  [  OK  ]
modprobe: Can't open dependencies file
/lib/modules/2.6.9-rc2/modules.dep (No such file or
directory)
Activating swap partitions:  [  OK  ]
Checking filesystems
[  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling swap space:  [  OK  ]
modprobe: Can't open dependencies file
/lib/modules/2.6.9-rc2/modules.dep (No such file or
directory)
Entering non-interactive startup
Setting network parameters:  [  OK  ]
Bringing up loopback interface:  [  OK  ]
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Initializing random number generator:  [  OK  ]
Starting portmapper: [  OK  ]
Mounting NFS filesystems:  [  OK  ]
Mounting other filesystems:  [  OK  ]
Starting xinetd: [  OK  ]

172 login: root
bash-2.05b# cd /
bash-2.05b# ls
bin  boot  dev  etc  images  lib  mnt  proc  root 
sbin  tmp  usr  var
bash-2.05b# reboot
INIT: Switching to runlevel: 6
bash-2.05b#
INIT: Sending processes the TERM signal
Starting killall:  [  OK  ]
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Syncing hardware clock to system time Cannot access
the Hardware Clock via any known method.
Use the --debug option to see the details of our
search for an access method.

mount: directory to mount not in host:dir format
Please stand by while rebooting the system...
Restarting syst

U-Boot 1.1.2 (Aug 31 2004 - 09:47:03)

CPU:   PPC823EZTnnB2 at 48 MHz: 16 kB I-Cache 8 kB
D-Cache
Board: RPXlite_DW
DRAM:  64 MB
FLASH: 16 MB
Hit any key to stop autoboot:  0
u-boot>

--------------------------------------------------

Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌÃ
http://music.yisou.com/
ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ
http://image.yisou.com
1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Song Sam wrote:

>Pantelis Antoniou <panto@intracom.gr> wrote£º
>
>>Well it works OK until it gets to start init.
>>
>>Then it crashes the way it is supposed to :).
>>
>>Tom I think it's the problem we are talking about.
>>
>>Song please try this...
>>
>
>Guess what? It WORKED!!! Just one more line make it.
>Could you pls tell us the theory in it if not too
>complicated? :-)
>
>Well Done!
>
Oh man Dan will kill me :)

The theory is simple, TLB handling is faulty for 8xx.

This patch fixes it but Dan & Ben think it's just by
coincedence and we should fix it properly.

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Tue, Sep 21, 2004 at 01:41:50PM +0300, Pantelis Antoniou wrote:
> Song Sam wrote:
>=20
> >Pantelis Antoniou <panto@intracom.gr> wrote=A3=BA
> >
> >>Well it works OK until it gets to start init.
> >>
> >>Then it crashes the way it is supposed to :).
> >>
> >>Tom I think it's the problem we are talking about.
> >>
> >>Song please try this...
> >>
> >
> >Guess what? It WORKED!!! Just one more line make it.
> >Could you pls tell us the theory in it if not too
> >complicated? :-)
> >
> >Well Done!
> >
> Oh man Dan will kill me :)
>=20
> The theory is simple, TLB handling is faulty for 8xx.
>=20
> This patch fixes it but Dan & Ben think it's just by
> coincedence and we should fix it properly.

Hi Pantelis, others,

And what has to be done to be fixed properly?=20

Ie what is the problem in detail?

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Marcelo Tosatti wrote:
> On Wed, Mar 23, 2005 at 11:12:11AM -0500, Dan Malek wrote:
> 
>>On Mar 23, 2005, at 5:25 AM, Marcelo Tosatti wrote:
>>
>>
>>>You misunderstood: get_mmu_context() _wont_ be called if the mm 
>>>structures
>>>are the same.
>>
>>I understood.  At most, get_mmu_context() will only do a 'tlbia'
>>instruction, I didn't see your reason for thinking this would have
>>an effect on the tlbie usage.
> 
> 
> OK. That is not a good reason, indeed.
> 
> 
>>>>Well, that's interesting.  It's likely to only happen on an 860 
>>>>variant
>>>>that
>>>>has the large TLB.
>>>
>>>For what reasoning?
>>
>>My initial debugging seemed to indicate a stale TLB entry.  With
>>the larger TLB this is more likely to happen.  The bug was never
>>seen on the 823/850 with smaller TLBs.
>>
>>I have a new 8xx board now, so I'll have to start working on these
>>issues as well.
> 
> 
> OK!

I've just managed to get 2.6.12-rc1 running on my 870 based board
and the tlb invalidate is still needed.

Investigating...

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Mar 23, 2005, at 5:25 AM, Marcelo Tosatti wrote:

> You misunderstood: get_mmu_context() _wont_ be called if the mm 
> structures
> are the same.

I understood.  At most, get_mmu_context() will only do a 'tlbia'
instruction, I didn't see your reason for thinking this would have
an effect on the tlbie usage.

>> Well, that's interesting.  It's likely to only happen on an 860 
>> variant
>> that
>> has the large TLB.
>
> For what reasoning?

My initial debugging seemed to indicate a stale TLB entry.  With
the larger TLB this is more likely to happen.  The bug was never
seen on the 823/850 with smaller TLBs.

I have a new 8xx board now, so I'll have to start working on these
issues as well.

Thanks.


	-- Dan

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Wed, Mar 23, 2005 at 11:12:11AM -0500, Dan Malek wrote:
> 
> On Mar 23, 2005, at 5:25 AM, Marcelo Tosatti wrote:
> 
> >You misunderstood: get_mmu_context() _wont_ be called if the mm 
> >structures
> >are the same.
> 
> I understood.  At most, get_mmu_context() will only do a 'tlbia'
> instruction, I didn't see your reason for thinking this would have
> an effect on the tlbie usage.

OK. That is not a good reason, indeed.

> >>Well, that's interesting.  It's likely to only happen on an 860 
> >>variant
> >>that
> >>has the large TLB.
> >
> >For what reasoning?
> 
> My initial debugging seemed to indicate a stale TLB entry.  With
> the larger TLB this is more likely to happen.  The bug was never
> seen on the 823/850 with smaller TLBs.
> 
> I have a new 8xx board now, so I'll have to start working on these
> issues as well.

OK!

Re: Linux 2.6.x on 8xx status

[Guillaume Autran]

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]



Marcelo Tosatti wrote:

>On Tue, Mar 22, 2005 at 03:57:08PM -0500, Dan Malek wrote:
>  
>
>>On Mar 22, 2005, at 8:04 AM, Marcelo Tosatti wrote:
>>
>>    
>>
>>>I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
>>>less times than v2.4 ?
>>>      
>>>
>
>That was rather a _factor_ of "100-or-so" less.
>
>  
>
>>Oh my ...  I'm more worried about the high number of TLB misses
>>in 2.6 compared to 2.4.  That's really bad.  
>>    
>>
>
>Newbie question: What prevents the initial kernel map (tuple of 8Mbyte I/D-TLB entries) 
>and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation pressure,
>in case CONFIG_PIN_TLB is disabled ? 
>
>  
>
>>How did you instrument the tlbie measurement? 
>>    
>>
>
>By a counter at the end of _tlbie function, similar to other counters which 
>you suggested.
>
>  
>
>>It could be that 2.4 used lots more 'tlbia' which were replaced by tlbie in 2.6.
>>    
>>
>
>Dont think thats the case given that v2.4 calls tlbia through flush_tlb_mm() at exit_mmap() 
>only. And at vmalloc_free which shouldnt be called at all.
>
>I just noticed this conditional at switch_mm() (v2.6), which _can_ partly 
>explain the reduced tlbie's  (its just a guess for now, though):
>
>static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>                             struct task_struct *tsk)
>{
>#ifdef CONFIG_ALTIVEC
>        asm volatile (
> BEGIN_FTR_SECTION
>        "dssall;\n"
>#ifndef CONFIG_POWER4
>         "sync;\n" /* G4 needs a sync here, G5 apparently not */
>#endif
> END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
>         : : );
>#endif /* CONFIG_ALTIVEC */
>                                                                                            
>        tsk->thread.pgdir = next->pgd;
>                                                                                            
>        /* No need to flush userspace segments if the mm doesnt change */
>	if (prev == next) 				<--------------
>		return;   				<--------------
>                                                                                            
>        /* Setup new userspace context */
>        get_mmu_context(next);
>        set_context(next->context, next->pgd);
>}
>
>I'm about to disable it and retry.
>
>Spent part of the day reading the MMU section of 860 manual, I think I have kind 
>of a clue how things are supposed to work at the lowlevel now. 
>
>I'll continue tracking it down - any help is appreciated.
>
>PS: I can't reproduce the invalid TLB crash anymore. i.e. even by removing
>the _tlbie() at update_mmu_cache() everything is working as expected.
>
>How can I reproduce it again? Guillaume, what kernel version are you using?
>
>  
>
It is very timing dependant. Running 2.6.11, ldconfig crashes in 
__flush_dcache_icache(...) just after boot time (first time called). 
Unfortunatly, it only happens every now and then. And of course, never 
when my BDI2000 is plugged in. :(

I also noticed that with kernel preemption disable, oops are less 
frequent. Probably does not mean anything anyway...

Guillaume.


-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
======================================= 


[-- Attachment #2: Type: text/html, Size: 4130 bytes --]

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Tue, Mar 22, 2005 at 05:53:40PM -0500, Dan Malek wrote:
> 
> On Mar 22, 2005, at 12:58 PM, Marcelo Tosatti wrote:
> 
> >Newbie question: What prevents the initial kernel map (tuple of 8Mbyte 
> >I/D-TLB entries)
> >and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation 
> >pressure,
> >in case CONFIG_PIN_TLB is disabled ?
> 
> Nothing.  In fact, they are likely invalidated shortly after the kernel
> page tables are set up.  This was only done to ensure we could get the
> kernel initialized without taking page faults.

OK.

> >By a counter at the end of _tlbie function, similar to other counters 
> >which
> >you suggested.
> 
> OK.
> 
> >Dont think thats the case given that v2.4 calls tlbia through 
> >flush_tlb_mm() at exit_mmap()
> >only. And at vmalloc_free which shouldnt be called at all.
> 
> Hmmm ...  Then, the 2.6 looks to be much less efficient with the MMU
> resources than 2.4 was.  This is going to affect everyone, it's just 
> easier
> to measure on this processor.

Many codepaths are longer (eg. but the difference 

> 
> >I just noticed this conditional at switch_mm() (v2.6), which _can_ 
> >partly
> >explain the reduced tlbie's  (its just a guess for now, though):
> 
> What is your guess?  I don't know how this would reduce the number
> of tlbie instructions, since stealing a context (as part of 
> get_context())
> will simply whack the whole TLB with a tlbia.  On 8xx, both instructions
> could be simply implemented as macros.

You misunderstood: get_mmu_context() _wont_ be called if the mm structures 
are the same.

v2.4 didnt had this optimization. 

> >Spent part of the day reading the MMU section of 860 manual, I think I 
> >have kind
> >of a clue how things are supposed to work at the lowlevel now.
> 
> :-)
> 
> >PS: I can't reproduce the invalid TLB crash anymore. i.e. even by 
> >removing
> >the _tlbie() at update_mmu_cache() everything is working as expected.
> 
> Well, that's interesting.  It's likely to only happen on an 860 variant 
> that
> has the large TLB.

For what reasoning? 

> >How can I reproduce it again? Guillaume, what kernel version are you 
> >using?
> 
> It used to happen on early 2.6 versions as soon as you entered user
> space programs.

Will let you know of any findings...

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Mar 22, 2005, at 12:58 PM, Marcelo Tosatti wrote:

> Newbie question: What prevents the initial kernel map (tuple of 8Mbyte 
> I/D-TLB entries)
> and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation 
> pressure,
> in case CONFIG_PIN_TLB is disabled ?

Nothing.  In fact, they are likely invalidated shortly after the kernel
page tables are set up.  This was only done to ensure we could get the
kernel initialized without taking page faults.

> By a counter at the end of _tlbie function, similar to other counters 
> which
> you suggested.

OK.

> Dont think thats the case given that v2.4 calls tlbia through 
> flush_tlb_mm() at exit_mmap()
> only. And at vmalloc_free which shouldnt be called at all.

Hmmm ...  Then, the 2.6 looks to be much less efficient with the MMU
resources than 2.4 was.  This is going to affect everyone, it's just 
easier
to measure on this processor.

> I just noticed this conditional at switch_mm() (v2.6), which _can_ 
> partly
> explain the reduced tlbie's  (its just a guess for now, though):

What is your guess?  I don't know how this would reduce the number
of tlbie instructions, since stealing a context (as part of 
get_context())
will simply whack the whole TLB with a tlbia.  On 8xx, both instructions
could be simply implemented as macros.

> Spent part of the day reading the MMU section of 860 manual, I think I 
> have kind
> of a clue how things are supposed to work at the lowlevel now.

:-)

> PS: I can't reproduce the invalid TLB crash anymore. i.e. even by 
> removing
> the _tlbie() at update_mmu_cache() everything is working as expected.

Well, that's interesting.  It's likely to only happen on an 860 variant 
that
has the large TLB.

> How can I reproduce it again? Guillaume, what kernel version are you 
> using?

It used to happen on early 2.6 versions as soon as you entered user
space programs.


	-- Dan

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Mar 22, 2005, at 8:04 AM, Marcelo Tosatti wrote:

> I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
> less times than v2.4 ?

Oh my ...  I'm more worried about the high number of TLB misses
in 2.6 compared to 2.4.  That's really bad.  How did you instrument
the tlbie measurement?  It could be that 2.4 used lots more 'tlbia'
which were replaced by tlbie in 2.6.

Thanks.


	-- Dan

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Tue, Mar 22, 2005 at 03:57:08PM -0500, Dan Malek wrote:
> 
> On Mar 22, 2005, at 8:04 AM, Marcelo Tosatti wrote:
> 
> >I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
> >less times than v2.4 ?

That was rather a _factor_ of "100-or-so" less.

> Oh my ...  I'm more worried about the high number of TLB misses
> in 2.6 compared to 2.4.  That's really bad.  

Newbie question: What prevents the initial kernel map (tuple of 8Mbyte I/D-TLB entries) 
and the IMMR 8Mbyte D-TLB entry from getting unmapped by translation pressure,
in case CONFIG_PIN_TLB is disabled ? 

> How did you instrument the tlbie measurement? 

By a counter at the end of _tlbie function, similar to other counters which 
you suggested.

> It could be that 2.4 used lots more 'tlbia' which were replaced by tlbie in 2.6.

Dont think thats the case given that v2.4 calls tlbia through flush_tlb_mm() at exit_mmap() 
only. And at vmalloc_free which shouldnt be called at all.

I just noticed this conditional at switch_mm() (v2.6), which _can_ partly 
explain the reduced tlbie's  (its just a guess for now, though):

static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
                             struct task_struct *tsk)
{
#ifdef CONFIG_ALTIVEC
        asm volatile (
 BEGIN_FTR_SECTION
        "dssall;\n"
#ifndef CONFIG_POWER4
         "sync;\n" /* G4 needs a sync here, G5 apparently not */
#endif
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
         : : );
#endif /* CONFIG_ALTIVEC */
                                                                                            
        tsk->thread.pgdir = next->pgd;
                                                                                            
        /* No need to flush userspace segments if the mm doesnt change */
	if (prev == next) 				<--------------
		return;   				<--------------
                                                                                            
        /* Setup new userspace context */
        get_mmu_context(next);
        set_context(next->context, next->pgd);
}

I'm about to disable it and retry.

Spent part of the day reading the MMU section of 860 manual, I think I have kind 
of a clue how things are supposed to work at the lowlevel now. 

I'll continue tracking it down - any help is appreciated.

PS: I can't reproduce the invalid TLB crash anymore. i.e. even by removing
the _tlbie() at update_mmu_cache() everything is working as expected.

How can I reproduce it again? Guillaume, what kernel version are you using?

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Mon, Mar 21, 2005 at 04:45:21PM -0500, Guillaume Autran wrote:
> Hi,
> 
> Was there any progress made about this issue or is it still pending ? 

That one is still pending.

There are other issues in 8xx which are probably related to it, as follows. 

> I'm running 2.6.11 and still see the problem...

I'm currently trying to understand 8xx cache structure and VM semantics to 
find out why I'm seeing the following numbers. 

Test application is: copy 16M from /dev/zero to file-on-RAMDISK, using:
# dd if=/dev/zero of=file bs=4k count=3840 

v2.6:
                                                                      
I-TLB userspace misses: 141264
I-TLB kernel misses: 117455
D-TLB userspace misses: 217590
D-TLB kernel misses: 202677
tlbie: 260
 
I-TLB userspace misses: 143455
I-TLB kernel misses: 119189
D-TLB userspace misses: 212828
D-TLB kernel misses: 197883
tlbie: 260
 
I-TLB userspace misses: 142248
I-TLB kernel misses: 118195
D-TLB userspace misses: 217576
D-TLB kernel misses: 202663
tlbie: 260

v2.4: 
 
I-TLB userspace misses: 266
I-TLB kernel misses: 5170
D-TLB userspace misses: 3661
D-TLB kernel misses: 177004
tlbie: 162599
 
I-TLB userspace misses: 266
I-TLB kernel misses: 3183
D-TLB userspace misses: 2024
D-TLB kernel misses: 180178
tlbie: 165675

I'm quite puzzled. Why v2.6 calls the "tlbie" instruction 100-or-so
less times than v2.4 ?

Paul, Ben? 

> 
> Regards,
> Guillaume.
> 
> 
> 
> Marcelo Tosatti wrote:
> 
> >On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote:
> > 
> >
> >>On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
> >>   
> >>
> >>>On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
> >>>
> >>>     
> >>>
> >>>>Does anyone have a clue of what is/can be wrong with the TLB entry for 
> >>>>the
> >>>>address being flushed at __flush_dcache_icache()?
> >>>>       
> >>>>
> >>>Not sure.  The problem is that the __flush_dcache_icache is passed a
> >>>user space virtual address that doesn't look like it is mapped for 
> >>>writing
> >>>or something.  I don't know, as an ooops isn't sufficient to debug the 
> >>>problem.
> >>>You have to catch it here and track down the current state of the TLB 
> >>>and
> >>>the page tables.  Of course, when I do this everything looks OK, 
> >>>     
> >>>
> >>How do you do track down the current TLB state? With a BDI? 
> >>
> >>   
> >>
> >>>so what I've been trying to do is catch the TLBmiss reload that actually 
> >>>causes this
> >>>to happen to see what it really tried to load into the tlb.
> >>>     
> >>>
> >>Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to 
> >>your
> >>analysis ?? 
> >>   
> >>
> >
> >So this assumption which you have made sometime ago is wrong, given that 
> >now you know TLB entry is not stale ?
> >
> >"The symptom is we appear to have a stale TLB entry,
> >so at least one of the callouts from the generic VM
> >code isn't doing the right thing for us.  I'm still
> >puzzled as to why it doesn't affect other PPC processor." 
> >
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> > 
> >
> 
> -- 
> =======================================
> Guillaume Autran
> Senior Software Engineer
> MRV Communications, Inc.
> Tel: (978) 952-4932 office
> E-mail: gautran@mrv.com
> ======================================= 
> 

Re: Linux 2.6.x on 8xx status

[Robert P. J. Day]

On Mon, 21 Mar 2005, Guillaume Autran wrote:

> Hi,
>
> Was there any progress made about this issue or is it still pending
> ? I'm running 2.6.11 and still see the problem...

when you say "2.6.11", does this mean you're building from a stock
kernel release?  these days, where's the canonical source for
2.6.x-based kernels for embedded ppc?  as i recall, it was bkbits,
linuxppc-2.5, but it's been a while since i've messed around with
that.

rday

Re: Linux 2.6.x on 8xx status

[Guillaume Autran]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hi,

Was there any progress made about this issue or is it still pending ? 
I'm running 2.6.11 and still see the problem...

Regards,
Guillaume.



Marcelo Tosatti wrote:

>On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote:
>  
>
>>On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
>>    
>>
>>>On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
>>>
>>>      
>>>
>>>>Does anyone have a clue of what is/can be wrong with the TLB entry for 
>>>>the
>>>>address being flushed at __flush_dcache_icache()?
>>>>        
>>>>
>>>Not sure.  The problem is that the __flush_dcache_icache is passed a
>>>user space virtual address that doesn't look like it is mapped for 
>>>writing
>>>or something.  I don't know, as an ooops isn't sufficient to debug the 
>>>problem.
>>>You have to catch it here and track down the current state of the TLB 
>>>and
>>>the page tables.  Of course, when I do this everything looks OK, 
>>>      
>>>
>>How do you do track down the current TLB state? With a BDI? 
>>
>>    
>>
>>>so what I've been trying to do is catch the TLBmiss reload that actually causes 
>>>this
>>>to happen to see what it really tried to load into the tlb.
>>>      
>>>
>>Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to your
>>analysis ?? 
>>    
>>
>
>So this assumption which you have made sometime ago is wrong, given that now you 
>know TLB entry is not stale ?
>
>"The symptom is we appear to have a stale TLB entry,
>so at least one of the callouts from the generic VM
>code isn't doing the right thing for us.  I'm still
>puzzled as to why it doesn't affect other PPC processor." 
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>  
>

-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
======================================= 


[-- Attachment #2: Type: text/html, Size: 2953 bytes --]

Linux 2.6.x on 8xx status

[Joakim Tjernlund]

dcbz(and a few other cache instr.) is buggy on 8xx CPU:s.
See http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/000867.html
for a litte more input or google.

This bug will cuase random craches or "hangs" if not used with care.
There is an old patch floating around for 2.4 that will workaround the bug by
doing instr. decoding in the TLB Error handler.

 Jocke

Re: Linux 2.6.x on 8xx status

[Guillaume Autran]

Armin Schindler wrote:

> Hi Dan,
>
> On Thu, 10 Feb 2005, Dan Malek wrote:
>
>>
>> On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
>>
>>> Does anyone have a clue of what is/can be wrong with the TLB entry 
>>> for the
>>> address being flushed at __flush_dcache_icache()?
>>
>>
>> Not sure. The problem is that the __flush_dcache_icache is passed a
>> user space virtual address that doesn't look like it is mapped for 
>> writing
>> or something. I don't know, as an ooops isn't sufficient to debug the 
>> problem.
>> You have to catch it here and track down the current state of the TLB 
>> and
>> the page tables. Of course, when I do this everything looks OK, so what
>> I've been trying to do is catch the TLBmiss reload that actually 
>> causes this
>> to happen to see what it really tried to load into the tlb. A much more
>> challenging project :-) I'll get it one of these days .....
>
>
> any news on that issue?
>
> I just started with an MPC855/859 and run into the same problem with 
> 2.6.9.
>
> Is there anything I can do or test?
> Right now I'm not sure where to begin.
>
> Even BDI-debugging would be possible...
>
> Thanks,
> Armin
>
> ---
> Armin Schindler SYSGO AG
> Am Pfaffenstein 14
> D-55270 Klein-Winternheim / Germany
> Phone: +49 6136 9948-0
> Fax : +49 6136 9948-10
> armin.schindler@sysgo.com
> www.sysgo.com
> www.elinos.com
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
Hi all,

I am experiencing the same issue with 2.6.11-rc2 (see oops below).
And I also notice something else that may or may not be related. I see 
that doing a DCBZ instruction on an invalid address "hangs" the process 
doing it. My expectation was to get a crash/core instead of hanging 
forever...

The code used is extremely simple (may be too simple ?):

int main( int argc, char **argv ) {
int *where = NULL;
int index = 0;
asm volatile ("dcbz %0,%1" : : "r"(index), "r"(where) );
return 1;
}

Also, the instruction left in the NIP by the Oops is:
0xc0004758 <__flush_dcache_icache+20>: dcbst r0,r3

Yet another dcbX instruction...

Does anyone know where do we go from here ??

Guillaume.


Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C0004758 LR: C0009804 SP: C7C4BE10 REGS: c7c4bd60 TRAP: 0300 Not 
tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 3000A038, DSISR: C2000000
TASK = c7c76ae0[24] 'ldconfig' THREAD: c7c4a000
Last syscall: 90
GPR00: C01C38C0 C7C4BE10 C7C76AE0 3000A000 00000100 00007FCB 3000A000 
C03FC028
GPR08: C03FE300 C01C38C0 00000000 000FF960 00000000 10099C8C 000000D8 
00000000
GPR16: 0000A038 3000A7F4 1009386B 00000007 7FFFFAD8 00000000 C03FE300 
00000000
GPR24: 00000000 C67732B0 C01C38C0 3000A038 C03FC028 C01C08B0 07FCB889 
C02FE960
NIP [c0004758] __flush_dcache_icache+0x14/0x40
LR [c0009804] update_mmu_cache+0x64/0x98
Call trace:
[c003aba0] do_no_page+0x4b8/0x54c
[c003ad28] handle_mm_fault+0xf4/0x2b4
[c0008de4] do_page_fault+0x208/0x424
[c0002ae8] handle_page_fault+0xc/0x80
.........

-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
======================================= 

Re: Linux 2.6.x on 8xx status

[Armin Schindler]

Hi Dan,

On Thu, 10 Feb 2005, Dan Malek wrote:
>
> On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
>
>> Does anyone have a clue of what is/can be wrong with the TLB entry for the
>> address being flushed at __flush_dcache_icache()?
>
> Not sure.  The problem is that the __flush_dcache_icache is passed a
> user space virtual address that doesn't look like it is mapped for writing
> or something.  I don't know, as an ooops isn't sufficient to debug the 
> problem.
> You have to catch it here and track down the current state of the TLB and
> the page tables.  Of course, when I do this everything looks OK, so what
> I've been trying to do is catch the TLBmiss reload that actually causes this
> to happen to see what it really tried to load into the tlb.  A much more
> challenging project :-)  I'll get it one of these days .....

any news on that issue?

I just started with an MPC855/859 and run into the same problem with 
2.6.9.

Is there anything I can do or test?
Right now I'm not sure where to begin.

Even BDI-debugging would be possible...

Thanks,
Armin

---
Armin Schindler 
SYSGO AG
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany
Phone: +49 6136 9948-0
Fax  : +49 6136 9948-10
armin.schindler@sysgo.com
www.sysgo.com
www.elinos.com

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Feb 10, 2005, at 12:06 PM, Marcelo Tosatti wrote:

> How do you do track down the current TLB state? With a BDI?

Yes.  The BDI2000 is invaluable for this kind of debugging.

> Shouldnt it be loading the TLB entry which "seem to be OK" accordingly 
> to your
> analysis ??

Yes.

> BTW, we are seeing very bad slowdown on v2.4 compared to v2.6 on m8xx.

What are you using for performance measurements?  Standard
benchmarks I could run, too?

> Its likely to be cache related - I'm preparing a detailed email about 
> it.

OK.  Thanks.


	-- Dan

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:

> Does anyone have a clue of what is/can be wrong with the TLB entry for 
> the
> address being flushed at __flush_dcache_icache()?

Not sure.  The problem is that the __flush_dcache_icache is passed a
user space virtual address that doesn't look like it is mapped for 
writing
or something.  I don't know, as an ooops isn't sufficient to debug the 
problem.
You have to catch it here and track down the current state of the TLB 
and
the page tables.  Of course, when I do this everything looks OK, so what
I've been trying to do is catch the TLBmiss reload that actually causes 
this
to happen to see what it really tried to load into the tlb.  A much more
challenging project :-)  I'll get it one of these days .....


	-- Dan

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote:
> On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
> > 
> > On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
> > 
> > >Does anyone have a clue of what is/can be wrong with the TLB entry for 
> > >the
> > >address being flushed at __flush_dcache_icache()?
> > 
> > Not sure.  The problem is that the __flush_dcache_icache is passed a
> > user space virtual address that doesn't look like it is mapped for 
> > writing
> > or something.  I don't know, as an ooops isn't sufficient to debug the 
> > problem.
> > You have to catch it here and track down the current state of the TLB 
> > and
> > the page tables.  Of course, when I do this everything looks OK, 
> 
> How do you do track down the current TLB state? With a BDI? 
> 
> > so what I've been trying to do is catch the TLBmiss reload that actually causes 
> > this
> > to happen to see what it really tried to load into the tlb.
> 
> Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to your
> analysis ?? 

So this assumption which you have made sometime ago is wrong, given that now you 
know TLB entry is not stale ?

"The symptom is we appear to have a stale TLB entry,
so at least one of the callouts from the generic VM
code isn't doing the right thing for us.  I'm still
puzzled as to why it doesn't affect other PPC processor." 

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
> 
> On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:
> 
> >Does anyone have a clue of what is/can be wrong with the TLB entry for 
> >the
> >address being flushed at __flush_dcache_icache()?
> 
> Not sure.  The problem is that the __flush_dcache_icache is passed a
> user space virtual address that doesn't look like it is mapped for 
> writing
> or something.  I don't know, as an ooops isn't sufficient to debug the 
> problem.
> You have to catch it here and track down the current state of the TLB 
> and
> the page tables.  Of course, when I do this everything looks OK, 

How do you do track down the current TLB state? With a BDI? 

> so what I've been trying to do is catch the TLBmiss reload that actually causes 
> this
> to happen to see what it really tried to load into the tlb.

Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to your
analysis ?? 

> A much more
> challenging project :-)  I'll get it one of these days .....

I see... thanks for your help. 

BTW, we are seeing very bad slowdown on v2.4 compared to v2.6 on m8xx. 

Its likely to be cache related - I'm preparing a detailed email about it.

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Tue, Sep 21, 2004 at 01:03:29PM -0400, Dan Malek wrote:
> 
> On Sep 21, 2004, at 7:59 AM, Smith, Craig wrote:
> 
> >Genius. That patch appears to work for me as well.
> 
> The fact this works indicates a subtle memory management
> problem elsewhere.  I don't know what that is at this
> point.  This hack is in a piece of generic code that works
> properly on all other PowerPC cores, so it isn't going to
> ever appear in the public sources.
> 
> I suggested this change to a few people hoping the information
> would lead them to finding the real problem, not that it
> should be perpetuated as a "fix" to make 8xx work.
> I don't personally have time to work on this right now,
> so anyone using 8xx should be looking for the real
> cause and solution, not using this to create products.

Hi Dan,

Does anyone have a clue of what is/can be wrong with the TLB entry for the 
address being flushed at __flush_dcache_icache()? 

Can we assume such TLB entry is corrupted in some way? 


This is v2.6.10 on m8xx - with the TLB invalidate everything works as
expected.

Oops: kernel access of bad area, sig: 11 [#1]
NIP: C00049F8 LR: C000A3E0 SP: C48D1E10 REGS: c48d1d60 TRAP: 0300    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 100113A0, DSISR: C2000000
TASK = c4e1eba0[1230] 'netserver' THREAD: c48d0000
Last syscall: 20
GPR00: C4ED7D60 C48D1E10 C4E1EBA0 10011000 00000100 000954A0 10011000 C01C8090
GPR08: C02E64B8 C4ED7D60 00009032 00000000 00020591 100B46A8 00000000 100CA328
GPR16: 100CA1E8 2FEED1FF F657FFF4 00000000 00000000 00000000 C48D1E28 00000000
GPR24: C1148100 00000000 C1147EA4 C4ED7D60 100113A0 C1229418 04AA5889 C02E64A0
NIP [c00049f8] __flush_dcache_icache+0x14/0x40
LR [c000a3e0] update_mmu_cache+0x64/0x98
Call trace:
 [c003f3a4] do_no_page+0x2ec/0x364
 [c003f588] handle_mm_fault+0xa4/0x17c
 [c0009968] do_page_fault+0x168/0x394
 [c0002c68] handle_page_fault+0xc/0x80

Re: Linux 2.6.x on 8xx status

[Sam Song]

Sam Song <samlinuxppc@yahoo.com.cn> wrote：
> BTW, out of curiousness, I just pulled from
> linux-2.4 and compiled 2.4.28-pre4 on 8xx but end 
> with some making errors as follows. Did you 
> encounter it? Some guys like me are more interested
> in 2.4.x on 8xx.

Oh, I feel so sorry to all of you for the former
misleading message I did on Sat, 16 Oct. It turned out
to be the kernel configuration problem. Now I can
compile a right 2.4.28-rc1 on RPXlite DW.

I should thank John Whittington for his hints.

Sorry for bothering you all.

=====
Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Sam Song]

Pantelis Antoniou <panto@intracom.gr> 的正文：
> I'm not dead, just very busy!

Fine, Good thing for busy! 
 
> Promise I'll start looking into it again this week.

If need, I would like to do some test for you. :-)

=====
Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Sam Song wrote:

>Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote：
>
>>I know Pantelis seems to have necessary knowledge to
>>it. Pantelis?
>>
>
>On 8xx porting, Tom, Pantelis, Dan, Ben and Kumar all
>involved a lot. Ten days more no see Pantelis online
>both on ppc list and u-boot list. Perhaps on vacation?
>
>BTW, out of curiousness, I just pulled from linux-2.4
>and compiled 2.4.28-pre4 on 8xx but end with some
>making errors as follows. Did you encounter it? Some
>guys like me are more interested in 2.4.x on 8xx. Any
>plan to make linuxppc_2_4_devel alive?
>
>Thanks a lot!
>

I'm not dead, just very busy!

Promise I'll start looking into it again this week.

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Oct 15, 2004, at 11:49 AM, Marcelo Tosatti wrote:

> Do you know the real cause Dan ?

The symptom is we appear to have a stale TLB entry,
so at least one of the callouts from the generic VM
code isn't doing the right thing for us.  I'm still
puzzled as to why it doesn't affect other PPC processor.

> As I told you, we are porting our sub-sub-architecture
> to v2.6, and need that bug fixed at some time.

I don't have any incentive to work on 8xx for 2.6 right
now.  When I have a little free time I try to work on it,
but I have other things placing demands on my
time right now.

Thanks.


	-- Dan

Re: Linux 2.6.x on 8xx status

[Sam Song]

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote：
> I know Pantelis seems to have necessary knowledge to
> it. Pantelis?

On 8xx porting, Tom, Pantelis, Dan, Ben and Kumar all
involved a lot. Ten days more no see Pantelis online
both on ppc list and u-boot list. Perhaps on vacation?

BTW, out of curiousness, I just pulled from linux-2.4
and compiled 2.4.28-pre4 on 8xx but end with some
making errors as follows. Did you encounter it? Some
guys like me are more interested in 2.4.x on 8xx. Any
plan to make linuxppc_2_4_devel alive?

Thanks a lot!
......
       net/network.o \
        /bk/linux-2.4/lib/lib.a \
        --end-group \
        -o vmlinux
drivers/net/net.o: In function `mace_probe':
drivers/net/net.o(.text.init+0x18): undefined
reference to `find_devices'
drivers/net/net.o(.text.init+0x18): relocation
truncated to fit: R_PPC_REL24 find_devices
drivers/net/net.o: In function `mace_probe1':
drivers/net/net.o(.text.init+0xdc): undefined
reference to `get_property'
drivers/net/net.o(.text.init+0xdc): relocation
truncated to fit: R_PPC_REL24 get_property
drivers/net/net.o(.text.init+0x144): undefined
reference to `request_OF_resource'
drivers/net/net.o(.text.init+0x144): relocation
truncated to fit: R_PPC_REL24 request_OF_resource
drivers/net/net.o(.text.init+0x180): undefined
reference to `release_OF_resource'
drivers/net/net.o(.text.init+0x180): relocation
truncated to fit: R_PPC_REL24 release_OF_resource
drivers/net/net.o(.text.init+0x18c): undefined
reference to `release_OF_resource'
drivers/net/net.o(.text.init+0x18c): relocation
truncated to fit: R_PPC_REL24 release_OF_resource
drivers/net/net.o(.text.init+0x198): undefined
reference to `release_OF_resource'
drivers/net/net.o(.text.init+0x198): relocation
truncated to fit: R_PPC_REL24 release_OF_resource
drivers/net/net.o(.text.init+0x1b0): undefined
reference to `request_OF_resource'
drivers/net/net.o(.text.init+0x1b0): relocation
truncated to fit: R_PPC_REL24 request_OF_resource
drivers/net/net.o(.text.init+0x1d4): undefined
reference to `request_OF_resource'
drivers/net/net.o(.text.init+0x1d4): relocation
truncated to fit: R_PPC_REL24 request_OF_resource
drivers/net/net.o(.text.init+0x4d4): undefined
reference to `machine_is_compatible'
drivers/net/net.o(.text.init+0x4d4): relocation
truncated to fit: R_PPC_REL24 machine_is_compatible
drivers/net/net.o(.text.init+0x520): undefined
reference to `get_property'
drivers/net/net.o(.text.init+0x520): relocation
truncated to fit: R_PPC_REL24 get_property
drivers/net/net.o: In function `mace_cleanup':
drivers/net/net.o(.text.exit+0x68): undefined
reference to `release_OF_resource'
drivers/net/net.o(.text.exit+0x68): relocation
truncated to fit: R_PPC_REL24 release_OF_resource
drivers/net/net.o(.text.exit+0x74): undefined
reference to `release_OF_resource'
drivers/net/net.o(.text.exit+0x74): relocation
truncated to fit: R_PPC_REL24 release_OF_resource
drivers/net/net.o(.text.exit+0x80): undefined
reference to `release_OF_resource'
drivers/net/net.o(.text.exit+0x80): relocation
truncated to fit: R_PPC_REL24 release_OF_resource
make: *** [vmlinux] Error 1
[root@shu linux-2.4]#

=====
Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Fri, Oct 15, 2004 at 12:49:46PM -0300, Marcelo Tosatti wrote:
> On Tue, Sep 21, 2004 at 01:03:29PM -0400, Dan Malek wrote:
> > 
> > On Sep 21, 2004, at 7:59 AM, Smith, Craig wrote:
> > 
> > >Genius. That patch appears to work for me as well.
> > 
> > The fact this works indicates a subtle memory management
> > problem elsewhere.  I don't know what that is at this
> > point.  This hack is in a piece of generic code that works
> > properly on all other PowerPC cores, so it isn't going to
> > ever appear in the public sources.
> > 
> > I suggested this change to a few people hoping the information
> > would lead them to finding the real problem, not that it
> > should be perpetuated as a "fix" to make 8xx work.
> > I don't personally have time to work on this right now,
> > so anyone using 8xx should be looking for the real
> > cause and solution, not using this to create products.
> 
> Do you know the real cause Dan ?
> 
> As I told you, we are porting our sub-sub-architecture 
> to v2.6, and need that bug fixed at some time.
> 
> Lots of other people do.

I can try to fix it if you dont have time, do you know what is 
wrong and requires fixing? I'm not familiar with low-level PowerPC
memory management, but I can try.

Can you help, or are you planning on fixing this yourself (who
was the necessary knowledge, as soon as time allows) ?

I know Pantelis seems to have necessary knowledge to it. Pantelis?

Re: Linux 2.6.x on 8xx status

[Marcelo Tosatti]

On Tue, Sep 21, 2004 at 01:03:29PM -0400, Dan Malek wrote:
> 
> On Sep 21, 2004, at 7:59 AM, Smith, Craig wrote:
> 
> >Genius. That patch appears to work for me as well.
> 
> The fact this works indicates a subtle memory management
> problem elsewhere.  I don't know what that is at this
> point.  This hack is in a piece of generic code that works
> properly on all other PowerPC cores, so it isn't going to
> ever appear in the public sources.
> 
> I suggested this change to a few people hoping the information
> would lead them to finding the real problem, not that it
> should be perpetuated as a "fix" to make 8xx work.
> I don't personally have time to work on this right now,
> so anyone using 8xx should be looking for the real
> cause and solution, not using this to create products.

Do you know the real cause Dan ?

As I told you, we are porting our sub-sub-architecture 
to v2.6, and need that bug fixed at some time.

Lots of other people do.

Re: Linux 2.6.x on 8xx status

[Sam Song]

Dan Malek <dan@embeddededge.com> wrote：
> I suggested this change to a few people hoping the
> information would lead them to finding the real 
> problem, not that it should be perpetuated as 
> a "fix" to make 8xx work. I don't personally have 
> time to work on this right now,
> so anyone using 8xx should be looking for the real
> cause and solution, not using this to create
> products.

Thanks for this clarification. We were just having a
beta test on it. I also noticed that there were some
disorder characters in NFS init process. Not smooth as
2.4.x did. But it was a big advance to the real
problem, especially BDI2000 firware cannot function
well for 2.6.x debug ATM. If possible, I wanna to try
JFFS2 on it to see how faster JFFS2 of 2.6 in boot
time, which David Woodhouse suggested. All
experimental.

Thanks again,

Sam

=====
Best regards,

Sam

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Sep 21, 2004, at 7:59 AM, Smith, Craig wrote:

> Genius. That patch appears to work for me as well.

The fact this works indicates a subtle memory management
problem elsewhere.  I don't know what that is at this
point.  This hack is in a piece of generic code that works
properly on all other PowerPC cores, so it isn't going to
ever appear in the public sources.

I suggested this change to a few people hoping the information
would lead them to finding the real problem, not that it
should be perpetuated as a "fix" to make 8xx work.
I don't personally have time to work on this right now,
so anyone using 8xx should be looking for the real
cause and solution, not using this to create products.

Thanks.


	-- Dan

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Sep 21, 2004, at 7:53 AM, Pantelis Antoniou wrote:

> BDI2000 does not work for 8xx 2.6 ATM.
>
> Dan should probably get it to work when he has time.
> At least that's what I hope...

The page table format has changed between 2.4 and 2.6.
I'm working on a solution, first to avoid any BDI firmware
changes.  If I can't do that, I'll send the info to Abatron and
ask them for an update.

Thanks.

	-- Dan

RE: Linux 2.6.x on 8xx status

[Smith, Craig]

> Guess what? It WORKED!!! Just one more line make it.
> Could you pls tell us the theory in it if not too
> complicated? :-)
Genius. That patch appears to work for me as well.

However, I'm still not able to debug via gdb/BDI2000.
I'm getting the ol' "MMU: address translation for 0xc----- failed".
I'm using the same BDI config file that works fine for debugging
a 2.4.26 kernel on the same hardware, I've verified that I have
CONFIG_BDI_SWITCH=y etc. Is this another known issue with 2.6
on 8xx platforms? Has anyone had success debugging via BDI2000 on an 8xx
board?
If so, could you share your config file or hints as to why it should behave
differently (i.e. not work) with a 2.6 kernel? Thanks.

Regards,
-Craig

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Smith, Craig wrote:

>>Guess what? It WORKED!!! Just one more line make it.
>>Could you pls tell us the theory in it if not too
>>complicated? :-)
>>
>Genius. That patch appears to work for me as well.
>
>However, I'm still not able to debug via gdb/BDI2000.
>I'm getting the ol' "MMU: address translation for 0xc----- failed".
>I'm using the same BDI config file that works fine for debugging
>a 2.4.26 kernel on the same hardware, I've verified that I have
>CONFIG_BDI_SWITCH=y etc. Is this another known issue with 2.6
>on 8xx platforms? Has anyone had success debugging via BDI2000 on an 8xx
>board?
>If so, could you share your config file or hints as to why it should behave
>differently (i.e. not work) with a 2.6 kernel? Thanks.
>
>Regards,
>-Craig
>
>
>
BDI2000 does not work for 8xx 2.6 ATM.

Dan should probably get it to work when he has time.
At least that's what I hope...

Regards

Pantelis

RE: Linux 2.6.x on 8xx status

[Smith, Craig]

>> I seem to be able ro run it OK on 8xx with an extra patch
>> that most people (including Dan :) ) find gross.
I don't mind gross patches....could you point me to this patch?

>> Use the new ethernet & serial drivers (fec_8xx & cpm_uart),
>> and try again.
Ah ha...I didn't even notice that since it wasn't showing up
in my menuconfig (depends on NETTA). Thanks I'll try it.

Regards,
-Craig

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Smith, Craig wrote:
>>>I seem to be able ro run it OK on 8xx with an extra patch
>>>that most people (including Dan :) ) find gross.
> 
> I don't mind gross patches....could you point me to this patch?
> 
> 

It's not online. We are just trying to find an acceptable solution
for the proper fix.

Please be patient a bit.

>>>Use the new ethernet & serial drivers (fec_8xx & cpm_uart),
>>>and try again.
> 
> Ah ha...I didn't even notice that since it wasn't showing up
> in my menuconfig (depends on NETTA). Thanks I'll try it.
> 

Still work in progress.

> Regards,
> -Craig
> 
> 
> 

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Pantelis Antoniou]

Dan Malek wrote:
> 
> On Sep 16, 2004, at 2:56 PM, Smith, Craig wrote:
> 
>> Can someone please tell me the current "status" of the
>> 2.6.9-rc2 kernel source
> 
> 
> It's not working for 8xx.  There are some subtle VM problems
> that I just have not had the time to track down.  A couple
> of us work on it as our time permits.  The 2.6 kernel
> works OK for 82xx and 85xx processors.  Some particular
> board ports may be missing, but the processor support
> is there along with a few board ports.
> 
>     -- Dan
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 

I seem to be able ro run it OK on 8xx with an extra patch
that most people (including Dan :) ) find gross.

The biggest stumbling block are the peripheral drivers.

Use the new ethernet & serial drivers (fec_8xx & cpm_uart),
and try again.

Regards

Pantelis

Re: Linux 2.6.x on 8xx status

[Dan Malek]

On Sep 16, 2004, at 2:56 PM, Smith, Craig wrote:

> Can someone please tell me the current "status" of the
> 2.6.9-rc2 kernel source

It's not working for 8xx.  There are some subtle VM problems
that I just have not had the time to track down.  A couple
of us work on it as our time permits.  The 2.6 kernel
works OK for 82xx and 85xx processors.  Some particular
board ports may be missing, but the processor support
is there along with a few board ports.

	-- Dan

Linux 2.6.x on 8xx status

[Smith, Craig]

Hello,
Can someone please tell me the current "status" of the
2.6.9-rc2 kernel source (a bitkeeper clone of linuxppc-2.5)?
I can compile and run it (with a minor modification to fec.c),
but I see random "Oops: kernel access of bad area" messages
when init runs, or other busybox tools run. Sometimes I boot
up (same file system etc.) and I see no errors. I can provide
more details if anyone's interested.

Right now, I just want to know if I should expect to see funny
behavior from this particular source tree on an 8xx platform or
should it work OK? Thanks so much.

Regards,
-Craig