[Barrelfish-users] {Disarmed} Re: Problems when booting Barrelfish on SCC
Stefan Kästle
stefan.kaestle at inf.ethz.ch
Sat Apr 28 16:41:03 CEST 2012
I used the one shipped with the release:
timeout 0
# spawnd is used to control which cpus are booted
#
# "spawnd boot" will use the skb and pci to figure out and
# boot all cores in the machine
#
# "spawnd boot bootscc=1-6" will not use the skb and
# boot the list of cores passed as argument.
# The hardware id of the cores to boot should be specified.
# This list may not include the bsp core id.
title Barrelfish
root (nd)
kernel /scc/sbin/cpu loglevel=4
module /scc/sbin/cpu
module /scc/sbin/init
# Domains spawned by init
module /scc/sbin/mem_serv
module /scc/sbin/monitor
module /scc/sbin/chips boot
module /scc/sbin/ramfsd boot
module /scc/sbin/spawnd boot bootscc=1,2,3
module /scc/sbin/startd boot
# modules needed to start the networking
# module /scc/sbin/eMAC core=0
# module /scc/sbin/netd core=0 cardname=eMAC2_0
# module /scc/sbin/eMAC core=1
# module /scc/sbin/netd core=1 cardname=eMAC2_1
# Test for network throughput
# module /scc/sbin/netthroughput core=1 /nfs nfs://10.110.4.41/shared
/nfs/pravin/testfile.txt
# For webserver
# module /scc/sbin/webserver core=1 eMAC2_1 10.110.4.41 /shared/pravin/sw
# RCK memory map
# Everything up til VGA is private RAM (maybe we want to throw it away)
mmap map 0x0 0xa000 2
# Everything after VGA is private RAM (we also live in this area)
mmap map 0xe800 0x26ff1800 1
# Shared RAM (over all MCs) in the middle of address space
#mmap map 0x80000000 0x4000000 1
mmap map 0x80000000 0x40000000 1
# At the very end we have some platform memory (bootup EEPROM)
mmap map 0xfffc0000 0x40000 2
The following patch fixes your issue. Can you try if this work for your
tree? I only tested this on the tip (where the problem was fixed, but
the system did still not come up). How to you train and boot the SCC?
diff -r b8f91be7c881 kernel/arch/x86/startup_x86.c
--- a/kernel/arch/x86/startup_x86.c Fri Mar 02 09:46:13 2012 +0100
+++ b/kernel/arch/x86/startup_x86.c Mon Apr 23 21:46:11 2012 +0200
@@ -302,7 +302,9 @@
/* spawn init */
init_dcb = spawn_bsp_init(BSP_INIT_MODULE_PATH, bsp_alloc_phys);
} else {
+#if !defined(__scc__)
my_core_id = core_data->dst_core_id;
+#endif
/* Initialize the allocator */
app_alloc_phys_start = core_data->memory_base_start;diff -r
b8f91be7c881 kernel/arch/x86_32/init.c
--- a/kernel/arch/x86_32/init.c Fri Mar 02 09:46:13 2012 +0100
+++ b/kernel/arch/x86_32/init.c Mon Apr 23 21:46:11 2012 +0200
@@ -573,7 +573,8 @@
// XXX: Set core ID and fake APIC ID to be the tile's core ID
my_core_id = apic_id = rck_get_coreid();
- printf("My APIC ID: %d\n", apic_id);
+ apic_bsp = (my_core_id == 0);
+ printf("My APIC ID: %d bsp=%d\n", apic_id, apic_bsp);
#endif
// do not remove/change this printf: needed by regression harness
On 04/28/2012 03:51 PM, Shi Jinghao (史经浩） wrote:
> I did a clean clone of release2011-09-02
>
> hg clone -r release2011-09-02 http://hg.barrelfish.org release2011-09-02
>
> and it still fails with this message when booting:
>
> kernel 1 PANIC! kernel assertion "rck_get_coreid() == 0" failed at
> ../kernel/arch/scc/rck.c:874
>
> which shows that kernel 1 is still trying to boot other cores. The
> same output also occurs on a
> clean release2011-11-10.
>
> Can you show me your menu.lst.scc
> so that I can check if my boot configuration is not correct. Mine is:
>
> 1 timeout 0
> 2
> 3 # spawnd is used to control which cpus are booted
> 4 #
> 5 # "spawnd boot" will use the skb and pci to figure out and
> 6 # boot all cores in the machine
> 7 #
> 8 # "spawnd boot bootscc=1-6" will not use the skb and
> 9 # boot the list of cores passed as argument.
> 10 # The hardware id of the cores to boot should be specified.
> 11 # This list may not include the bsp core id.
> 12
> 13 title Barrelfish
> 14 root (nd)
> 15 kernel /scc/sbin/cpu loglevel=4
> 16 module /scc/sbin/cpu
> 17 module /scc/sbin/init
> 18
> 19 # Domains spawned by init
> 20 module /scc/sbin/mem_serv
> 21 module /scc/sbin/monitor
> 22
> 23 module /scc/sbin/chips boot
> 24 module /scc/sbin/ramfsd boot
> 25 module /scc/sbin/spawnd boot bootscc=1-3
> 26 module /scc/sbin/startd boot
> 27
> 28 module /scc/sbin/examples/xmpl-hello core=0
> 29
> 30 # modules needed to start the networking
> 31 # module /scc/sbin/eMAC core=0 device=2
> 32 # module /scc/sbin/netd core=0 cardname=eMAC2_0
> 33 # module /scc/sbin/eMAC core=1
> 34 # module /scc/sbin/netd core=1 cardname=eMAC2_1
> 35
> 36 # Test for network throughput
> 37 # module /scc/sbin/netthroughput core=1 /nfs
> nfs://10.110.4.41/shared <http://10.110.4.41/shared>
> /nfs/pravin/testfile.txt
> 38
> 39 # For webserver
> 40 # module /scc/sbin/webserver core=1 eMAC2_1 10.110.4.41
> /shared/pravin/sw
> 41
> 42 # RCK memory map
> 43 # Everything up til VGA is private RAM (maybe we want to throw it
> away)
> 44 mmap map 0x0 0xa000 2
> 45 # Everything after VGA is private RAM (we also live in this area)
> 46 mmap map 0xe800 0x26ff1800 1
> 47 # Shared RAM (over all MCs) in the middle of address space
> 48 #mmap map 0x80000000 0x4000000 1
> 49 mmap map 0x80000000 0x40000000 1
> 50 # At the very end we have some platform memory (bootup EEPROM)
> 51 mmap map 0xfffc0000 0x40000 2
>
>
> On Sat, Apr 28, 2012 at 5:23 PM, Stefan Kästle
> <stefan.kaestle at inf.ethz.ch <mailto:stefan.kaestle at inf.ethz.ch>> wrote:
>
> Hi,
>
> Yes, exactly: apic_is_bsp is broken on the SCC. It should use
> rck_get_coreid to initialize apic_bsp, but I doesn't. If fixed
> this issue in my tree, but it won't help you, as there are more
> bugs coming up after that.
>
> Are you sure you reverted your revision properly? Can you try a
> clean clone of that revision? I tested revision release2011-09-02
> on our SCC, and it worked.
>
>
> On 04/27/2012 11:55 AM, Shi Jinghao (史经浩） wrote:
>>
>> Here is my progress update on the problem of booting on SCC.
>>
>> I found that the variable bsp is not correctly set in apic_init
>> (/kernel/arch/x86/apic.c). bsp is initiated as true when defined.
>> But there is no code that set its value when __scc__ is defined.
>> The only code that touch bsp is wapped by #if !defined(__scc__)
>> || defined.
>>
>> So I added the following line in text_init
>> (/kernel/arch/x86_32/init.c), right after print the "My APIC ID:"
>> message,
>>
>> bsp = (apic_id == 0);
>>
>> It's a temporal hack that we assume core 0 is always the bsp core.
>>
>> After done this, core 1 will realize that it's not bsp core so it
>> will not try to boot core 0. But then I immediately found that
>> the core_data passed to core 1 is corrupted. I found this from:
>>
>> - core_data->memory_base_start = 0x0ffb7000, which seems ok but
>> core_data->memory_bits = 0, this will make app_alloc_phys_end =
>> 0x0ffb7001 and fail app_alloc_phys
>>
>> - core_data->dst_core_id and src_arch_id is wrong (some
>> meaningless number)
>>
>> I'm trying to figure out whether core 0 has place the
>> x86_core_data structure correctly..
>>
>> Thanks,
>> Jinghao
>>
>> On Fri, Apr 27, 2012 at 2:18 PM, Shi Jinghao <jhshi89 at gmail.com
>> <mailto:jhshi89 at gmail.com>> wrote:
>>
>> Hi, Stefan,
>>
>> I tried release2011-09-02 but it's still not work, and the
>> same problem occurs.
>>
>> Don't know if you got any clue yet, but when I insert a
>> printk in function kernel_startup
>> (/kernel/arch/x86/startup_x86.c). I find that the function
>> apic_is_bsp() may not work properly: each core think it'
>> startup core!! But when I traced the code and come to
>> apic_base_msr (function apic_init in file
>> /kernel/arch/x86/apic.c), I am lost, and can not figure out
>> where apic_base_msr.bsp is set. Any hints here?
>>
>> Thanks,
>> Jinghao
>>
>>
>> Here is the code snippet where I inserted printk, FYI:
>>
>> 290 if (apic_is_bsp()) {
>> 291 printk(LOG_DEBUG, "\n in kernel_startup, I am
>> BSP\n");
>> 292 /* Initialize the location to allocate phys
>> memory from */
>> 293 bsp_init_alloc_addr = glbl_core_data->start_free_ram;
>> 294
>> 295 /* spawn init */
>> 296 init_dcb = spawn_bsp_init(BSP_INIT_MODULE_PATH,
>> bsp_alloc_phys);
>> 297 } else {
>> 298 printk(LOG_DEBUG, "\n in kernel_startup, I am NOT
>> BSP\n");
>> 299 my_core_id = core_data->dst_core_id;
>> 300
>> 301 /* Initialize the allocator */
>> 302 app_alloc_phys_start = core_data->memory_base_start;
>> 303 app_alloc_phys_end = ((lpaddr_t)1 <<
>> core_data->memory_bits) +
>> 304 app_alloc_phys_start;
>> 305
>> 306 init_dcb = spawn_app_init(core_data,
>> APP_INIT_PROG_NAME, app_alloc_phys);
>> 307 }
>>
>>
>> On Tue, Apr 24, 2012 at 4:13 AM, Stefan Kästle
>> <stefan.kaestle at inf.ethz.ch
>> <mailto:stefan.kaestle at inf.ethz.ch>> wrote:
>>
>> Hi,
>>
>> this is harder to fix than I originally though. I will
>> take some time to fix (especially since I am a little
>> busy right now).
>>
>> Maybe you want to use an earlier version of Barrelfish in
>> the meanwhile, e.g. revision release2011-09-02?! Since
>> then, nothing significantly changed for the SCC code
>> anyway. That one works fine on our SCC. In case you
>> revert, make sure to do a clean rebuild!
>>
>> Cheers
>> Stefan
>>
>> On 04/22/2012 12:18 PM, Shi Jinghao (史经浩） wrote:
>>> Hi, stefan.
>>>
>>> I changed the line as you instructed and it works. But
>>> when I try to boot core 0, 1, 2 ,3
>>> with the following line:
>>>
>>> module /scc/sbin/spawnd boot bootscc=1-3
>>>
>>> The same problem occurs (ouput attached). So what's the
>>> proper syntax that correctly
>>> boot scc cores (e.g. {0, 1, 2, 3}, or {0, 2, 4, 6} )?
>>>
>>> Regards,
>>> Jinghao
>>>
>>> ---------- OUTPUT START ------------------------------
>>> Kernel starting at address 0x80100000
>>> Barrelfish CPU driver starting on scc core 0
>>> init: invoked as: init 2097152
>>> Spawning memory server (scc/sbin/mem_serv)...
>>> Spawning monitor (scc/sbin/monitor)...
>>> starting monitor as 'scc/sbin/monitor 327680 '
>>> monitor: invoked as: scc/sbin/monitor 327680
>>> RAM allocator initialised, 1612 MB (of 1628 MB) available
>>> Spawning chips on core 0
>>> Spawning /scc/sbin/ramfsd on core 0
>>> Spawning /scc/sbin/spawnd on core 0
>>> Spawning /scc/sbin/startd on core 0
>>> 0 chips: client waiting for ramfs
>>> ramfsd.0: pre-populating from boot image...
>>> 0 chips: client waiting for ramfs
>>> ramfsd.0: ready
>>> 0 chips: notifying client about ramfs
>>> 0 chips: notifying client about ramfs
>>> kernel 0: Allocating RAM at 0x80000000 uninitialized
>>> kernel 0: Allocating RAM at 0x80010000 uninitialized
>>> spawnd.0: coreid 0 is arch id 0
>>> spawnd.0: coreid 1 is arch id 1
>>> spawnd.0: coreid 2 is arch id 2
>>> spawnd.0: coreid 3 is arch id 3
>>> 0 chips: client waiting for all_spawnds_up
>>> Monitor 0: booting scc core 1 as '/scc/sbin/cpu'
>>> kernel 0: Allocating RAM at 0x80020000 uninitialized
>>> Kernel starting at address 0x80100000
>>> My APIC ID: 1
>>> Barrelfish CPU driver starting on scc core 1
>>> init: invoked as: init 2097152
>>> Spawning memory server (scc/sbin/mem_serv)...
>>> Spawning monitor (scc/sbin/monitor)...
>>> starting monitor as 'scc/sbin/monitor 327680 '
>>> monitor: invoked as: scc/sbin/monitor 327680
>>> RAM allocator initialised, 1612 MB (of 1628 MB) available
>>> Spawning chips on core 1
>>> Spawning /scc/sbin/ramfsd on core 1
>>> Spawning /scc/sbin/spawnd on core 1
>>> Spawning /scc/sbin/startd on core 1
>>> 0 chips: client waiting for ramfs
>>> ramfsd.1: pre-populating from boot image...
>>> 0 chips: client waiting for ramfs
>>> ramfsd.1: ready
>>> 0 chips: notifying client about ramfs
>>> 0 chips: notifying client about ramfs
>>> kernel 1: Allocating RAM at 0x84000000 uninitialized
>>> kernel 1: Allocating RAM at 0x84010000 uninitialized
>>> spawnd.1: coreid 0 is arch id 2
>>> spawnd.1: coreid 1 is arch id 1
>>> spawnd.1: coreid 2 is arch id 3
>>> 0 chips: client waiting for all_spawnds_up
>>> Monitor 1: booting scc core 0 as '/scc/sbin/cpu'
>>> kernel 1: Allocating RAM at 0x84020000 uninitialized
>>> kernel 1 PANIC! kernel assertion "rck_get_coreid() == 0"
>>> failed at ../kernel/arch/scc/rck.c:876
>>> kernel 1: exception 3 (error code 0x0): breakpoint
>>> On behalf of: monitor
>>> Faulting instruction pointer (or following instruction):
>>> 0x8010a7bf (0x 10a7bf in binary)
>>> EAX 0x80118000 EBX 0x80116e88 ECX 0x0 EDX 0x805202c0 ESP
>>> 0x80920a08
>>> Top o' stack:
>>> 0x8010a7bf 0x2 0x8 0x10 0x3 0x0 0x8010a7bf 0x8 0x2
>>> 0x80520180 0x80116e88 0x80920a44 0x8010c612 0x80116e88
>>> 0x210d6000 0x80920a64 0x8010c64b 0x801164a0 0x80114c10
>>> 0x80114b55
>>> No GDB backend
>>> ---------------- OUTPUT END ----------------------------
>>>
>>>
>>> On Sun, Apr 22, 2012 at 5:33 PM,
>>> <barrelfish-users-request at lists.inf.ethz.ch
>>> <mailto:barrelfish-users-request at lists.inf.ethz.ch>> wrote:
>>>
>>> Send Barrelfish-users mailing list submissions to
>>> barrelfish-users at lists.inf.ethz.ch
>>> <mailto:barrelfish-users at lists.inf.ethz.ch>
>>>
>>> To subscribe or unsubscribe via the World Wide Web,
>>> visit
>>> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>>> or, via email, send a message with subject or body
>>> 'help' to
>>> barrelfish-users-request at lists.inf.ethz.ch
>>> <mailto:barrelfish-users-request at lists.inf.ethz.ch>
>>>
>>> You can reach the person managing the list at
>>> barrelfish-users-owner at lists.inf.ethz.ch
>>> <mailto:barrelfish-users-owner at lists.inf.ethz.ch>
>>>
>>> When replying, please edit your Subject line so it
>>> is more specific
>>> than "Re: Contents of Barrelfish-users digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Problems when booting Barrelfish on SCC (????
>>> <jhshi at cs.hku.hk <mailto:jhshi at cs.hku.hk>>)
>>> 2. Re: Problems when booting Barrelfish on SCC
>>> (Stefan K?stle)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sun, 22 Apr 2012 17:12:57 +0800
>>> From: Shi Jinghao (???? <jhshi at cs.hku.hk
>>> <mailto:jhshi at cs.hku.hk>>
>>> Subject: [Barrelfish-users] Problems when booting
>>> Barrelfish on SCC
>>> To: barrelfish-users at lists.inf.ethz.ch
>>> <mailto:barrelfish-users at lists.inf.ethz.ch>
>>> Message-ID:
>>> <CAKdW-HFRKv6HWqAxwsL5MMJRqot6BSPkHXPx9ecXg3eaONRHZw at mail.gmail.com
>>> <mailto:CAKdW-HFRKv6HWqAxwsL5MMJRqot6BSPkHXPx9ecXg3eaONRHZw at mail.gmail.com>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hi,
>>>
>>> I'm trying to boot barrelfish on SCC. I've managed
>>> to compile the source,
>>> get barrelfish0.obj and barrelfish48.mt
>>> <http://barrelfish48.mt>.
>>> Then I use the bootscc.sh to boot it. For test, I
>>> just want to boot core 0
>>> and core 1, but a weird problem
>>> happens: core 1 is trying to boot core 0. Here is
>>> the output after system
>>> start.
>>>
>>> ----------------------OUTPUT START
>>> ------------------------------------
>>> Kernel starting at address 0x80100000
>>> hku at ubuntu:~/fish/hg.barrelfish.org/build$
>>> <http://hg.barrelfish.org/build$> My APIC ID: 0
>>> Barrelfish CPU driver starting on scc core 0
>>> init: invoked as: init 2097152
>>> Spawning memory server (scc/sbin/mem_serv)...
>>> Spawning monitor (scc/sbin/monitor)...
>>> starting monitor as 'scc/sbin/monitor 327680 '
>>> monitor: invoked as: scc/sbin/monitor 327680
>>> RAM allocator initialised, 1612 MB (of 1628 MB)
>>> available
>>> Spawning chips on core 0
>>> Spawning /scc/sbin/ramfsd on core 0
>>> Spawning /scc/sbin/spawnd on core 0
>>> Spawning /scc/sbin/startd on core 0
>>> 0 chips: client waiting for ramfs
>>> ramfsd.0: pre-populating from boot image...
>>> 0 chips: client waiting for ramfs
>>> ramfsd.0: ready
>>> 0 chips: notifying client about ramfs
>>> 0 chips: notifying client about ramfs
>>> kernel 0: Allocating RAM at 0x80000000 uninitialized
>>> kernel 0: Allocating RAM at 0x80010000 uninitialized
>>> spawnd.0: coreid 0 is arch id 0
>>> spawnd.0: coreid 1 is arch id 1
>>> 0 chips: client waiting for all_spawnds_up
>>> Monitor 0: booting scc core 1 as '/scc/sbin/cpu'
>>> kernel 0: Allocating RAM at 0x80020000 uninitialized
>>> Kernel starting at address 0x80100000
>>> My APIC ID: 1
>>> Barrelfish CPU driver starting on scc core 1
>>> init: invoked as: init 2097152
>>> Spawning memory server (scc/sbin/mem_serv)...
>>> Spawning monitor (scc/sbin/monitor)...
>>> starting monitor as 'scc/sbin/monitor 327680 '
>>> monitor: invoked as: scc/sbin/monitor 327680
>>> RAM allocator initialised, 1612 MB (of 1628 MB)
>>> available
>>> Spawning chips on core 1
>>> Spawning /scc/sbin/ramfsd on core 1
>>> Spawning /scc/sbin/spawnd on core 1
>>> Spawning /scc/sbin/startd on core 1
>>> 0 chips: client waiting for ramfs
>>> ramfsd.1: pre-populating from boot image...
>>> 0 chips: client waiting for ramfs
>>> ramfsd.1: ready
>>> 0 chips: notifying client about ramfs
>>> 0 chips: notifying client about ramfs
>>> kernel 1: Allocating RAM at 0x84000000 uninitialized
>>> kernel 1: Allocating RAM at 0x84010000 uninitialized
>>> spawnd.1: coreid 0 is arch id 0
>>> spawnd.1: coreid 1 is arch id 1
>>> 0 chips: client waiting for all_spawnds_up
>>> Monitor 1: booting scc core 0 as '/scc/sbin/cpu'
>>> ********* Why would core 1 want to boot core 0 ?
>>> **************
>>> kernel 1: Allocating RAM at 0x84020000 uninitialized
>>> kernel 1 PANIC! kernel assertion "rck_get_coreid()
>>> == 0" failed at
>>> ../kernel/arch/scc/rck.c:876
>>> kernel 1: exception 3 (error code 0x0): breakpoint
>>> On behalf of: monitor
>>> Faulting instruction pointer (or following
>>> instruction): 0x8010a7bf (0x
>>> 10a7bf in binary)
>>> EAX 0x80118000 EBX 0x80116e88 ECX 0x0 EDX 0x805202c0
>>> ESP 0x80920a08
>>> Top o' stack:
>>> 0x8010a7bf 0x2 0x8 0x10 0x3 0x0 0x8010a7bf 0x8 0x2
>>> 0x80520180 0x80116e88
>>> 0x80920a44 0x8010c612 0x80116e88 0x210d6000
>>> 0x80920a64 0x8010c64b
>>> 0x801164a0 0x80114c10 0x80114b55
>>> No GDB backend
>>> --------------- OUTPUT END
>>> ------------------------------
>>>
>>> As I see it, core 1 seems thought that it's the bsp
>>> core (while it's not)
>>> so it's responsible to boot other cores. But I fail
>>> to see why core 1 would
>>> think like that.
>>>
>>> Any ideas on this? Thanks in advance.
>>>
>>> Regards,
>>> Jinghao
>>>
>>> FYI, this is my menu.lst.scc
>>>
>>> 1 timeout 0
>>> 2
>>> 3 # spawnd is used to control which cpus are booted
>>> 4 #
>>> 5 # "spawnd boot" will use the skb and pci to
>>> figure out and
>>> 6 # boot all cores in the machine
>>> 7 #
>>> 8 # "spawnd boot bootscc=1-6" will not use the skb and
>>> 9 # boot the list of cores passed as argument.
>>> 10 # The hardware id of the cores to boot should be
>>> specified.
>>> 11 # This list may not include the bsp core id.
>>> 12
>>> 13 title Barrelfish
>>> 14 root (nd)
>>> 15 kernel /scc/sbin/cpu loglevel=4
>>> 16 module /scc/sbin/cpu
>>> 17 module /scc/sbin/init
>>> 18
>>> 19 # Domains spawned by init
>>> 20 module /scc/sbin/mem_serv
>>> 21 module /scc/sbin/monitor
>>> 22
>>> 23 module /scc/sbin/chips boot
>>> 24 module /scc/sbin/ramfsd boot
>>> 25 module /scc/sbin/spawnd boot bootscc=0-1
>>> 26 module /scc/sbin/startd boot
>>> 27
>>> 28 #module /scc/sbin/examples/xmpl-hello
>>> 29
>>> 30 # modules needed to start the networking
>>> 31 # module /scc/sbin/eMAC core=0 device=2
>>> 32 # module /scc/sbin/netd core=0 cardname=eMAC2_0
>>> 33 # module /scc/sbin/eMAC core=1
>>> 34 # module /scc/sbin/netd core=1 cardname=eMAC2_1
>>> 35
>>> 36 # Test for network throughput
>>> 37 # module /scc/sbin/netthroughput core=1 /nfs
>>> nfs://*MailScanner warning: numerical links are
>>> often malicious:*
>>> 10.110.4.41/shared/nfs/pravin/testfile.txt
>>> <http://10.110.4.41/shared/nfs/pravin/testfile.txt>
>>> 38
>>> 39 # For webserver
>>> 40 # module /scc/sbin/webserver core=1 eMAC2_1
>>> 10.110.4.41
>>> /shared/pravin/sw
>>> 41
>>> 42 # RCK memory map
>>> 43 # Everything up til VGA is private RAM (maybe we
>>> want to throw it away)
>>> 44 mmap map 0x0 0xa000 2
>>> 45 # Everything after VGA is private RAM (we also
>>> live in this area)
>>> 46 mmap map 0xe800 0x26ff1800 1
>>> 47 # Shared RAM (over all MCs) in the middle of
>>> address space
>>> 48 #mmap map 0x80000000 0x4000000 1
>>> 49 mmap map 0x80000000 0x40000000 1
>>> 50 # At the very end we have some platform memory
>>> (bootup EEPROM)
>>> 51 mmap map 0xfffc0000 0x40000 2
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120422/e2ff7982/attachment-0001.html
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sun, 22 Apr 2012 11:33:52 +0200
>>> From: Stefan K?stle <stefan.kaestle at inf.ethz.ch
>>> <mailto:stefan.kaestle at inf.ethz.ch>>
>>> Subject: Re: [Barrelfish-users] Problems when
>>> booting Barrelfish on
>>> SCC
>>> To: <barrelfish-users at lists.inf.ethz.ch
>>> <mailto:barrelfish-users at lists.inf.ethz.ch>>
>>> Message-ID: <4F93D080.6080905 at inf.ethz.ch
>>> <mailto:4F93D080.6080905 at inf.ethz.ch>>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hi,
>>>
>>> can you try replacing
>>> module /scc/sbin/spawnd boot bootscc=0-1
>>> with
>>> module /scc/sbin/spawnd boot bootscc=1
>>> and try it again?
>>>
>>> The boot-up of core 0 is implicit - we do not
>>> specify it as a spwand
>>> argument.
>>>
>>> Cheers,
>>> Stefan
>>>
>>> On 04/22/2012 11:12 AM, Shi Jinghao (???) wrote:
>>> > Hi,
>>> >
>>> > I'm trying to boot barrelfish on SCC. I've managed
>>> to compile the
>>> > source, get barrelfish0.obj and barrelfish48.mt
>>> <http://barrelfish48.mt> <http://barrelfish48.mt>.
>>> > Then I use the bootscc.sh to boot it. For test, I
>>> just want to boot
>>> > core 0 and core 1, but a weird problem
>>> > happens: core 1 is trying to boot core 0. Here is
>>> the output after
>>> > system start.
>>> >
>>> > ----------------------OUTPUT START
>>> ------------------------------------
>>> > Kernel starting at address 0x80100000
>>> > hku at ubuntu:~/fish/hg.barrelfish.org/build$
>>> <http://hg.barrelfish.org/build$>
>>> > <http://hg.barrelfish.org/build$> My APIC ID: 0
>>> > Barrelfish CPU driver starting on scc core 0
>>> > init: invoked as: init 2097152
>>> > Spawning memory server (scc/sbin/mem_serv)...
>>> > Spawning monitor (scc/sbin/monitor)...
>>> > starting monitor as 'scc/sbin/monitor 327680 '
>>> > monitor: invoked as: scc/sbin/monitor 327680
>>> > RAM allocator initialised, 1612 MB (of 1628 MB)
>>> available
>>> > Spawning chips on core 0
>>> > Spawning /scc/sbin/ramfsd on core 0
>>> > Spawning /scc/sbin/spawnd on core 0
>>> > Spawning /scc/sbin/startd on core 0
>>> > 0 chips: client waiting for ramfs
>>> > ramfsd.0: pre-populating from boot image...
>>> > 0 chips: client waiting for ramfs
>>> > ramfsd.0: ready
>>> > 0 chips: notifying client about ramfs
>>> > 0 chips: notifying client about ramfs
>>> > kernel 0: Allocating RAM at 0x80000000 uninitialized
>>> > kernel 0: Allocating RAM at 0x80010000 uninitialized
>>> > spawnd.0: coreid 0 is arch id 0
>>> > spawnd.0: coreid 1 is arch id 1
>>> > 0 chips: client waiting for all_spawnds_up
>>> > Monitor 0: booting scc core 1 as '/scc/sbin/cpu'
>>> > kernel 0: Allocating RAM at 0x80020000 uninitialized
>>> > Kernel starting at address 0x80100000
>>> > My APIC ID: 1
>>> > Barrelfish CPU driver starting on scc core 1
>>> > init: invoked as: init 2097152
>>> > Spawning memory server (scc/sbin/mem_serv)...
>>> > Spawning monitor (scc/sbin/monitor)...
>>> > starting monitor as 'scc/sbin/monitor 327680 '
>>> > monitor: invoked as: scc/sbin/monitor 327680
>>> > RAM allocator initialised, 1612 MB (of 1628 MB)
>>> available
>>> > Spawning chips on core 1
>>> > Spawning /scc/sbin/ramfsd on core 1
>>> > Spawning /scc/sbin/spawnd on core 1
>>> > Spawning /scc/sbin/startd on core 1
>>> > 0 chips: client waiting for ramfs
>>> > ramfsd.1: pre-populating from boot image...
>>> > 0 chips: client waiting for ramfs
>>> > ramfsd.1: ready
>>> > 0 chips: notifying client about ramfs
>>> > 0 chips: notifying client about ramfs
>>> > kernel 1: Allocating RAM at 0x84000000 uninitialized
>>> > kernel 1: Allocating RAM at 0x84010000 uninitialized
>>> > spawnd.1: coreid 0 is arch id 0
>>> > spawnd.1: coreid 1 is arch id 1
>>> > 0 chips: client waiting for all_spawnds_up
>>> > Monitor 1: booting scc core 0 as '/scc/sbin/cpu'
>>> > ********* Why would core 1 want to boot core 0 ?
>>> **************
>>> > kernel 1: Allocating RAM at 0x84020000 uninitialized
>>> > kernel 1 PANIC! kernel assertion "rck_get_coreid()
>>> == 0" failed at
>>> > ../kernel/arch/scc/rck.c:876
>>> > kernel 1: exception 3 (error code 0x0): breakpoint
>>> > On behalf of: monitor
>>> > Faulting instruction pointer (or following
>>> instruction): 0x8010a7bf
>>> > (0x 10a7bf in binary)
>>> > EAX 0x80118000 EBX 0x80116e88 ECX 0x0 EDX
>>> 0x805202c0 ESP 0x80920a08
>>> > Top o' stack:
>>> > 0x8010a7bf 0x2 0x8 0x10 0x3 0x0 0x8010a7bf 0x8 0x2
>>> 0x80520180
>>> > 0x80116e88 0x80920a44 0x8010c612 0x80116e88
>>> 0x210d6000 0x80920a64
>>> > 0x8010c64b 0x801164a0 0x80114c10 0x80114b55
>>> > No GDB backend
>>> > --------------- OUTPUT END
>>> ------------------------------
>>> >
>>> > As I see it, core 1 seems thought that it's the
>>> bsp core (while it's
>>> > not) so it's responsible to boot other cores. But
>>> I fail to see why
>>> > core 1 would think like that.
>>> >
>>> > Any ideas on this? Thanks in advance.
>>> >
>>> > Regards,
>>> > Jinghao
>>> >
>>> > FYI, this is my menu.lst.scc
>>> >
>>> > 1 timeout 0
>>> > 2
>>> > 3 # spawnd is used to control which cpus are booted
>>> > 4 #
>>> > 5 # "spawnd boot" will use the skb and pci to
>>> figure out and
>>> > 6 # boot all cores in the machine
>>> > 7 #
>>> > 8 # "spawnd boot bootscc=1-6" will not use the
>>> skb and
>>> > 9 # boot the list of cores passed as argument.
>>> > 10 # The hardware id of the cores to boot should
>>> be specified.
>>> > 11 # This list may not include the bsp core id.
>>> > 12
>>> > 13 title Barrelfish
>>> > 14 root (nd)
>>> > 15 kernel /scc/sbin/cpu loglevel=4
>>> > 16 module /scc/sbin/cpu
>>> > 17 module /scc/sbin/init
>>> > 18
>>> > 19 # Domains spawned by init
>>> > 20 module /scc/sbin/mem_serv
>>> > 21 module /scc/sbin/monitor
>>> > 22
>>> > 23 module /scc/sbin/chips boot
>>> > 24 module /scc/sbin/ramfsd boot
>>> > 25 module /scc/sbin/spawnd boot bootscc=0-1
>>> > 26 module /scc/sbin/startd boot
>>> > 27
>>> > 28 #module /scc/sbin/examples/xmpl-hello
>>> > 29
>>> > 30 # modules needed to start the networking
>>> > 31 # module /scc/sbin/eMAC core=0 device=2
>>> > 32 # module /scc/sbin/netd core=0 cardname=eMAC2_0
>>> > 33 # module /scc/sbin/eMAC core=1
>>> > 34 # module /scc/sbin/netd core=1 cardname=eMAC2_1
>>> > 35
>>> > 36 # Test for network throughput
>>> > 37 # module /scc/sbin/netthroughput core=1 /nfs
>>> > nfs://*MailScanner warning: numerical links are
>>> often malicious:* 10.110.4.41/shared
>>> <http://10.110.4.41/shared> <*MailScanner warning:
>>> numerical links are often malicious:*
>>> http://10.110.4.41/shared>
>>> > /nfs/pravin/testfile.txt
>>> > 38
>>> > 39 # For webserver
>>> > 40 # module /scc/sbin/webserver core=1 eMAC2_1
>>> 10.110.4.41
>>> > /shared/pravin/sw
>>> > 41
>>> > 42 # RCK memory map
>>> > 43 # Everything up til VGA is private RAM (maybe
>>> we want to throw it
>>> > away)
>>> > 44 mmap map 0x0 0xa000 2
>>> > 45 # Everything after VGA is private RAM (we also
>>> live in this area)
>>> > 46 mmap map 0xe800 0x26ff1800 1
>>> > 47 # Shared RAM (over all MCs) in the middle of
>>> address space
>>> > 48 #mmap map 0x80000000 0x4000000 1
>>> > 49 mmap map 0x80000000 0x40000000 1
>>> > 50 # At the very end we have some platform memory
>>> (bootup EEPROM)
>>> > 51 mmap map 0xfffc0000 0x40000 2
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Barrelfish-users mailing list
>>> > Barrelfish-users at lists.inf.ethz.ch
>>> <mailto:Barrelfish-users at lists.inf.ethz.ch>
>>> >
>>> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120422/ffc2681c/attachment.html
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Barrelfish-users mailing list
>>> Barrelfish-users at lists.inf.ethz.ch
>>> <mailto:Barrelfish-users at lists.inf.ethz.ch>
>>> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>>>
>>>
>>> End of Barrelfish-users Digest, Vol 27, Issue 9
>>> ***********************************************
>>>
>>>
>>
>>
>
> --
> Stefan
>
>
--
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20120428/16c04315/attachment-0001.html
More information about the Barrelfish-users
mailing list