EST SBC8260 Linux memory mapping rules

EST SBC8260 Linux memory mapping rules

[diekema_jon]

I have attempted to capture the Linux memory mapping rules, and how
they apply to the EST SBC8260 board.  I would appreciate any
comments on how this can be improved.

After the comments have been rolled in, I would like to publish this
as Documentation/powerpc/SBC8260_memory_mapping.txt in the Linux
kernel source tree.


	* EST SBC8260 Linux memory mapping rules

	Initial conditions:
	-------------------

	Tasks that need to be perform by the boot ROM before control is
	transferred to zImage (compressed Linux kernel):

	- Define the IMMR to 0xf0000000

	- Initialize the memory controller so that RAM is available at
	  physical address 0x00000000.  On the SBC8260 is this 16M (64M)
	  SDRAM.

	- Build the board information structure (see
	  include/asm-ppc/est8260.h for its definition)

	- The compressed Linux kernel (zImage) contains a bootstrap loader
	  that is position independent; you can load it into any RAM,
	  ROM or FLASH memory address >= 0x00200000 (above 2 MB).

	  Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
	        then zImage will skip the step of moving itself to
		its link address.

	- Load R3 with the address of the board information structure

	- Transfer control to zImage

	- The Linux console port is SMC1, and the baud rate is controlled
	  from the bi_baudrate field of the board information structure.
	  On thing to keep in mind when picking the baud rate, is that
	  there is no flow control on the SMC ports.  I would stick
	  with something safe and standard like 19200.

	  On the EST SBC8260, the SMC1 port is on the COM1 connector of
	  the board.


	EST SBC8260 defaults:
	---------------------

	0x00000000-0x00FFFFFF   16M (64M) SDRAM
	0xFE000000-0xFFFFFFFF    4M flash (SIMM)
	0xFC000000-0xFCFFFFFF    2M flash (8 bits wide, soldered to the board)
	0x22000000-0x2200FFFF    8K EEPROM
	0x04000000-0x04FFFFFF    4M local bus SDRAM (soldered to the board)
	0x21000000-0x21000000   Flash present detect (from the flash SIMM)
	0x21000001-0x21000001   Switches (read) and LEDs (write)


	Notes:
	------

	- The chip selects can map 32K blocks and up (powers of 2)

	- The SDRAM machine can handled up to 128Mbytes per chip select

	- Linux uses the 60x bus memory (the SDRAM DIMM) for the
	  communications buffers.

	- BATs can map 128K-256Mbytes each.  There are four data BATs and
	  four instruction BATs.  Generally the data and instruction BATs
	  are mapped the same.

	- The IMMR must be set above the kernel virtual memory addresses,
	  which start at 0xC0000000.  Otherwise, the kernel may crash as
	  soon as you start any threads or processes due to VM collisions
	  in the kernel or user process space.


	  Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:

	  The user application virtual space consumes the first 2 Gbytes
	  (0x00000000 to 0x7FFFFFFF).  The kernel virtual text starts at
	  0xC0000000, with data following.  There is a "protection hole"
	  between the end of kernel data and the start of the kernel
	  dynamically allocated space, but this space is still within
	  0xCxxxxxxx.

	  Obviously the kernel can't map any physical addresses 1:1 in
	  these ranges.


	  Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:

	  During the early kernel initialization, the kernel virtual
	  memory allocator is not operational.  Prior to this KVM
	  initialization, we choose to map virtual to physical addresses
	  1:1.  That is, the kernel virtual address exactly matches the
	  physical address on the bus.  These mappings are typically done
	  in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only
	  absolutely necessary mappings should be done at this time, for
	  example board control registers or a serial uart.  Normal device
	  driver initialization should map resources later when necessary.

	  Although platform dependent, and certainly the case for embedded
	  8xx, traditionally memory is mapped at physical address zero,
	  and I/O devices above phsical address 0x80000000.  The lowest
	  and highest (above 0xf0000000) I/O addresses are traditionally
	  used for devices or registers we need to map during kernel
	  initialization and prior to KVM operation.  For this reason,
	  and since it followed prior PowerPC platform examples, I chose
	  to map the embedded 8xx kernel to the 0xc0000000 virtual address.
	  This way, we can enable the MMU to map the kernel for proper
	  operation, and still map a few windows before the KVM is operational.

	  On some systems, you could possibly run the kernel at the
	  0x80000000 or any other virtual address.  It just depends upon
	  mapping that must be done prior to KVM operational.  You can never
	  map devices or kernel spaces that overlap with the user virtual
	  space.  This is why default IMMR mapping used by most BDM tools
	  won't work.  They put the IMMR at something like 0x10000000 or
	  0x02000000 for example.  You simply can't map these addresses early
	  in the kernel, and continue proper system operation.

	  The embedded 8xx/82xx kernel is mature enough that all you should
	  need to do is map the IMMR someplace at or above 0xf0000000 and it
	  should boot far enough to get serial console messages and KGDB
	  connected on any platform.  There are lots of other subtle memory
	  management design features that you simply don't need to worry
	  about.  If you are changing functions related to MMU initialization,
	  you are likely breaking things that are known to work and are
	  heading down a path of disaster and frustration.  Your changes
	  should be to make the flexibility of the processor fit Linux,
	  not force arbitrary and non-workable memory mappings into Linux.

	- You don't want to change KERNELLOAD or KERNELBASE, otherwise the
	  virtual memory and MMU code will get confused.

	  arch/ppc/Makefile:KERNELLOAD = 0xc0000000

	  include/asm-ppc/page.h:#define PAGE_OFFSET    0xc0000000
	  include/asm-ppc/page.h:#define KERNELBASE     PAGE_OFFSET

	- RAM is at physical address 0x00000000, and gets mapped to
	  virtual address 0xC0000000 for the kernel.


	Physical addresses used by the Linux kernel:
	--------------------------------------------

	0x00000000-0x3FFFFFFF   1GB reserved for RAM
	0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
                                 64K for 8260 registers


        Logical addresses used by the Linux kernel:
	-------------------------------------------

	0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
	0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
	0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
	0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)


	EST SBC8260 Linux mapping:
	--------------------------

	DBAT0, IBAT0, cache inhibited:

                                Chip
        Memory                  Sel Use
        ---------------------   --- ---------------------------------
        0xF0000000-0xF001FFFF   n/a IMMR: dual port RAM, registers

        DBAT1, IBAT1, cache inhibited:


------------------\\----------------------\\----------------------------
Jon Diekema        |                       | Smiths Industries
(616) 241-8310     |                       | 3290 Patterson Avenue, SE
diekema_jon@si.com \\                      \\  Grand Rapids, MI 49512-1991

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: EST SBC8260 Linux memory mapping rules

[Dan Malek]

diekema_jon wrote:

>         - The compressed Linux kernel (zImage) contains a bootstrap loader
>           that is position independent; you can load it into any RAM,
>           ROM or FLASH memory address >= 0x00200000 (above 2 MB).
>
>           Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
>                 then zImage will skip the step of moving itself to
>                 its link address.

The zImage should be loaded above the link address by at least the
amount of memory required by the uncompress/setup functions.  If you
load it below the address, it could potentially relocate itself on
top of the kernel or ram disk image.  For example, the uncompress/setup
functions are linked to run at 0x00400000, based upon the current size
of the functions, you need to load above 0x00407000.  I would pick
0x00480000 or higher, just to not worry about it.


>           and I/O devices above phsical address 0x80000000.  The lowest

You could fix this typo....it should be 'physical'.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: EST SBC8260 Linux memory mapping rules

[diekema_jon]

>From Dan Malek:

> The zImage should be loaded above the link address by at least the
> amount of memory required by the uncompress/setup functions.  If you
> load it below the address, it could potentially relocate itself on
> top of the kernel or ram disk image.  For example, the uncompress/setup
> functions are linked to run at 0x00400000, based upon the current size
> of the functions, you need to load above 0x00407000.  I would pick
> 0x00480000 or higher, just to not worry about it.

I have loaded the zImage bits at the link address on the SBC8260,
and that works just fine.

On the TQM 860T board, I have sucessfully loaded and booted Linux 2.2.13
from a Srecord version of zImage with the ELF header (first 64k)
stripped out at 0x00200000 (2 MB).

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: EST SBC8260 Linux memory mapping rules

[Dan Malek]

diekema_jon wrote:

> I have loaded the zImage bits at the link address on the SBC8260,
> and that works just fine.

Well, you must have some pretty damn magical tools, because that
certainly will not work based upon the way the code is written.
What do consider the "link address" and "works"?


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Wait Queue bug triggered on EST SBC8260

[diekema_jon]

>From Dan Malek:
May 20, 00 12:47:56 AM -0400
Re: EST SBC8260 Linux memory mapping rules

> diekema_jon wrote:

> > I have loaded the zImage bits at the link address on the SBC8260,
> > and that works just fine.

> Well, you must have some pretty damn magical tools, because that
> certainly will not work based upon the way the code is written.
> What do consider the "link address" and "works"?


The works definition would be able to run /bin/sash.


zvmlinux is being linked at 0x00400000, and its entry point
is also at this same address.

dell 121} powerpc-linux-nm arch/ppc/mbxboot/zvmlinux | grep ' start$'
00400000 T start

dell 108} powerpc-linux-objdump -h arch/ppc/mbxboot/zvmlinux
arch/ppc/mbxboot/zvmlinux:     file format elf32-powerpc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000044d4  00400000  00400000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000470  004044e0  004044e0  000144e0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         0000030c  00405000  00405000  00015000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .data.init    00000000  00406000  00406000  0008ce71  2**0
                  CONTENTS
  4 .bss          00005270  00406000  00406000  00016000  2**2
                  ALLOC
  5 .gzimage      00071c01  0040b270  0040b270  0001b270  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

We are using the vxWorks boot rom on the EST SBC8260 board, and it
understandsa ELF files.  This boot rom is loading zvmlinux at the
address is was linked at.  Here is an example:


                            VxWorks System Boot

Copyright 1984-1998  Wind River Systems, Inc.

CPU: EST Corp. est8260 -- MPC8260 PowerQUICC II SBC
Version: 5.4
BSP version: 1.2/3
Creation date: Apr 19 2000, 10:24:59

Press any key to stop auto-boot...

Attached TCP/IP interface to motfcc0.
Subnet Mask: 0xff000000
Attaching network interface lo0... done.
Loading... 45680 + 465921
Starting at 0x400000...

loaded at:     00400000 0040B270
board data at: 00FFFFC0 00FFFFE4
relocated to:  00200100 00200124
zimage at:     0040B270 0047CE71
avail ram:     0047D000 01000000

Linux/PPC load: root=/dev/nfs rw nfsroot=126.28.1.117:/target nfsaddrs=126.1.4.5:126.28.1.117::255.0.0.0
Uncompressing Linux...done.
Now booting the kernel
Total memory = 16MB; using 0kB for hash table (at 00000000)
Linux version 2.3.99-pre9 (diekema@dell) (gcc version 2.95.2 19991024 (release)) #45 Sat May 20 21:08:00 EDT 2000
Boot arguments:  root=/dev/nfs rw nfsroot=126.28.1.117:/target nfsaddrs=126.1.4.5:126.28.1.117::255.0.0.0
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Calibrating delay loop... 164.66 BogoMIPS
Memory: 14736k available (860k kernel code, 416k data, 48k init) [c0000000,c1000000]
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
kmem_create: Poisoning requested, but con given - bdev_cache
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
kmem_create: Poisoning requested, but con given - inode_cache
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
kmem_create: Poisoning requested, but con given - skbuff_head_cache
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Starting kswapd v1.6
CPM UART driver version 0.01
ttyS00 at 0x0000 is a SMC
ttyS01 at 0x0040 is a SMC
ttyS02 at 0x8100 is a SCC
ttyS03 at 0x8200 is a SCC
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: registered device at major 7
loop: enabling 8 loop devices
eth0: SCC ENET Version 0.1, 00:a0:1e:01:04:05
kmem_create: Forcing size word alignment - nfs_fh
Looking up port of RPC 100003/2 on 126.28.1.117
Looking up port of RPC 100005/2 on 126.28.1.117
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 48k init
bad magic 0 (should be c01fb2e0, creator 0), wq bug, forcing oops.
kernel BUG at sched.c:656!
NIP: C000FB5C XER: 00000000 LR: C000FB5C REGS: c01adc00 TRAP: 0700
MSR: 00081032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c01ac000[1] 'init' Last syscall: 6
last math 00000000 last altivec 00000000
GPR00: C000FB5C C01ADCB0 C01AC000 0000001B 00001032 C010EF80 C01FB260 C0128502
GPR08: 0000001B C0110000 F00000B8 C01ADBF0 24444028 1001EEB4 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 C01DA060 00000000 00000000
GPR24: 00000021 00000001 C01DA060 C010A3E0 C0125000 C0110000 C01FB2D4 C01ADCB0
Call backtrace:
C000FB5C C008CB8C C007F560 C007FE8C C0033CE4 C0033D80 C0032818
C00328CC C00328FC C00048F0 10005548 10005A20 0FF09E78 00000000
Kernel panic: Exception in kernel pc c000fb5c signal 4
Rebooting in 180 seconds..


The root partition gets mounted via NFS, but we die with a scheduling
related problem.

dell 138} ./backtrace < z
0xc000fb5c -- 0xc000fad4 + 0x0088   __wake_up
0xc008cb8c -- 0xc008c8bc + 0x02d0   rs_8xx_close
0xc007f560 -- 0xc007f30c + 0x0254   release_dev
0xc007fe8c -- 0xc007fe78 + 0x0014   tty_release
0xc0033ce4 -- 0xc0033c9c + 0x0048   __fput
0xc0033d80 -- 0xc0033d60 + 0x0020   _fput
0xc0032818 -- 0xc0032784 + 0x0094   filp_close
0xc00328cc -- 0xc0032830 + 0x009c   do_close
0xc00328fc -- 0xc00328e8 + 0x0014   sys_close
0xc00048f0 -- 0xc00048f0 + 0x0000   ret_from_syscall_1
0x10005548 -- 0xc0125d84 + 0x4fedf7c4   packet_proto_init
0x10005a20 -- 0xc0125d84 + 0x4fedfc9c   packet_proto_init
0x0ff09e78 -- 0xc0125d84 + 0x4fde40f4   packet_proto_init
0x00000000 -- 0xc0125d84 + 0x3feda27c   packet_proto_init


dell 106} search '*.[hcsS]' | xargs  grep 'wq bug'
./include/linux/wait.h: printk("wq bug, forcing oops.\n"); \

"wq bug" is used in the WQ_BUG macro

#define WQ_BUG() do { \
        printk("wq bug, forcing oops.\n"); \
        BUG(); \
} while (0)

The WQ_BUG is used int the CHECK_MAGIC_WQHEAD macro.

#define CHECK_MAGIC_WQHEAD(x) do { \
        if (x->__magic != (long)&(x->__magic)) { \
                printk("bad magic %lx (should be %lx, creator %lx), ", \
                        x->__magic, (long)&(x->__magic), x->__creator); \
                WQ_BUG(); \
        } \
} while (0)



>From kernel/sched.c:

static inline void __wake_up_common(wait_queue_head_t *q, unsigned int mode, con
st int sync)
{
        struct list_head *tmp, *head;
        struct task_struct *p;
        unsigned long flags;

        if (!q)
                goto out;

        wq_write_lock_irqsave(&q->lock, flags);

#if WAITQUEUE_DEBUG
        CHECK_MAGIC_WQHEAD(q);  <<<<<<<<<<<<<<<-- Magic numbers are wrong!!!
#endif

        head = &q->task_list;
#if WAITQUEUE_DEBUG
        if (!head->next || !head->prev)
                WQ_BUG();
#endif
        list_for_each(tmp, head) {
                unsigned int state;
                wait_queue_t *curr = list_entry(tmp, wait_queue_t, task_list);

#if WAITQUEUE_DEBUG
                CHECK_MAGIC(curr->__magic);
#endif
                p = curr->task;
                state = p->state;
                if (state & (mode & ~TASK_EXCLUSIVE)) {
#if WAITQUEUE_DEBUG
                        curr->__waker = (long)__builtin_return_address(0);
#endif
                        if (sync)
                                wake_up_process_synchronous(p);
                        else
                                wake_up_process(p);
                        if (state & mode & TASK_EXCLUSIVE)
                                break;
                }
        }
        wq_write_unlock_irqrestore(&q->lock, flags);
out:
        return;
}


The last message before we die is "Freeing unused kernel memory: 48k init".
This is generated from the free_initmem() routine in arch/ppc/mm/init.c.
free_initmem() gets call from init() in init/main.c.

static int init(void * unused)
{
        lock_kernel();
        do_basic_setup();

        /*
         * Ok, we have completed the initial bootup, and
         * we're essentially up and running. Get rid of the
         * initmem segments and start the user-mode stuff..
         */
        free_initmem();  <<<<<<<<<<<<<<<-- We go this far w/o probems
        unlock_kernel();

        if (open("/dev/console", O_RDWR, 0) < 0)
                printk("Warning: unable to open an initial console.\n");

        (void) dup(0);
        (void) dup(0);

        /*
         * We try each of these until one succeeds.
         *
         * The Bourne shell can be used instead of init if we are
         * trying to recover a really broken machine.
         */

        if (execute_command)
                execve(execute_command,argv_init,envp_init);
        execve("/sbin/init",argv_init,envp_init);
        execve("/etc/init",argv_init,envp_init);
        execve("/bin/init",argv_init,envp_init);
        execve("/bin/sh",argv_init,envp_init);
        panic("No init found.  Try passing init= option to kernel.");
}


Does anybody have any hints on how I might try to debug this problem?
Options that I have thought about:

- Boot sash instead of init

Ok, I have modifified the boot params to include init=/bin/sash.
I am able to run /bin/sash, but init is giving me grief.

Note: The root file system is from the MontaVista Hard Hat Linux
      version 1.1.

./ppc_8xx/RPMS/hhl-ppc_8xx-sysvinit-2.77-6.noarch.rpm

Attached TCP/IP interface to motfcc0.
Subnet Mask: 0xff000000
Attaching network interface lo0... done.
Loading... 45680 + 465921
Starting at 0x400000...

loaded at:     00400000 0040B270
board data at: 00FFFFC0 00FFFFE4
relocated to:  00200100 00200124
zimage at:     0040B270 0047CE71
avail ram:     0047D000 01000000

Linux/PPC load: root=/dev/nfs rw nfsroot=126.28.1.117:/target nfsaddrs=126.1.4.5:126.28.1.117::255.0.0.0 init=/bin/sash
Uncompressing Linux...done.
Now booting the kernel
Total memory = 16MB; using 0kB for hash table (at 00000000)
Linux version 2.3.99-pre9 (diekema@dell) (gcc version 2.95.2 19991024 (release)) #45 Sat May 20 21:08:00 EDT 2000
Boot arguments: root=/dev/nfs rw nfsroot=126.28.1.117:/target nfsaddrs=126.1.4.5:126.28.1.117::255.0.0.0 init=/bin/sash
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Calibrating delay loop... 164.66 BogoMIPS
Memory: 14736k available (860k kernel code, 416k data, 48k init) [c0000000,c1000000]
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
kmem_create: Poisoning requested, but con given - bdev_cache
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
kmem_create: Poisoning requested, but con given - inode_cache
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
kmem_create: Poisoning requested, but con given - skbuff_head_cache
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Starting kswapd v1.6
CPM UART driver version 0.01
ttyS00 at 0x0000 is a SMC
ttyS01 at 0x0040 is a SMC
ttyS02 at 0x8100 is a SCC
ttyS03 at 0x8200 is a SCC
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: registered device at major 7
loop: enabling 8 loop devices
eth0: SCC ENET Version 0.1, 00:a0:1e:01:04:05
kmem_create: Forcing size word alignment - nfs_fh
Looking up port of RPC 100003/2 on 126.28.1.117
Looking up port of RPC 100005/2 on 126.28.1.117
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 48k init
Stand-alone shell (version 3.4)
> /etc/rc*
+ /sbin/ifconfig lo 127.0.0.1
+
+ mount /proc
+ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:A0:1E:01:04:05
          inet addr:126.1.4.5  Bcast:126.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1227 errors:0 dropped:0 overruns:0 frame:0
          TX packets:490 errors:0 dropped:0 overruns:0 carrier:0
          collisions:4 txqueuelen:100
          Base address:0x8000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3904  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

+ mount -a
+ mount -o rsize=8192,wsize=8192,rw,remount /

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Wait Queue bug triggered on EST SBC8260

[diekema_jon]

Previous message:

http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00180.html

> bad magic 0 (should be c01fb2e0, creator 0), wq bug, forcing oops.
> kernel BUG at sched.c:656!
> NIP: C000FB5C XER: 00000000 LR: C000FB5C REGS: c01adc00 TRAP: 0700
> MSR: 00081032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = c01ac000[1] 'init' Last syscall: 6
> last math 00000000 last altivec 00000000
> GPR00: C000FB5C C01ADCB0 C01AC000 0000001B 00001032 C010EF80 C01FB260 C0128502
> GPR08: 0000001B C0110000 F00000B8 C01ADBF0 24444028 1001EEB4 00000000 00000000
> GPR16: 00000000 00000000 00000000 00000000 00009032 C01DA060 00000000 00000000
> GPR24: 00000021 00000001 C01DA060 C010A3E0 C0125000 C0110000 C01FB2D4 C01ADCB0
> Call backtrace:
> C000FB5C C008CB8C C007F560 C007FE8C C0033CE4 C0033D80 C0032818
> C00328CC C00328FC C00048F0 10005548 10005A20 0FF09E78 00000000
> Kernel panic: Exception in kernel pc c000fb5c signal 4
> Rebooting in 180 seconds..

We are walking into a scheduling bug in kernel/sched.c with Linux
2.3.99-pre9.  MontaVista has an experimental real-time scheduler that
can be installed into Linux 2.2.14.  Will this scheduler work with
Linux 2.3.99-pre9?  If it has a shot at working, I would like to try
it.  Perhaps I can avoid my problem.


>From hhl-kernel-rtsched.patch:

REAL TIME SCHEDULER for Linux version 2.2.14

Released under the GNU Public License.

This patch contains the real time scheduler developed by
MontaVista Software, Inc.  It applies cleanly against the
Linux kernel version 2.2.14.  It adds the kernel configuration
option CONFIG_RTSCHED.  If CONFIG_RTSCHED=y, the real time
scheduler is configured, otherwise the standard scheduler is
used.

This patch also contains some fixes for the standard scheduler.

May 5, 2000:
Add real time scheduler option, as well as fixes for the standard scheduler.
This updated version fixes a build problem on the PowerPC.

CONTACT: <source@mvista.com>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Wait Queue bug triggered on EST SBC8260

[Joe Green]

As the patch indicates, we've only really built and tested this for
2.2.14 at this time.  We will be porting the scheduler to 2.4 when we
add support for that release, but I can't tell you if or when it might
be ported to any of the 2.3 versions.  The source code is provided, so
you can try to port it yourself if you wish.

On Wed, 24 May 2000, diekema_jon wrote:
> Previous message:
>
> http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00180.html
>
> > bad magic 0 (should be c01fb2e0, creator 0), wq bug, forcing oops.
> > kernel BUG at sched.c:656!
> > NIP: C000FB5C XER: 00000000 LR: C000FB5C REGS: c01adc00 TRAP: 0700
> > MSR: 00081032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> > TASK = c01ac000[1] 'init' Last syscall: 6
> > last math 00000000 last altivec 00000000
> > GPR00: C000FB5C C01ADCB0 C01AC000 0000001B 00001032 C010EF80 C01FB260 C0128502
> > GPR08: 0000001B C0110000 F00000B8 C01ADBF0 24444028 1001EEB4 00000000 00000000
> > GPR16: 00000000 00000000 00000000 00000000 00009032 C01DA060 00000000 00000000
> > GPR24: 00000021 00000001 C01DA060 C010A3E0 C0125000 C0110000 C01FB2D4 C01ADCB0
> > Call backtrace:
> > C000FB5C C008CB8C C007F560 C007FE8C C0033CE4 C0033D80 C0032818
> > C00328CC C00328FC C00048F0 10005548 10005A20 0FF09E78 00000000
> > Kernel panic: Exception in kernel pc c000fb5c signal 4
> > Rebooting in 180 seconds..
>
> We are walking into a scheduling bug in kernel/sched.c with Linux
> 2.3.99-pre9.  MontaVista has an experimental real-time scheduler that
> can be installed into Linux 2.2.14.  Will this scheduler work with
> Linux 2.3.99-pre9?  If it has a shot at working, I would like to try
> it.  Perhaps I can avoid my problem.
>
>
> From hhl-kernel-rtsched.patch:
>
> REAL TIME SCHEDULER for Linux version 2.2.14
>
> Released under the GNU Public License.
>
> This patch contains the real time scheduler developed by
> MontaVista Software, Inc.  It applies cleanly against the
> Linux kernel version 2.2.14.  It adds the kernel configuration
> option CONFIG_RTSCHED.  If CONFIG_RTSCHED=y, the real time
> scheduler is configured, otherwise the standard scheduler is
> used.
>
> This patch also contains some fixes for the standard scheduler.
>
> May 5, 2000:
> Add real time scheduler option, as well as fixes for the standard scheduler.
> This updated version fixes a build problem on the PowerPC.
>
> CONTACT: <source@mvista.com>
--
Joe Green <jgreen@mvista.com>
MontaVista Software, Inc.
(408) 328-9209

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Wait Queue bug triggered on EST SBC8260

[Joe Green]

I should also point out that the real-time scheduler primarily changes
the responsiveness of processes and threads that are scheduled with
real-time priorities.  Non-realtime threads are handled by the standard
scheduler algorithm, so if there's a bug in there it may very well
still be present with the real-time scheduler, unless it was something
we caught in our testing.

On Wed, 24 May 2000, diekema_jon wrote:
> Previous message:
>
> http://lists.linuxppc.org/listarcs/linuxppc-embedded/200005/msg00180.html
>
> > bad magic 0 (should be c01fb2e0, creator 0), wq bug, forcing oops.
> > kernel BUG at sched.c:656!
> > NIP: C000FB5C XER: 00000000 LR: C000FB5C REGS: c01adc00 TRAP: 0700
> > MSR: 00081032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> > TASK = c01ac000[1] 'init' Last syscall: 6
> > last math 00000000 last altivec 00000000
> > GPR00: C000FB5C C01ADCB0 C01AC000 0000001B 00001032 C010EF80 C01FB260 C0128502
> > GPR08: 0000001B C0110000 F00000B8 C01ADBF0 24444028 1001EEB4 00000000 00000000
> > GPR16: 00000000 00000000 00000000 00000000 00009032 C01DA060 00000000 00000000
> > GPR24: 00000021 00000001 C01DA060 C010A3E0 C0125000 C0110000 C01FB2D4 C01ADCB0
> > Call backtrace:
> > C000FB5C C008CB8C C007F560 C007FE8C C0033CE4 C0033D80 C0032818
> > C00328CC C00328FC C00048F0 10005548 10005A20 0FF09E78 00000000
> > Kernel panic: Exception in kernel pc c000fb5c signal 4
> > Rebooting in 180 seconds..
>
> We are walking into a scheduling bug in kernel/sched.c with Linux
> 2.3.99-pre9.  MontaVista has an experimental real-time scheduler that
> can be installed into Linux 2.2.14.  Will this scheduler work with
> Linux 2.3.99-pre9?  If it has a shot at working, I would like to try
> it.  Perhaps I can avoid my problem.
>
>
> From hhl-kernel-rtsched.patch:
>
> REAL TIME SCHEDULER for Linux version 2.2.14
>
> Released under the GNU Public License.
>
> This patch contains the real time scheduler developed by
> MontaVista Software, Inc.  It applies cleanly against the
> Linux kernel version 2.2.14.  It adds the kernel configuration
> option CONFIG_RTSCHED.  If CONFIG_RTSCHED=y, the real time
> scheduler is configured, otherwise the standard scheduler is
> used.
>
> This patch also contains some fixes for the standard scheduler.
>
> May 5, 2000:
> Add real time scheduler option, as well as fixes for the standard scheduler.
> This updated version fixes a build problem on the PowerPC.
>
> CONTACT: <source@mvista.com>

--
Joe Green <jgreen@mvista.com>
MontaVista Software, Inc.
(408) 328-9209

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/