Solaris Express Community release refusing to install
Conor Svensson
start of the install Grub comes up, I select the default, the kernel
starts to load on the next screen, then another screen comes up & all
of a sudden the laptop reboots. The last screen is only up for less
than a second & pretty much the only work I've managed to make out is
"syncing" (presumably my file systems, which is obviously consistent
with a reboot being invoked). I've so far been unable to pause the
laptop on final screen for more detailed information.
An interesting point to note is the Solaris 10 FCS GUI installer is
launched without any hiccups on the same laptop.
Sorry if any of the above is slightly vague, I'm not in front of my
laptop at this precise moment.
Cheers in advance,
Conor
Eric Enright
> I'm trying to install Nevada build 16 on my Acer Aspire 5024, at the
> start of the install Grub comes up, I select the default, the kernel
> starts to load on the next screen, then another screen comes up & all
> of a sudden the laptop reboots. The last screen is only up for less
> than a second & pretty much the only work I've managed to make out is
> "syncing" (presumably my file systems, which is obviously consistent
> with a reboot being invoked). I've so far been unable to pause the
> laptop on final screen for more detailed information.
>
> An interesting point to note is the Solaris 10 FCS GUI installer is
> launched without any hiccups on the same laptop.
The exact same thing happens with my notebook as well, due to
what looks like an ACPI issue (there were some pretty major
ACPI changes since the last SX). You could try tweaking the
ACPI settings in your bios, if available.
To get a bit more information edit the grub boot parameters and
add "-k". I get this (in brief):
unix:die+a7
unix:trap+fc8
unix:_cmntrap+9a
pcplusmp:acpi_probe+13b
pcplusmp:apic_probe+59
unix:psm_install+31
unix:startup_end+a4
unix:startup+32
genunix:main+1b
I've got a bfu all ready and waiting on my server machine
for this notebook.. not much fun :-(
Eric
Rich Teer
> I'm trying to install Nevada build 16 on my Acer Aspire 5024, at the
> start of the install Grub comes up, I select the default, the kernel
> starts to load on the next screen, then another screen comes up & all
> of a sudden the laptop reboots. The last screen is only up for less
> than a second & pretty much the only work I've managed to make out is
Hmmm. It works OK on my Acer Ferrari 3400. Doesn't help much, but
at least its another data point.
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Joerg Schilling
Martin Bochnig <mbe...@cs.tu-berlin.de> wrote:
>
>kernel memory allocator: invalid free: buffer not in cache
> buffer=0 bufctl=0 cache: kmem_alloc_8
>
> panic[cpu0]/thread=fec1d960: kernel heap corruption detected
>
> genunix:kmem_error+3e6(3, db02c030, 0)
> genunix:kmem_free+a8 (0, 8)
> acpica:AcpiOsDeleteSemaphore+18 (0)
> acpica:AcpiUtDleteMutex+24 (0)
> acpica:AcpiUtMutexTerminate+c (fec33c70, fea4b219, )
> acpica:AcpiTerminate+d (0, fec9c650, fec33c)
> acpica:acpica_init+9b (fec39948,
> uppc:uppc_init_acpi+2b (...)
> uppc:uppc_softinit+17 ()
> ....
> unix:startup+32 ()
> genunix:main+1b ()
>
>There is a NULLPOINTER in the acpica module.
>
>Thanks to Juergen Keil!
Do you know where the problem is in the source?
Maybe I could fix this before I publish SchilliX.
I did already add 4 patches so far....
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Martin Bochnig
> On Wed, 15 Jun 2005, Conor Svensson wrote:
>
> > I'm trying to install Nevada build 16 on my Acer Aspire 5024, at the
> > start of the install Grub comes up, I select the default, the kernel
> > starts to load on the next screen, then another screen comes up & all
> > of a sudden the laptop reboots. The last screen is only up for less
> > than a second & pretty much the only work I've managed to make out is
>
> Hmmm. It works OK on my Acer Ferrari 3400. Doesn't help much, but
> at least its another data point.
Here is the solution / rather a workaround:
add "acpi-user-options=2" to GRUB's kernel command line (to the "-B" flag)
so that you get
kernel /boot/multiboot kernel/unix -B
install_media=cdrom,acpi-user-options=2
This one seems to be a known problem:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6283818
Initially I added "-kdvs" to the GRUB kernel line (boot with kmdb,
stop in Debugger, Verbose, Single-user).
Then - in the debugger - I booted with kernel heap checking, in kmdb type:
kmem_flags/W 0xf
... and then
:c
That way I got
kernel memory allocator: invalid free: buffer not in cache
buffer=0 bufctl=0 cache: kmem_alloc_8
panic[cpu0]/thread=fec1d960: kernel heap corruption detected
genunix:kmem_error+3e6(3, db02c030, 0)
genunix:kmem_free+a8 (0, 8)
acpica:AcpiOsDeleteSemaphore+18 (0)
acpica:AcpiUtDleteMutex+24 (0)
acpica:AcpiUtMutexTerminate+c (fec33c70, fea4b219, )
acpica:AcpiTerminate+d (0, fec9c650, fec33c)
acpica:acpica_init+9b (fec39948,
uppc:uppc_init_acpi+2b (...)
uppc:uppc_softinit+17 ()
....
unix:startup+32 ()
genunix:main+1b ()
There is a NULLPOINTER in the acpica module.
Thanks to Juergen Keil!
--
Best regards,
Martin Bochnig
Martin Bochnig
> In article <42B09B5E...@cs.tu-berlin.de>,
> Martin Bochnig <mbe...@cs.tu-berlin.de> wrote:
> >
> >kernel memory allocator: invalid free: buffer not in cache
> > buffer=0 bufctl=0 cache: kmem_alloc_8
> >
> > panic[cpu0]/thread=fec1d960: kernel heap corruption detected
> >
> > genunix:kmem_error+3e6(3, db02c030, 0)
> > genunix:kmem_free+a8 (0, 8)
> > acpica:AcpiOsDeleteSemaphore+18 (0)
> > acpica:AcpiUtDleteMutex+24 (0)
> > acpica:AcpiUtMutexTerminate+c (fec33c70, fea4b219, )
> > acpica:AcpiTerminate+d (0, fec9c650, fec33c)
> > acpica:acpica_init+9b (fec39948,
> > uppc:uppc_init_acpi+2b (...)
> > uppc:uppc_softinit+17 ()
> > ....
> > unix:startup+32 ()
> > genunix:main+1b ()
> >
> >There is a NULLPOINTER in the acpica module.
> >
> >Thanks to Juergen Keil!
>
> Do you know where the problem is in the source?
> Maybe I could fix this before I publish SchilliX.
> I did already add 4 patches so far....
>
The crash happens in usr/src/uts/common/os/cyclic.c, cyclic_add_xcall()
1582 ndx = cpu->cyp_heap[nelems];
1583 cyclic = &cpu->cyp_cyclics[ndx];
1584
1585 ASSERT(cyclic->cy_flags == CYF_FREE);
1586 cyclic->cy_interval = when->cyt_interval;
cpu->cyp_heap is a NULL Pointer. "ndx" is filled with any arbitrary value of
address 0, therefore also "cyclic" is another Pointer, pointing to an invalid
address, and then at the assignment
"cyclic->cy_interval = ..." is the end.
According to Juergen Keil, - cpu->cyp_heap in usr/src/uts/common/os/cyclic.c,
cyclic_configure()
should be set:
2096 cpu->cyp_size = 1;
2097 cpu->cyp_heap = kmem_zalloc(sizeof (cyc_index_t), KM_SLEEP);
But kmem_zalloc() returns a NULL Pointer despite KM_SLEEP !
- Then - when booting with "kmem_flags=0xf" (kernel heap checking) - the NULL
POINTER in
acpica can be detected:
kernel memory allocator: invalid free: buffer not in cache
buffer=0 bufctl=0 cache: kmem_alloc_8
panic[cpu0]/thread=fec1d960: kernel heap corruption detected
genunix:kmem_error+3e6(3, db02c030, 0)
genunix:kmem_free+a8 (0, 8)
acpica:AcpiOsDeleteSemaphore+18 (0)
acpica:AcpiUtDleteMutex+24 (0)
acpica:AcpiUtMutexTerminate+c (fec33c70, fea4b219, )
acpica:AcpiTerminate+d (0, fec9c650, fec33c)
acpica:acpica_init+9b (fec39948,
uppc:uppc_init_acpi+2b (...)
uppc:uppc_softinit+17 ()
....
unix:startup+32 ()
genunix:main+1b ()
I guess the reason is an incomplete implementation of ACPI on some hardware.
Properly initializing ACPI goes wrong, and before leaving the acpica module there
is a clean-up. Maybe a bit too thoroghly as it seems.
Under "OldBoot" "acpi-user-options=2" could be set in DCA, in order to ignore ACPI.
Now, in GRUB you have to modify the kernel command line in GRUB, so that you get
something like:
kernel /boot/multiboot kernel/unix -B install_media=cdrom,acpi-user-options=2
Thanks again to Juergen Keil for all his support!
Conor Svensson
workaround still brought about the same panic causing the system to
reboot. Using kmdb the error I recieve is identical to that quoted by
Martin. Any other suggestions wouuld be most gratefully received.
Cheers,
Conor
Eric Enright
acpi-user-options does nothing for me either; I worked around it
like this:
-boot kernel with "-kd"
-when the debugger comes up, set a breakpoint in pcplusmp::acpi_probe:
::bp pcplusmp`acpi_probe
:c
-when the breakpoint is hit, force acpi_probe to return by setting
apic_use_acpi to false:
apic_use_acpi/W 0
:c
-will hopefully boot normally here ;)
Oddly enough, the first reboot after the initial install did not
require this hack, but the one after that did.
Thanks to Juergen Keil for helping with all that.
HTH,
Eric
Eric Enright
Sorry, I meant to link to the relevant source as well!
http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/io/pcplusmp/apic.c#acpi_probe
Eric
Martin Bochnig
Mmmh, sorry.
I don't have the same machine as you do. Just a very similar issue.
However - "acpi-user-options=2" cannot be appended to the "kernel" line
on its own.
It belongs to the "-B" option.
Did you really specify ... "-B acpi-user-options=2" ?
Best,
Martin
Dan Foster
I think I read on one of the Sun blogs recently that for a recent Nevada
build with Newboot, they now prefer people using acpi-user-options=0x8.
http://blogs.sun.com/roller/page/danasblog/20050614#configuring_solaris_acpi_at_boot
I don't think Solaris Express has the change yet.
Other possible options would be to recompile your own fixed ACPI tables
and put the file in /boot/acpi/tables:
http://blogs.sun.com/roller/page/chewmyblog/20050614#an_antidote_to_acpi_table
-Dan
Andrew Gabriel
j...@cs.tu-berlin.de (Joerg Schilling) writes:
> In article <42B09B5E...@cs.tu-berlin.de>,
> Martin Bochnig <mbe...@cs.tu-berlin.de> wrote:
>>
>>kernel memory allocator: invalid free: buffer not in cache
>> buffer=0 bufctl=0 cache: kmem_alloc_8
>>
>> panic[cpu0]/thread=fec1d960: kernel heap corruption detected
>>
>> genunix:kmem_error+3e6(3, db02c030, 0)
>> genunix:kmem_free+a8 (0, 8)
>> acpica:AcpiOsDeleteSemaphore+18 (0)
>> acpica:AcpiUtDleteMutex+24 (0)
>> acpica:AcpiUtMutexTerminate+c (fec33c70, fea4b219, )
>> acpica:AcpiTerminate+d (0, fec9c650, fec33c)
>> acpica:acpica_init+9b (fec39948,
>> uppc:uppc_init_acpi+2b (...)
>> uppc:uppc_softinit+17 ()
>> ....
>> unix:startup+32 ()
>> genunix:main+1b ()
>>
>>There is a NULLPOINTER in the acpica module.
>>
>>Thanks to Juergen Keil!
>
> Do you know where the problem is in the source?
> Maybe I could fix this before I publish SchilliX.
> I did already add 4 patches so far....
The call to AcpiTerminate in acpica_init is an error path
when ACPI fails to initialise. There are several branches
to it in acpi_init, and the first two, and in some cases
the third, will result in AcpiTerminate being called before
the ACPI mutexs are initialised. This is probably what tips
it over, when AcpiTerminate deallocates the ACPI mutexs
which weren't ever allocated, including the associated
kernel memory.
At least, this is from my quick browse of the code.
--
Andrew Gabriel
Dana H. Myers
> Rich Teer wrote:
>
>
>>On Wed, 15 Jun 2005, Conor Svensson wrote:
>>
>>
>>>I'm trying to install Nevada build 16 on my Acer Aspire 5024, at the
>>>start of the install Grub comes up, I select the default, the kernel
>>>starts to load on the next screen, then another screen comes up & all
>>>of a sudden the laptop reboots. The last screen is only up for less
>>>than a second & pretty much the only work I've managed to make out is
>>
>>Hmmm. It works OK on my Acer Ferrari 3400. Doesn't help much, but
>>at least its another data point.
>
>
> Here is the solution / rather a workaround:
>
> add "acpi-user-options=2" to GRUB's kernel command line (to the "-B" flag)
> so that you get
I think you want to make sure it is:
acpi-user-options=0x2
> This one seems to be a known problem:
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6283818
[...]
> kernel memory allocator: invalid free: buffer not in cache
> buffer=0 bufctl=0 cache: kmem_alloc_8
>
> panic[cpu0]/thread=fec1d960: kernel heap corruption detected
>
> genunix:kmem_error+3e6(3, db02c030, 0)
> genunix:kmem_free+a8 (0, 8)
> acpica:AcpiOsDeleteSemaphore+18 (0)
> acpica:AcpiUtDleteMutex+24 (0)
> acpica:AcpiUtMutexTerminate+c (fec33c70, fea4b219, )
> acpica:AcpiTerminate+d (0, fec9c650, fec33c)
> acpica:acpica_init+9b (fec39948,
> uppc:uppc_init_acpi+2b (...)
> uppc:uppc_softinit+17 ()
> ....
> unix:startup+32 ()
> genunix:main+1b ()
>
> There is a NULLPOINTER in the acpica module.
This problem happens acpica_init() can not successfully initialize
ACPI CA, almost certainly because AcpiLoadTables() can't find an
ACPI table because the system either doesn't have an ACPI BIOS or has
ACPI disabled in the BIOS setup. If your system BIOS supports ACPI,
make sure it's turned on in the system BIOS.
If your BIOS does not support ACPI, or you're still seeing this
problem, then acpi-user-options=0x2 should work-around this issue
with no loss of functionality.
The root-cause of this problem is that I'd included a call to
AcpiTerminate() in the error tail of acpica_init(); in a system
with no ACPI BIOS, acpica_init() will be called at least 3 times,
fail each time, and call AcpiTerminate() each time.
AcpiTerminate() percolates down to AcpiiUtMutexTerminate(),
which unconditionally calls AcpiOsDeleteLock(AcpiGbl_GpeLock);
AcpiGbl_GpeLock is set up as a result of AcpiIntializeSubsystem()
- which is only called once when the acpica module is first loaded.
Note that this is not a problem with deleteing mutexes before
they're set-up - it's a problem with multiple deletions of the
same mutex.
The correct fix for this is to simply remove the call
to AcpiTerminate() in acpica_init(); my thinking about
calling it under all error cases was clearly mistaken.
I have a fix in hand, under testing for this, and will be integrating
it along with an update to the latest ACPI CA source release from Intel
in the next week or so.
Thanks to Andrew Gabriel for mentioning this thread to me. I'm
sorry this snuck out in the Community release before we found it!
Cheers,
Dana
Dana H. Myers
> In article <1118878036.8...@f14g2000cwb.googlegroups.com>, Conor Svensson <conor.s...@evolution.net> wrote:
>
>>Unfortunately I'm still having no joy. using the acpi-user-options=2
>>workaround still brought about the same panic causing the system to
>>reboot. Using kmdb the error I recieve is identical to that quoted by
>>Martin. Any other suggestions wouuld be most gratefully received.
>
>
> I think I read on one of the Sun blogs recently that for a recent Nevada
> build with Newboot, they now prefer people using acpi-user-options=0x8.
>
> http://blogs.sun.com/roller/page/danasblog/20050614#configuring_solaris_acpi_at_boot
>
> I don't think Solaris Express has the change yet.
In this case, acpi-user-options=0x8 won't help.
> Other possible options would be to recompile your own fixed ACPI tables
> and put the file in /boot/acpi/tables:
>
> http://blogs.sun.com/roller/page/chewmyblog/20050614#an_antidote_to_acpi_table
Right; but is this a case of broken ACPI tables or no ACPI tables at all?
Dana
Juergen Keil
> Right; but is this a case of broken ACPI tables or no ACPI tables at all?
For me it was a case of no ACPI tables.
AcpiOsGetRootPointer() returned with an error code
http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/io/acpica/osl.c#AcpiOsGetRootPointer
This error code is returned from AcpiLoadTables()
http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/io/acpica/tables/tbxface.c#AcpiLoadTables
The error returned from AcpiLoadTables() force a jump to the
error label in acpica_init(), which calls AcpiTerminate().
http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/io/acpica/acpica.c#acpica_init
The AcpiTerminate() cleanup works OK for the first call to
acpica_init(), but for subsequent calls to acpica_init() the
kernel's heap will be corrupted due to a kmem_free(NULL, 8).
The kernel will crash soon after the heap is corrupted.
For some reason, kmdb is unable to catch the fault - the system
immediatelly reboots.
The orignal poster (Conor Svensson) might have a different issue,
though, because he mentions "syncing", which appears to be a hint that
the system has reported some sort of panic (maybe with a stack
backtrace?) and is trying to sync filesystems before the reboot.
And Eric Enright's machine appears to have a different problem,
with a panic at pcplusmp:acpi_probe+13b
Joerg Schilling
Dana H. Myers <dana....@gmail.com> wrote:
>If your BIOS does not support ACPI, or you're still seeing this
>problem, then acpi-user-options=0x2 should work-around this issue
>with no loss of functionality.
>
>The root-cause of this problem is that I'd included a call to
>AcpiTerminate() in the error tail of acpica_init(); in a system
>with no ACPI BIOS, acpica_init() will be called at least 3 times,
>fail each time, and call AcpiTerminate() each time.
>
>AcpiTerminate() percolates down to AcpiiUtMutexTerminate(),
>which unconditionally calls AcpiOsDeleteLock(AcpiGbl_GpeLock);
>AcpiGbl_GpeLock is set up as a result of AcpiIntializeSubsystem()
>- which is only called once when the acpica module is first loaded.
>
>Note that this is not a problem with deleteing mutexes before
>they're set-up - it's a problem with multiple deletions of the
>same mutex.
>
>The correct fix for this is to simply remove the call
>to AcpiTerminate() in acpica_init(); my thinking about
>calling it under all error cases was clearly mistaken.
Does this mean, it would be a good idea to just remove the
call to AcpiTerminate() in acpica_init() ?
Note that I like to publish my OpenSolaris distribution
tomorrow and would like to have a fix before.
Dana H. Myers
>>The correct fix for this is to simply remove the call
>>to AcpiTerminate() in acpica_init(); my thinking about
>>calling it under all error cases was clearly mistaken.
>
>
> Does this mean, it would be a good idea to just remove the
> call to AcpiTerminate() in acpica_init() ?
>
> Note that I like to publish my OpenSolaris distribution
> tomorrow and would like to have a fix before.
That's the fix I'm integrating. I believe it has very low
risk of regression, and if you (and anyone else in the
community) would like to try the fix and email off-list
with results and machines tested on, that'd be of great
value.
Thanks!
Dana
Dana H. Myers
> "Dana H. Myers" <dana....@gmail.com> writes:
>
>
>
>>Right; but is this a case of broken ACPI tables or no ACPI tables at all?
>
>
> For me it was a case of no ACPI tables.
Presumably acpi-user-options=0x2 addresses this as a
workaround?
[Multiple calls to AcpiTerminate() are bad; I'm fixing it]
> The orignal poster (Conor Svensson) might have a different issue,
> though, because he mentions "syncing", which appears to be a hint that
> the system has reported some sort of panic (maybe with a stack
> backtrace?) and is trying to sync filesystems before the reboot.
Indeed; Conor - could you email me offlist and let's see what's cooking?
> And Eric Enright's machine appears to have a different problem,
> with a panic at pcplusmp:acpi_probe+13b
Thanks -
Dana
Juergen Keil
> Juergen Keil wrote:
>> "Dana H. Myers" <dana....@gmail.com> writes:
>>
>>>Right; but is this a case of broken ACPI tables or no ACPI tables at all?
>>
>> For me it was a case of no ACPI tables.
>
> Presumably acpi-user-options=0x2 addresses this as a
> workaround?
Yep.
Dana H. Myers
I suspect this problem is pcplusmp tripping over an unused
entry in the ACPI MADT table of the system. Eric, are you
familiar with "iasl -g" ?
What specific kind of machine are you using?
Dana
Dana H. Myers
Once you've installed, to make this work-around permanent until
I get this diagnosed and fixed, you can add:
set pcplusmp:apic_use_acpi=1
to /etc/system
Thanks -
Dana
Dana H. Myers
[Panic booting NV16 on Toshiba Satellite A30 with the following
signature backtrace]
> unix:die+a7
> unix:trap+fc8
> unix:_cmntrap+9a
> pcplusmp:acpi_probe+13b
> pcplusmp:apic_probe+59
> unix:psm_install+31
> unix:startup_end+a4
> unix:startup+32
> genunix:main+1b
This has been root-caused; there's a bug open at:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6288486
(in summary, the Studio compilers and gcc differ in bit-field
behavior and ACPI CA trips over this; working on a solution)
and the work-around is:
-boot kernel with "-kd"
-when the debugger comes up, set a breakpoint in pcplusmp::acpi_probe:
::bp pcplusmp`acpi_probe
:c
-when the breakpoint is hit, force acpi_probe to return by setting
apic_use_acpi to false:
apic_use_acpi/W 0
:c
Thanks to Eric for posting the above workaround and helping me
investigate this.
Dana