Is this message normal or does it indicate a problem that needs to be
corrected?
INIT detected from {APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
Looking at the code this is emitted in model_fxx/init_cpus.c when
cpu_init_detectedx is non-zero.
Thanks,
Steve
--
On Fri, 2008-01-11 at 13:57 -0700, Marc Jones wrote:
This could indicate a real problem. It means that the core was
unexpectedly reset at some point. This is checked in cache_as_ram.inc.
Look for /* check if cpu_init_detected */.
Yes, as it turns out this is a real problem. The
I'm seeing the following during early initialization. Does anyone have a
suggestion for what to investigate?
I've moved to a new board (first proto). This has BSP to AP on BSP link
1 and AP to BSP on AP link 2.
(0,1) link=02
(1,0) link=01
02 nodes initialized.
core0 started: 01
01 02
On Thu, 2007-12-20 at 16:40 -0700, Myles Watson wrote:
I'm seeing delays between each of the following messages --
approximately 8 seconds. Is this normal?
Not for me on Tyan s2895 (Dual Opteron NVidia CK804.)
Myles
Thanks,
hhhmmm Looks like I've got a problem.
Steve
--
On Fri, 2007-12-21 at 14:15 -0700, Marc Jones wrote:
Try setting CONFIG_LOGICAL_CPUS 0 and see if that makes the delay go
away. I am going to assume that is where the problem is based on the
*01*0001 message is probably coming from wait_ap_started().
I'll give it a try. This
I'm seeing delays between each of the following messages --
approximately 8 seconds. Is this normal?
core0 started: 01
*01*0001
*02*0001
*03*0001
This is a dual opteron system.
Thanks,
Steve
--
linuxbios mailing list
linuxbios@linuxbios.org
On Thu, 2007-12-20 at 15:38 -0800, ron minnich wrote:
On Dec 20, 2007 3:30 PM, Steve Isaacs [EMAIL PROTECTED] wrote:
I'm seeing delays between each of the following messages --
approximately 8 seconds. Is this normal?
core0 started: 01
*01*0001
*02*0001
*03*0001
On Wed, 2007-12-19 at 11:17 +0100, Carl-Daniel Hailfinger wrote:
On 19.12.2007 01:35, Marc Jones wrote:
Steve Isaacs wrote:
AFAICS Steve is talking about SMBIOS, not SMI. SMBIOS is sort of an
asset management helper. With a chassis type, serial number and some
information about
On Wed, 2007-12-19 at 07:44 -0800, Steve Isaacs wrote:
On Wed, 2007-12-19 at 11:17 +0100, Carl-Daniel Hailfinger wrote:
On 19.12.2007 01:35, Marc Jones wrote:
Steve Isaacs wrote:
The requirement I'm struggling with is for our Linux based applications
to be able to identify
On Tue, 2007-12-18 at 17:05 -0800, ron minnich wrote:
Steve, I am afraid few people really understand all the ins and outs
of the cmos bits, and most don't really use them. We used them
somewhat at LANL, but the real usage was by linux networx on their
cluster nodes. I would say we used maybe
On Mon, 2007-12-10 at 17:32 -0700, Marc Jones wrote:
When I have seen a soft reset at this point it has been due to a memory
problem. Try simpler configurations and try putting some basic memory
test just before CAR is disabled. I would try on the interesting
boundaries. For example,
On Sun, 2007-12-09 at 10:15 -0800, ron minnich wrote:
On Dec 9, 2007 10:12 AM, Uwe Hermann [EMAIL PROTECTED] wrote:
You don't have the 19.* devices from lspci listed here; not sure what
those devices are, but I guess they must be listed.
They're cpu 1 northbridge I believe.
You're
On Sun, 2007-12-09 at 19:12 +0100, Uwe Hermann wrote:
On Wed, Dec 05, 2007 at 12:00:59PM -0800, Steve Isaacs wrote:
Is there anything that describes how to make a configuration in detail?
I'd rather learn the rules than have someone figure it out for me.
There's a PDF which describes some
On Sun, 2007-12-09 at 15:56 -0500, Tom Sylla wrote:
Steve Isaacs wrote:
chip southbridge/broadcom/bcm21000
device pci 0.0 on
end
device pci 1.0 off
end
device pci 2.0 on
end
device pci 3.0 off
On Sun, 2007-12-09 at 12:26 -0800, yhlu wrote:
whole boot log and your Options.lb in your MB dir ?
I just now realized that this might be what you wanted. This is the
output sent to the serial port during boot.
Steve
-
LinuxBIOS-2.0.0._apollo_Fallback OBJ--XX Mon Dec 10 11:19:06
On Mon, 2007-12-10 at 09:05 -0800, ron minnich wrote:
On Dec 10, 2007 7:51 AM, Steve Isaacs [EMAIL PROTECTED] wrote:
That's something I don't understand. What is essential and what is not?
Essential is needed to configure machine to load Linux. Which really
means that devices
On Mon, 2007-12-10 at 21:25 +0100, Uwe Hermann wrote:
On Mon, Dec 10, 2007 at 10:08:30AM -0800, Steve Isaacs wrote:
One thing that keeps tripping me is it appears that some device numbers
are 0 based and others are 1 based. For example 18.0 agrees with a PCI
bus scan as well as 19.0 but 6.0
On Mon, 2007-12-10 at 13:19 -0800, ron minnich wrote:
Your board is not working, and the best thing you can do is shrink
down Config.lb until it works.
I performed a series of experiments stripping the Config.lb none of
which fixed my issue. The process I followed was to comment out devices
I tried this config and it got this far (hangs after second SOFT_RESET):
LinuxBIOS-2.0.0._apollo_Fallback OBJ--XX Mon Dec 10 15:21:11 PST
2007 starting...
(0,1) link=01
(1,0) link=01
02 nodes initialized.
core0 started: 01
01 02 03SBLink=00
NC node|link=00
SMBus controller enabled
INIT
On Fri, 2007-12-07 at 20:11 +0100, Uwe Hermann wrote:
On Tue, Dec 04, 2007 at 10:59:21AM -0800, Steve Isaacs wrote:
I found these in mainboard/momentum/apache and am wondering if I can use
them as is for my board.
Where is this from? There's no such board in LinuxBIOS, AFAICS.
I
I was dealing with a strange first-time issue that would cause problems
on power on but appear fine after that. I'm working with a dual Opteron
board with two banks of DIMMs on separate I2C buses connected to a
pca9544 I2C mux.
This problem manifested itself as a series of no memory messages
On Wed, 2007-12-05 at 12:30 +0100, Uwe Hermann wrote:
Please post your Config.lb and 'lspci -tvnn' output.
You're likely listing PCI devices in Config.lb which are not on the
board, or you use the wrong nesting or order (?)
Thanks, see below.
I have been in a very uncomfortable position
When I look at the options passed to the compiler on the command line I
see the following:
-DCONFIG_MAX_CPUS='4' -DCONFIG_MAX_PHYSICAL_CPUS='2'
-DCONFIG_LOGICAL_CPUS='1'
Can someone help me understand what the difference between these is? I'm
working with two dual core opterons and this doesn't
Thanks.
On Tue, 2007-12-04 at 10:18 -0700, Marc Jones wrote:
CONFIG_MAX_CPUS : Saves space in the ACPI tables and additional stack
space for maximum possible number of cores in the system. Might be
better named as CONFIG_MAX_CPUs_CORES (AMD only)
CONFIG_MAX_PHYSICAL_CPUS: Used to set
I'm puzzled about the difference between these options. If I want to
boot using an IDE device does the following make sense?
## Boot linux from IDE
default CONFIG_IDE=1
default CONFIG_FS_STREAM=1
default CONFIG_FS_EXT2=1
default CONFIG_FS_ISO9660=1
default CONFIG_FS_FAT=1
default
I'm seeing this message during boot and have made several attempts and
modifying the Config.lb as the message suggests. Here's the tail of the
messages:
PCI: 00:09.0 [1166/0142] disabled
PCI: 00:0a.0 subbordinate bus PCI Express
PCI: 00:0a.0 [1166/0144] enabled
PCI: 00:0b.0 subbordinate bus PCI
On Fri, 2007-11-30 at 16:57 -0700, Jordan Crouse wrote:
On 30/11/07 15:29 -0800, Steve Isaacs wrote:
Is it a viable solution to have buildrom build a cross-tool chain? Imho:
This would be best in order to have repeatable results. Having config
options to control the gcc and binutils
On Mon, 2007-12-03 at 18:08 +0100, Peter Stuge wrote:
However - I want it to remain optional rather than a requirement,
so that the entry level stays as low as possible for as many as
possible.
I agree. A fully native build should be supported for when it's
appropriate and to keep the
On Mon, 2007-12-03 at 11:52 -0700, Jordan Crouse wrote:
I'm already on board with my opinion on a cross compiler, no need to rehash
that here.
But the thing about _this_ bug is that this can be fixed, and if you use
buildrom it _should_ be fixed. This is our fault, and we need to remedy it
On Mon, 2007-12-03 at 10:40 -0700, Jordan Crouse wrote:
You don't have to worry - as you can infer from the e-mail address, I am
keenly aware of the challenges that we have to face for commercial adoption.
It is one of my primary goals to ensure that LinuxBIOS becomes and stays
a viable
On Mon, 2007-12-03 at 13:19 -0700, Jordan Crouse wrote:
they happen. The problem is that LinuxBIOS compiler arguments are pretty
long, and its a pain to go through them all to figure out which files
don't have -fno-stack-protector attached to them. The best way to do it
is to figure out
On Mon, 2007-12-03 at 21:53 +0100, Stefan Reinauer wrote:
We already have all this: That's why I developed the LinuxBIOS test
system that started producing binary images at a central point:
http://qa.linuxbios.org/log_test.php?timestamp=20061109-173426device=epia-mvendor=viamanual=true
On Mon, 2007-12-03 at 22:45 +0100, Uwe Hermann wrote:
On Mon, Dec 03, 2007 at 10:36:51PM +0100, Stefan Reinauer wrote:
You can add the following lines to your
target/vendor/board/Config.lb:
option CC=i386-elf-gcc
# this one is CFLAGS.
option CPU_OPT=-O2 -Wl,...
option HOSTCC=gcc
When attempting to use buildrom I'm seeing the undefined reference to
`__stack_chk_fail' message. I see that this was a topic of discussion
back in January but haven't found anything to say how or if this was
resolved. At the risk of scratching an old itch I have to ask if this
was resolved or if
I'm working with a two dual core Opteron (2218HE) motherboard using a
new and currently unsupported chipset from Broadcom. During the early
startup I'm seeing the messages I've included below. I know I have
problems in my Config.lb for the board which is causing the complaint
about static devices
Jordan Crouse wrote:
Well, first and foremost, because the tiny kernel already knows how to do
I'm sorry, can someone enlighten me as to what a tiny kernel is? Is
that anything similar to this? http://www.selenic.com/linux-tiny/
Steve
--
linuxbios mailing list
linuxbios@linuxbios.org
36 matches
Mail list logo
