NetBSD Problem Report #32958

From www@netbsd.org  Wed Mar  1 04:24:22 2006
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
	id A180263B877; Wed,  1 Mar 2006 04:24:22 +0000 (UTC)
Message-Id: <20060301042422.A180263B877@narn.netbsd.org>
Date: Wed,  1 Mar 2006 04:24:22 +0000 (UTC)
From: sinda@users.sf.net
Reply-To: sinda@users.sf.net
To: gnats-bugs@netbsd.org
Subject: pxeboot on WRAP
X-Send-Pr-Version: www-1.0

>Number:         32958
>Category:       port-i386
>Synopsis:       pxeboot on WRAP
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 01 04:25:00 +0000 2006
>Last-Modified:  Sun Oct 15 17:30:01 +0000 2006
>Originator:     Petr Sindylek
>Release:        NetBSD 3.0
>Organization:
AlphaSys, s.r.o.
>Environment:
>Description:
I'm not able to PXE boot WRAP 1E [1] system board using NetBSD's pxeboot. It looks like this:

PC Engines WRAP.1C/1D/1E v1.08
640 KB Base Memory
130048 KB Extended Memory

01F0 Master 848A Hitachi XX.V.3.4.0.0                    
Phys C/H/S 695/15/48 Log C/H/S 695/15/48
ROM segment 0xe000 length 0x8000 reloc 0x00020000
Etherboot 5.3.12 (GPL) http://etherboot.org
Drivers: NATSEMI   Images: NBI PXE   Exports: PXE   
Relocating _text from: [00089370,0009b230) to [07eee140,07f00000)
Boot from (N)etwork (D)isk or (Q)uit? N

Probing pci nic...
[dp83815]
natsemi_probe: MAC addr 00:0D:B9:03:5C:BC at ioaddr 0X1000
natsemi_probe: Vendor:0X100B Device:0X0020
dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex.
dp83815: Transceiver status 7869 advertising 05E1
dp83815: Setting full-duplex based on negotiated link capability.
Searching for server (DHCP)...
Me: 192.168.127.19, Server: 192.168.127.254, Gateway 192.168.127.254
Loading 192.168.127.254:pxeboot_ia32.bin (PXE)done


>> NetBSD/i386 PXE Boot, Revision 1.1
>> (root@, Wed Mar  1 03:39:25 CET 2006)
>> Memory: 614/128824 k
Press return to boot now, any other key for boot menu
Starting in 0 
exec: file=netbsd loadaddr=0x0
PXE BIOS Version 2.1

and it locks now. pxeboot enters pxe_call(PXENV_GET_CACHED_INFO) on line 389 of pxe.c ver. 1.6 and never return.
It seems similar to problem solved in this posting
http://www.monkey.org/openbsd/archive2/bugs/200503/msg00001.html

[1] http://www.pcengines.ch/wrap.htm
>How-To-Repeat:

>Fix:

>Audit-Trail:
From: Nino Dehne <ndehne@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-i386/32958
Date: Tue, 11 Apr 2006 19:13:18 +0200

 Hi,

 a recent Etherboot contains the option FLATTEN_REAL_MODE which carries a
 description:

 "Use 4GB segment limits when calling out to or returning to real-mode code.
 This is necessary to work around some buggy code (e.g. OpenBSD's pxeboot)
 that uses flat real-mode without being sufficiently paranoid about the
 volatility of its segment limits."

 which is exactly the fix described in the thread listed above.

 Since my WRAP somehow doesn't jump into Etherboot when I flash it with a
 recent 5.4.1 instead of the ancient 5.3.12, I wanted to revive this PR.

 (Alternatively, if someone managed to get a 5.4.1 Etherboot into the WRAP
 BIOS and make it boot, I'd be interested in hearing about it.)

 From the description, it rather looks like a bug in pxeboot which Etherboot
 merely works around.

 If someone could please look into this, I'd be very grateful. This way, I
 wouldn't have to fiddle with the WRAP and potentially wreck it.

 Thanks

 Best regards

 ND

From: Nino Dehne <ndehne@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-i386/32958
Date: Sun, 1 Oct 2006 07:02:30 +0200

 As it turned out, there was one Etherboot option that was in the readme to
 WRAP's BIOS update which prevented Etherboot from getting jumped to, unless
 you pressed N during the memory test. That really sucked because the list
 of options made it sound like they were used to build the old Etherboot
 already in the BIOS.

 Anyway, a current Etherboot works now, although there is still trouble:

 ---- snip ----
 PC Engines WRAP.1C/1D/1E v1.11
 640 KB Base Memory
 130048 KB Extended Memory

 01F0 Master 848A Hitachi XXM2.3.0
 Phys C/H/S 978/8/32 Log C/H/S 978/8/32
 ROM segment 0xe000 length 0x8000 reloc 0x00000000
 Etherboot 5.4.2 (GPL) http://etherboot.org
 Drivers: NATSEMI   Images: NBI ELF Multiboot PXE   Exports: PXE
 Protocols: DHCP TFTP
 Relocating _text from: [0008bb80,0009fdc0) to [07eebdc0,07f00000)
 Boot from (N)etwork or (Q)uit?

 Probing pci nic...
 [dp83815]
 natsemi_probe: MAC addr 00:0D:B9:[...] at ioaddr 0X1000
 natsemi_probe: Vendor:0X100B Device:0X0020
 dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex.
 dp83815: Transceiver status 7869 advertising 05E1
 dp83815: Setting full-duplex based on negotiated link capability.
 Searching for server (DHCP)......
 Me: 192.168.1.99, DHCP: 192.168.1.1, TFTP: 192.168.1.1, Gateway 192.168.1.254
 Loading 192.168.1.1:i386/n/pxeboot.bin ...(PXE)............................done


 >> NetBSD/i386 PXE Boot, Revision 1.1
 >> (build@[...], Fri Sep 22 03:59:22 CEST 2006)
 >> Memory: 633/128943 k
 Press return to boot now, any other key for boot menu
 Starting in 0
 type "?" or "help" for help.
 >
 >
 >
 > boot netbsd.gz
 PXE BIOS Version 2.1
 Using PCI device at bus 0 device 14 function 0
 Ethernet address 00:0d:b9:[...]
 net_open: client addr: 192.168.1.99
 net_open: subnet mask: 255.255.255.0
 net_open: net gateway: 192.168.1.254
 net_open: server addr: 192.168.1.1
 net_open: server path: /x/b/i386/n/any/ext-gw/
 1914740+67142336+149048 [130592+123598]=0x423f4bc
 dp83815: Setting full-duplex based on negotiated link capability.
 ---- snip ----

 And that's it. pxeboot doesn't hang anymore. Instead, the kernel doesn't boot.
 Is it perhaps still pxeboot related? How can I debug?

 Best regards,

 ND

From: Adrian Portelli <adrianp@stindustries.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Subject: Re: port-i386/32958
Date: Sun, 15 Oct 2006 18:27:30 +0100

 Just as a data point I have a WRAP.1E-2 running BIOS v1.11 and the
 pxeboot functionality has the same problem as documented earlier in this
 ticket.

 However, using a kernel built from the netbsd-3 branch I was able to
 successfully boot a GENERIC kernel off a CF card on the WRAP.1E-2.  So
 you might want to try booting a kernel directly from a CF card and see
 how far it gets you.

 adrian.

Home	PR Database Search