From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 4 19:11:42 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DF28BCE for ; Thu, 4 Sep 2014 19:11:42 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61DA91939 for ; Thu, 4 Sep 2014 19:11:42 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4E9FDB97E; Thu, 4 Sep 2014 15:11:41 -0400 (EDT) From: John Baldwin To: "Sinha, Prokash" Subject: Re: PXE boot Date: Thu, 04 Sep 2014 13:53:13 -0400 Message-ID: <2303890.kxxKhV23z4@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 04 Sep 2014 15:11:41 -0400 (EDT) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 19:11:42 -0000 On Thursday, September 04, 2014 04:33:46 PM Sinha, Prokash wrote: > On 9/4/14 9:31 AM, "Sinha, Prokash" wrote: > >Thanks once again... > > > >This is the part - that you spelled out is why I had a trace in the > >pxe_enable(...) routine. As well as at pxe_init( ...) routine, just = to be > >sure > >the pxe.c routines are working like ( as you said ) devsw invocation= . But > >did not see the trace messages, could be serial console is not actin= g ( > >though I doubt it). > > > >Now gave me a base, off of what I could debug ... Hmm, the console should be working (cons_probe() is called before=20 pxe_enable()). However, if you are using 'console=3Dcomconsole' in loa= der.conf=20 to set a serial console, you won't see early messages because loader.co= nf is=20 processed after main() calls interact() at the bottom of the function. = If you=20 want to see early loader messages on serial, you will need to build pxe= boot=20 with BOOT_PXELDR_ALWAYS_SERIAL defined as a make variable (so on the co= mmand=20 line, or in /etc/make.conf or /etc/src.conf). That will force a serial= =20 console for early loader messages. > > > >-prokash > > > >On 9/4/14 7:57 AM, "John Baldwin" wrote: > >>On Wednesday, September 03, 2014 11:16:05 PM Sinha, Prokash wrote: > >>> Thanks much, John ! > >>>=20 > >>> When it starts executing ? How ?. Who starts executing these. Fro= m the > >>> Makefile it's org is 0x7c00. So I would assume that it would be l= oaded > >>> > >>>at > >>> > >>> that absolute real-mode address !. I don't understand this part. = But, > >>> > >>>if I > >>> > >>> put traces, I see pxe_open, and pxe_close are being called, but a= fter > >>> > >>>all > >>> > >>> these pxe_calls are done, the loader's main is invoked at Rebooti= ng =C5=A0 > >>> > >>>time. > >>> > >>> We are using a net boot server, and I see mountd- authenticated =C5= =A0 > >>> > >>>message > >>> > >>> storm on the boot server side. > >>>=20 > >>> Wondering what could cause such a message storm, while pxe_open()= -> > >>> > >>>net > >>> > >>> if_open( ) executes. > >> > >>The PXE BIOS uses TFTP to fetch the pxeboot binary (and it will do = its > >>own > >>DHCP, etc. as part of doing that). It writes the binary it downloa= ds > >>starting > >>at address 0x7c00. Once the download is complete, it jumps to 0x7c= 00 > >>similar > >>to how booting from a disk loads the first sector at address 0x7c00= and > >>then > >>jumps to it. > >> > >>The PXE calls in libi386 should not be invoked until the loader mai= n() > >>routine > >> > >>runs: > >> /* > >> =20 > >> * Special handling for PXE and CD booting. > >> */ > >> =20 > >> if (kargs->bootinfo =3D=3D 0) { > >>=09 > >>=09/* > >>=09 > >>=09 * We only want the PXE disk to try to init itself in the below > >>=09 * walk through devsw if we actually booted off of PXE. > >>=09 */ > >>=09 > >>=09if (kargs->bootflags & KARGS_FLAGS_PXE) > >>=09 > >>=09 pxe_enable(kargs->pxeinfo ? PTOV(kargs->pxeinfo) : NULL); > >>=09 > >>=09else if (kargs->bootflags & KARGS_FLAGS_CD) > >>=09 > >>=09 bc_add(initial_bootdev); > >> =20 > >> } > >> > >>That enables the PXE devsw driver so that it will do something late= r when > >> > >>main() calls all the devsw init routines: > >> /* > >> =20 > >> * March through the device switch probing for things. > >> */ > >> =20 > >> for (i =3D 0; devsw[i] !=3D NULL; i++) > >>=09 > >>=09if (devsw[i]->dv_init !=3D NULL) > >>=09 > >>=09 (devsw[i]->dv_init)(); > >> =20 > >> printf("BIOS %dkB/%dkB available memory\n", bios_basemem / 1024= , > >> > >>bios_extmem / 1024); --=20 John Baldwin