Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2020-03-22 Thread Andrey Fesenko 
On Thu, Nov 28, 2019 at 11:31 PM Toomas Soome  wrote:
>
> > On 28. Nov 2019, at 22:20, Andrey Fesenko  wrote:
> >
> > Fixed
> >
>
> Thanks. And yea, that one is nasty. I have some guess but nothing too solid… 
> it may take time to get figured out.
>
> Have you tested BIOS boot?
>
> rgds,
> toomas
>
> > On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
> >>
> >>
> >>
> >> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
> >>
> >> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
> >>
> >>
> >> hi!
> >>
> >> I did try to reach you, but mail did bounce back…
> >>
> >> unicast ping me:)
> >>
> >> rgds,
> >> toomas
> >>
> >> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> >>
> >> Hello,
> >>
> >> Around starting 20191114 r354699 (memstick tested), my desktop not
> >> boot normally. Boot only loader menu (black and white mode) after
> >> start i'm see load modules, after this monitor gray, and 15-20s
> >> disabled, system block not disable but run silently. system not boot.
> >>
> >> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> >> release, system boot normally
> >>
> >>
> >>
> >> This video boot second version (Name: "loader.efi") 545 KB
> >> https://bsdnir.info/files/efi_fail.mp4
> >>
> >>
> >> 403 Forbidden
> >>
> >> :=)
> >>
> >> rgds,
> >> toomas
>

New news ;)

r359151 i'm make memstick with custom refind
/mnt/
`-- EFI
|-- BOOT
|   |-- bootx64.efi - refind
|-- freebsd
|   `-- loader.efi  - freebsd not boot
|-- freebsd_lua
|   `-- loader_lua.efi - not boot
|-- freebsd_simple
|   `-- loader_simp.efi - boot fine
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Andrey Fesenko 
On Thu, Nov 28, 2019 at 11:31 PM Toomas Soome  wrote:
>
>
>
> > On 28. Nov 2019, at 22:20, Andrey Fesenko  wrote:
> >
> > Fixed
> >
>
> Thanks. And yea, that one is nasty. I have some guess but nothing too solid… 
> it may take time to get figured out.
>
> Have you tested BIOS boot?
>
> rgds,
> toomas
>
> > On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
> >>
> >>
> >>
> >> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
> >>
> >> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
> >>
> >>
> >> hi!
> >>
> >> I did try to reach you, but mail did bounce back…
> >>
> >> unicast ping me:)
> >>
> >> rgds,
> >> toomas
> >>
> >> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> >>
> >> Hello,
> >>
> >> Around starting 20191114 r354699 (memstick tested), my desktop not
> >> boot normally. Boot only loader menu (black and white mode) after
> >> start i'm see load modules, after this monitor gray, and 15-20s
> >> disabled, system block not disable but run silently. system not boot.
> >>
> >> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> >> release, system boot normally
> >>
> >>
> >>
> >> This video boot second version (Name: "loader.efi") 545 KB
> >> https://bsdnir.info/files/efi_fail.mp4
> >>
> >>
> >> 403 Forbidden
> >>
> >> :=)
> >>
> >> rgds,
> >> toomas
>

BIOS boot fine, loader colored, installer start normal.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Toomas Soome 


> On 28. Nov 2019, at 22:20, Andrey Fesenko  wrote:
> 
> Fixed
> 

Thanks. And yea, that one is nasty. I have some guess but nothing too solid… it 
may take time to get figured out.

Have you tested BIOS boot?

rgds,
toomas

> On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
>> 
>> 
>> 
>> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
>> 
>> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
>> 
>> 
>> hi!
>> 
>> I did try to reach you, but mail did bounce back…
>> 
>> unicast ping me:)
>> 
>> rgds,
>> toomas
>> 
>> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
>> 
>> Hello,
>> 
>> Around starting 20191114 r354699 (memstick tested), my desktop not
>> boot normally. Boot only loader menu (black and white mode) after
>> start i'm see load modules, after this monitor gray, and 15-20s
>> disabled, system block not disable but run silently. system not boot.
>> 
>> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
>> release, system boot normally
>> 
>> 
>> 
>> This video boot second version (Name: "loader.efi") 545 KB
>> https://bsdnir.info/files/efi_fail.mp4
>> 
>> 
>> 403 Forbidden
>> 
>> :=)
>> 
>> rgds,
>> toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Andrey Fesenko 
Fixed

On Thu, Nov 28, 2019 at 11:18 PM Toomas Soome  wrote:
>
>
>
> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
>
> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
>
>
> hi!
>
> I did try to reach you, but mail did bounce back…
>
> unicast ping me:)
>
> rgds,
> toomas
>
> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
>
> Hello,
>
> Around starting 20191114 r354699 (memstick tested), my desktop not
> boot normally. Boot only loader menu (black and white mode) after
> start i'm see load modules, after this monitor gray, and 15-20s
> disabled, system block not disable but run silently. system not boot.
>
> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> release, system boot normally
>
>
>
> This video boot second version (Name: "loader.efi") 545 KB
> https://bsdnir.info/files/efi_fail.mp4
>
>
> 403 Forbidden
>
> :=)
>
> rgds,
> toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Toomas Soome 


> On 28. Nov 2019, at 22:16, Andrey Fesenko  wrote:
> 
> On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  > wrote:
>> 
>> hi!
>> 
>> I did try to reach you, but mail did bounce back…
>> 
>> unicast ping me:)
>> 
>> rgds,
>> toomas
>> 
>>> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
>>> 
>>> Hello,
>>> 
>>> Around starting 20191114 r354699 (memstick tested), my desktop not
>>> boot normally. Boot only loader menu (black and white mode) after
>>> start i'm see load modules, after this monitor gray, and 15-20s
>>> disabled, system block not disable but run silently. system not boot.
>>> 
>>> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
>>> release, system boot normally
>>> 
>> 
> 
> This video boot second version (Name: "loader.efi") 545 KB
> https://bsdnir.info/files/efi_fail.mp4 
> 

403 Forbidden

:=)

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Andrey Fesenko 
On Thu, Nov 28, 2019 at 9:20 PM Andrey Fesenko  wrote:
>
> On Thu, Nov 28, 2019 at 1:24 PM Eugene Grosbein  wrote:
> >
> > 28.11.2019 16:43, Andrey Fesenko wrote:
> >
> > > Hello,
> > >
> > > Around starting 20191114 r354699 (memstick tested), my desktop not
> > > boot normally. Boot only loader menu (black and white mode) after
> > > start i'm see load modules, after this monitor gray, and 15-20s
> > > disabled, system block not disable but run silently. system not boot.
> >
> > So loader works. Try breaking to loader prompt and do:
> >
> > set hw.vga.acpi_ignore_no_vga=1
> > boot
> >
>
> Hm new test, new problems. Old and new efi, if breaking to loader
> prompt work only alphabet keys, nums not work :) (on notebook loader
> work fine)
> If make
> echo 'hw.vga.acpi_ignore_no_vga=1' > /boot/loader.conf
>
> on flash, and reboot, not fix boot.

Correction number and underline work, but set
hw.vga.acpi_ignore_no_vga not fix boot
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Andrey Fesenko 
On Thu, Nov 28, 2019 at 3:03 PM Toomas Soome  wrote:
>
> hi!
>
> I did try to reach you, but mail did bounce back…
>
> unicast ping me:)
>
> rgds,
> toomas
>
> > On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> >
> > Hello,
> >
> > Around starting 20191114 r354699 (memstick tested), my desktop not
> > boot normally. Boot only loader menu (black and white mode) after
> > start i'm see load modules, after this monitor gray, and 15-20s
> > disabled, system block not disable but run silently. system not boot.
> >
> > If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> > release, system boot normally
> >
>

This video boot second version (Name: "loader.efi") 545 KB
https://bsdnir.info/files/efi_fail.mp4
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Andrey Fesenko 
On Thu, Nov 28, 2019 at 1:24 PM Eugene Grosbein  wrote:
>
> 28.11.2019 16:43, Andrey Fesenko wrote:
>
> > Hello,
> >
> > Around starting 20191114 r354699 (memstick tested), my desktop not
> > boot normally. Boot only loader menu (black and white mode) after
> > start i'm see load modules, after this monitor gray, and 15-20s
> > disabled, system block not disable but run silently. system not boot.
>
> So loader works. Try breaking to loader prompt and do:
>
> set hw.vga.acpi_ignore_no_vga=1
> boot
>

Hm new test, new problems. Old and new efi, if breaking to loader
prompt work only alphabet keys, nums not work :) (on notebook loader
work fine)
If make
echo 'hw.vga.acpi_ignore_no_vga=1' > /boot/loader.conf

on flash, and reboot, not fix boot.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Toomas Soome 
hi!

I did try to reach you, but mail did bounce back…

unicast ping me:)

rgds,
toomas

> On 28. Nov 2019, at 11:43, Andrey Fesenko  wrote:
> 
> Hello,
> 
> Around starting 20191114 r354699 (memstick tested), my desktop not
> boot normally. Boot only loader menu (black and white mode) after
> start i'm see load modules, after this monitor gray, and 15-20s
> disabled, system block not disable but run silently. system not boot.
> 
> If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
> release, system boot normally
> 
> My notebook x220 work fine any loaders.
> 
> desktop
> BIOS Information
>Vendor: American Megatrends Inc.
>Version: F2
>Release Date: 05/03/2013
>Address: 0xF
>Runtime Size: 64 kB
>ROM Size: 16 MB
>Characteristics:
>PCI is supported
>BIOS is upgradeable
>BIOS shadowing is allowed
>Boot from CD is supported
>Selectable boot is supported
>BIOS ROM is socketed
>EDD is supported
>5.25"/1.2 MB floppy services are supported (int 13h)
>3.5"/720 kB floppy services are supported (int 13h)
>3.5"/2.88 MB floppy services are supported (int 13h)
>Print screen service is supported (int 5h)
>8042 keyboard services are supported (int 9h)
>Serial services are supported (int 14h)
>Printer services are supported (int 17h)
>ACPI is supported
>USB legacy is supported
>BIOS boot specification is supported
>Targeted content distribution is supported
>UEFI is supported
>BIOS Revision: 4.6
> 
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
>Manufacturer: Gigabyte Technology Co., Ltd.
>Product Name: Z87MX-D3H
>Version: To be filled by O.E.M.
>Serial Number: To be filled by O.E.M.
>UUID: 03de0294-0480-057d-0c06-7a0700080009
>Wake-up Type: Power Switch
>SKU Number: To be filled by O.E.M.
>Family: To be filled by O.E.M.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

EFI loader failure, after 20191114-r354699 Z87MX-D3H

2019-11-28 Thread Andrey Fesenko 
Hello,

Around starting 20191114 r354699 (memstick tested), my desktop not
boot normally. Boot only loader menu (black and white mode) after
start i'm see load modules, after this monitor gray, and 15-20s
disabled, system block not disable but run silently. system not boot.

If i'm change efi  (EFI/BOOT/bootx64.efi), 20191031-r354207 or 12.1
release, system boot normally

My notebook x220 work fine any loaders.

desktop
BIOS Information
Vendor: American Megatrends Inc.
Version: F2
Release Date: 05/03/2013
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: Z87MX-D3H
Version: To be filled by O.E.M.
Serial Number: To be filled by O.E.M.
UUID: 03de0294-0480-057d-0c06-7a0700080009
Wake-up Type: Power Switch
SKU Number: To be filled by O.E.M.
Family: To be filled by O.E.M.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lua Loader Failure to Include

2019-02-11 Thread Kyle Evans 
On Mon, Feb 11, 2019 at 9:14 AM Cy Schubert  wrote:
>
> On February 11, 2019 5:05:37 AM PST, Cy Schubert  
> wrote:
> >Hi,
> >
> >Under the old Forth loader the line:
> >
> >   include /boot/testbed/test_sys
> >
> >would load the file and execute loader commands.
> >
> >However the the Lua loader results in the following:
> >
> >OK include /boot/testbed/amd64-current-r
> >no error message
> >OK
> >
> >Looking at the code, interp_include() expects to run actual Lua code
> >using luaL_dofile(). Is this an intended change?
> >
> >The loader statements the file above is intending to execute are:
> >
> >echo
> >echo
> >echo testbed/amd64-current-r (12.0-CURRENT) loader file selected
> >set bootdev=disk1s4a:
> >include /boot/testbed/current.hints
> >include /boot/testbed/do_load_KOMQUATS
> >
> >Let me know if I am to rewrite these loader statements into Lua or
> >whether the Lua loader should be taught to read loader statements
> >instead.
>
> Thinking about this while travelling to $JOB, it's probably best to leave it 
> as is. I'll rewrite the includes into Lua. The benefit is greater flexibility 
> and functionality.
>

Indeed, this is the best course of action. The translation shouldn't
be too hard -- the main caveat to note is that your current.hints
include likely can't be required in directly, you'll need to run it
through config.load(). I intend to write up a wiki page or something
for converting common Forth-isms to either portable loader.conf(5)
directives or Lua-specific equivalents, depending on the feasibility
of the former.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lua Loader Failure to Include

2019-02-11 Thread Cy Schubert 
On February 11, 2019 5:05:37 AM PST, Cy Schubert  
wrote:
>Hi,
>
>Under the old Forth loader the line:
>
>   include /boot/testbed/test_sys
>
>would load the file and execute loader commands.
>
>However the the Lua loader results in the following:
>
>OK include /boot/testbed/amd64-current-r
>no error message
>OK
>
>Looking at the code, interp_include() expects to run actual Lua code 
>using luaL_dofile(). Is this an intended change?
>
>The loader statements the file above is intending to execute are:
>
>echo
>echo 
>echo testbed/amd64-current-r (12.0-CURRENT) loader file selected
>set bootdev=disk1s4a:
>include /boot/testbed/current.hints
>include /boot/testbed/do_load_KOMQUATS
>
>Let me know if I am to rewrite these loader statements into Lua or 
>whether the Lua loader should be taught to read loader statements 
>instead.

Thinking about this while travelling to $JOB, it's probably best to leave it as 
is. I'll rewrite the includes into Lua. The benefit is greater flexibility and 
functionality.

-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert 
FreeBSD UNIX:  Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Lua Loader Failure to Include

2019-02-11 Thread Cy Schubert 
Hi,

Under the old Forth loader the line:

include /boot/testbed/test_sys

would load the file and execute loader commands.

However the the Lua loader results in the following:

OK include /boot/testbed/amd64-current-r
no error message
OK

Looking at the code, interp_include() expects to run actual Lua code 
using luaL_dofile(). Is this an intended change?

The loader statements the file above is intending to execute are:

echo
echo 
echo testbed/amd64-current-r (12.0-CURRENT) loader file selected
set bootdev=disk1s4a:
include /boot/testbed/current.hints
include /boot/testbed/do_load_KOMQUATS

Let me know if I am to rewrite these loader statements into Lua or 
whether the Lua loader should be taught to read loader statements 
instead.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loader failure

2002-05-16 Thread Bruce Evans 

On Wed, 15 May 2002, John Baldwin wrote:

 On 15-May-2002 Dag-Erling Smorgrav wrote:
  John Baldwin [EMAIL PROTECTED] writes:
  The kernel overflowed it's stack.  In SRM, you can try to debug this
  by using 'e sp' to get the stack pointer then get a stack dump and save
  a copy of it in a log or something, reboot the machine, then use gdb's
  list command on the kernel.debug to figure out the source:line for all
  the kernel-text addresses in the stack dump to figure out the backtrace.
 
  How do I get a stack trace? I can't get the 'examine' command to
  actually print anything...

 It depends on which machine actually. :-/  First do 'e sp' to get the
 stack pointer.  Then you want to do something like this:

 e -n 100 value of sp without any leading 0x

At least for i386's, it can be useful to set $esp and $eip to
non-preposterous values if they are hosed (record the old values first).
Bugs in the pagefault handler make the behaviour for invalid pointers
very bad.  The main one trap_pfault() doesn't give up immediately if
the pagefault is from within ddb.  In old versions of FreeBSD, this is
probably only fatal if trap_pfault() blocks, but in -current is is fatal
in the usual case where trap_fault() acquires a sleep lock.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

loader failure

2002-05-15 Thread Dag-Erling Smorgrav 

Trying to boot with a newly-built loader (make world earlier today
from fresh sources) results in:

FreeBSD/alpha SRM disk boot, Revision 1.2
([EMAIL PROTECTED], Wed May 15 08:01:43 CEST 2002)
Memory: 262144 k
Loading /boot/defaults/loader.conf
/boot/kernel/kernel data=0x283780+0x63670 /

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Entering /boot/kernel/kernel at 0xfc32e740...

halted CPU 0

halt code = 2
kernel stack not valid halt
PC = 2
boot failure

no matter which kernel I try to boot.  Booting my new kernel with the
old loader (from the DP1 dist) works fine until it tries to start
init(8):

spec_getpages: preposterous offset 0xfff8f446
exec /sbin/init: error 5
spec_getpages: preposterous offset 0xfff81426c000
exec /sbin/init.bak: error 5
spec_getpages: preposterous offset 0xfff8c86c
exec /stand/sysinstall: error 5
init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
panic: no init
panic
Stopped at  Debugger+0x34:  zapnot  v0,#0xf,v0  v0=0x0

Booting DP1's GENERIC with the old loader and the new userland works
fine.

Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts
as funny stuff)

guess type=wildThe loader problem is possibly a compiler issue
(since DP1 was built with gcc 2.95 while my world was built with 3.1).
The init problem is probably a UFS2 f*up; the code has obviously not
been tested on a 64-bit architecture (the UFS2 stuff broke the kernel
build)./guess

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: loader failure

2002-05-15 Thread John Baldwin 


On 15-May-2002 Dag-Erling Smorgrav wrote:
 Trying to boot with a newly-built loader (make world earlier today
 from fresh sources) results in:
 
 FreeBSD/alpha SRM disk boot, Revision 1.2
 ([EMAIL PROTECTED], Wed May 15 08:01:43 CEST 2002)
 Memory: 262144 k
 Loading /boot/defaults/loader.conf
 /boot/kernel/kernel data=0x283780+0x63670 /
 
 Hit [Enter] to boot immediately, or any other key for command prompt.
 Booting [/boot/kernel/kernel]...
 Entering /boot/kernel/kernel at 0xfc32e740...
 
 halted CPU 0
 
 halt code = 2
 kernel stack not valid halt
 PC = 2
 boot failure
 
 no matter which kernel I try to boot.  Booting my new kernel with the
 old loader (from the DP1 dist) works fine until it tries to start
 init(8):
 
 spec_getpages: preposterous offset 0xfff8f446
 exec /sbin/init: error 5
 spec_getpages: preposterous offset 0xfff81426c000
 exec /sbin/init.bak: error 5
 spec_getpages: preposterous offset 0xfff8c86c
 exec /stand/sysinstall: error 5
 init: not found in path
 /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
 panic: no init
 panic
 Stopped at  Debugger+0x34:  zapnot  v0,#0xf,v0  v0=0x0
 
 Booting DP1's GENERIC with the old loader and the new userland works
 fine.
 
 Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts
 as funny stuff)
 
 guess type=wildThe loader problem is possibly a compiler issue
 (since DP1 was built with gcc 2.95 while my world was built with 3.1).
 The init problem is probably a UFS2 f*up; the code has obviously not
 been tested on a 64-bit architecture (the UFS2 stuff broke the kernel
 build)./guess

The kernel overflowed it's stack.  In SRM, you can try to debug this
by using 'e sp' to get the stack pointer then get a stack dump and save
a copy of it in a log or something, reboot the machine, then use gdb's
list command on the kernel.debug to figure out the source:line for all
the kernel-text addresses in the stack dump to figure out the backtrace.
From that you can figure out where the recursion is happening and fix it.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Andrew Gallatin 


Dag-Erling Smorgrav writes:
  Trying to boot with a newly-built loader (make world earlier today
  from fresh sources) results in:
..
  boot failure
  
  no matter which kernel I try to boot.  Booting my new kernel with the
  old loader (from the DP1 dist) works fine until it tries to start
  init(8):
..
  guess type=wildThe loader problem is possibly a compiler issue
  (since DP1 was built with gcc 2.95 while my world was built with 3.1).
  The init problem is probably a UFS2 f*up; the code has obviously not
  been tested on a 64-bit architecture (the UFS2 stuff broke the kernel
  build)./guess

My 2 cents - the kernel  world (including loader) were fine as of
Friday (both built with gcc3, modulo the atomic fixes for vm_object.c
that jhb / alc / jeff came up with on Saturday).

Drew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Bernd Walter 

On Wed, May 15, 2002 at 02:22:04PM +0200, Dag-Erling Smorgrav wrote:
 Trying to boot with a newly-built loader (make world earlier today
 from fresh sources) results in:
 
 FreeBSD/alpha SRM disk boot, Revision 1.2
 ([EMAIL PROTECTED], Wed May 15 08:01:43 CEST 2002)
 Memory: 262144 k
 Loading /boot/defaults/loader.conf
 /boot/kernel/kernel data=0x283780+0x63670 /
 
 Hit [Enter] to boot immediately, or any other key for command prompt.
 Booting [/boot/kernel/kernel]...
 Entering /boot/kernel/kernel at 0xfc32e740...
 
 halted CPU 0
 
 halt code = 2
 kernel stack not valid halt
 PC = 2
 boot failure
 
 no matter which kernel I try to boot.  Booting my new kernel with the
 old loader (from the DP1 dist) works fine until it tries to start
 init(8):
 
 spec_getpages: preposterous offset 0xfff8f446
 exec /sbin/init: error 5
 spec_getpages: preposterous offset 0xfff81426c000
 exec /sbin/init.bak: error 5
 spec_getpages: preposterous offset 0xfff8c86c
 exec /stand/sysinstall: error 5
 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
 panic: no init
 panic
 Stopped at  Debugger+0x34:  zapnot  v0,#0xf,v0  v0=0x0
 
 Booting DP1's GENERIC with the old loader and the new userland works
 fine.
 
 Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts
 as funny stuff)

I'm running 11th May -current with ev4 on NoName and since yesterday
with ev56 on PC164.
No problems with /boot/loader.

On the PC164 I had an dup alloc ufs panic yesterday :(
The filesystem was checked with fsck -y directly after updating.
Debugging options in kernel were disabled.

 guess type=wildThe loader problem is possibly a compiler issue
 (since DP1 was built with gcc 2.95 while my world was built with 3.1).
 The init problem is probably a UFS2 f*up; the code has obviously not
 been tested on a 64-bit architecture (the UFS2 stuff broke the kernel
 build)./guess

Some UFS2 preparation parts were commited after I checked out my
source, IIRC also a part influencing loader.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Dag-Erling Smorgrav 

John Baldwin [EMAIL PROTECTED] writes:
 The kernel overflowed it's stack.  In SRM, you can try to debug this
 by using 'e sp' to get the stack pointer then get a stack dump and save
 a copy of it in a log or something, reboot the machine, then use gdb's
 list command on the kernel.debug to figure out the source:line for all
 the kernel-text addresses in the stack dump to figure out the backtrace.

How do I get a stack trace? I can't get the 'examine' command to
actually print anything...

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Brian Somers 

  no matter which kernel I try to boot.  Booting my new kernel with the
  old loader (from the DP1 dist) works fine until it tries to start
  init(8):
  
  spec_getpages: preposterous offset 0xfff8f446
  exec /sbin/init: error 5
  spec_getpages: preposterous offset 0xfff81426c000
  exec /sbin/init.bak: error 5
  spec_getpages: preposterous offset 0xfff8c86c
  exec /stand/sysinstall: error 5
  init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
  panic: no init
  panic
  Stopped at  Debugger+0x34:  zapnot  v0,#0xf,v0  v0=0x0
  
  Booting DP1's GENERIC with the old loader and the new userland works
  fine.
  
  Clean tree, no funny stuff in make.conf (unless 'CPUTYPE?=ev56' counts
  as funny stuff)

This was fixed an hour or so ago.  Phk backed out the daddr_t size 
change pending investigation.
-- 
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
  http://www.Awfulhak.org   brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour !  brian@[uk.]OpenBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Dag-Erling Smorgrav 

Brian Somers [EMAIL PROTECTED] writes:
 This was fixed an hour or so ago.  Phk backed out the daddr_t size 
 change pending investigation.

Does that fix the loader too, or just the kernel?

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Brian Somers 

 Brian Somers [EMAIL PROTECTED] writes:
  This was fixed an hour or so ago.  Phk backed out the daddr_t size 
  change pending investigation.
 
 Does that fix the loader too, or just the kernel?

I'm not sure, I'm just rebuilding now.

Remember, /boot/loader.old is left around... handy in this situation 
(I'd forgotten 'till jhb pointed it out).

 DES
 -- 
 Dag-Erling Smorgrav - [EMAIL PROTECTED]

-- 
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
  http://www.Awfulhak.org   brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour !  brian@[uk.]OpenBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread John Baldwin 


On 15-May-2002 Dag-Erling Smorgrav wrote:
 John Baldwin [EMAIL PROTECTED] writes:
 The kernel overflowed it's stack.  In SRM, you can try to debug this
 by using 'e sp' to get the stack pointer then get a stack dump and save
 a copy of it in a log or something, reboot the machine, then use gdb's
 list command on the kernel.debug to figure out the source:line for all
 the kernel-text addresses in the stack dump to figure out the backtrace.
 
 How do I get a stack trace? I can't get the 'examine' command to
 actually print anything...

It depends on which machine actually. :-/  First do 'e sp' to get the
stack pointer.  Then you want to do something like this:

e -n 100 value of sp without any leading 0x

if that doesn't work then try:

e -n 100 vmem:value of sp w/o leading 0x

This should basically do a raw memory dump.  However, see if phk's
daddr_t reversal fixes it first.

-- 

John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: loader failure

2002-05-15 Thread Brian Somers 

  Brian Somers [EMAIL PROTECTED] writes:
   This was fixed an hour or so ago.  Phk backed out the daddr_t size 
   change pending investigation.
  
  Does that fix the loader too, or just the kernel?
 
 I'm not sure, I'm just rebuilding now.
 
 Remember, /boot/loader.old is left around... handy in this situation 
 (I'd forgotten 'till jhb pointed it out).

Yes, the daddr_t backout has fixed the loader and the filesystem 
problems.

  DES
  -- 
  Dag-Erling Smorgrav - [EMAIL PROTECTED]

-- 
Brian [EMAIL PROTECTED][EMAIL PROTECTED]
  http://www.Awfulhak.org   brian@[uk.]FreeBSD.org
Don't _EVER_ lose your sense of humour !  brian@[uk.]OpenBSD.org



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message