From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OrHqZ-0003PY-Bv for mharc-grub-devel@gnu.org; Thu, 02 Sep 2010 18:01:27 -0400 Received: from [140.186.70.92] (port=50222 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OrHqV-0003Mo-0M for grub-devel@gnu.org; Thu, 02 Sep 2010 18:01:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OrHqT-0005uq-Nm for grub-devel@gnu.org; Thu, 02 Sep 2010 18:01:22 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:50834) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OrHqT-0005ue-Hq for grub-devel@gnu.org; Thu, 02 Sep 2010 18:01:21 -0400 Received: by fxm3 with SMTP id 3so780041fxm.0 for ; Thu, 02 Sep 2010 15:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=HWWoM1x3OKwgsu4hXHcZAekzuTBSn4POtx24Z0tqc0I=; b=A+eKnXjyk/em7CoRy91zBL8JbB9dTUud5ILAx9EWIj/DSMwYw+kwEySrBUk7EXPpy9 RS6OLeTeqtiRJgMovF/d0r7ofysGZJHgJgW7JGQYR7mwq/kiZoDuPmYAf2HDlnaBkfrm Mbx4rJJyNGSWKwZ3F7og476diI3ZQlguIbaks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=vhVpTYXb4B/LBSzOor4nPShL/WIUG4t36701tgbuNppxRSzfFu4vRYu0Ed3JRi2L+j 87eUn8FyAlR6a/qhnY6g8/7ArCHqWV65Jl+C4KlrI3VxioVVrOzbPYq+hdwU+6CaWCmA wKugzK5mSkLePYrlvsQoJORHjHjbAPi3feylY= Received: by 10.223.108.200 with SMTP id g8mr5644219fap.103.1283464880636; Thu, 02 Sep 2010 15:01:20 -0700 (PDT) Received: from debian.bg45.phnet (62-156.62-81.cust.bluewin.ch [81.62.156.62]) by mx.google.com with ESMTPS id 19sm523266fas.1.2010.09.02.15.01.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Sep 2010 15:01:19 -0700 (PDT) Message-ID: <4C801EAD.5070703@gmail.com> Date: Fri, 03 Sep 2010 00:01:17 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6 MIME-Version: 1.0 To: grub-devel@gnu.org References: <4C7AF5EA.5020305@gmail.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1104DEE3E6FE60B08D166E1F" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Bug report: PXE blocksize X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 22:01:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1104DEE3E6FE60B08D166E1F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/30/2010 04:52 PM, Turner, Ian wrote: >> I don't see where you mean. The only reference to pxe_blksize I see in= >> pxefs_read is following: >> o.packet_size =3D grub_pxe_blksize; >> grub_pxe_call (GRUB_PXENV_TFTP_OPEN, &o); >> Which is called only when reopening file. Could you retry pulling? Now= >> newreloc is merged into mainline so you can just pull mainline. >> =20 > You're right. The problem is more complex that I thought originally. I = think it's something more like this: > > 1. Start loading a file 'grub.cfg' with blksize=3D512 > 2. File contains a directive to change blocksize to something else (e.g= =2E, 1024). This updates grub_pxe_blksize but doesn't change the paramete= rs of the grub.cfg session. > 3. File also contains a directive that causes grub to load some other f= ile (say, an insmod or source command). This causes pxe.c to close grub.c= fg for now, but the grub_pxe_data object sticks around. > 4. Upon resuming read of grub.cfg, pxe opens with the new blocksize but= reads with the old one. > > I still think the solution is what I proposed originally (patch follows= ), which maintains the same PXE blocksize for a given file until it is fi= nally closed by the requestor, no matter how many times PXE itself needs = to open/close the TFTP session. > =20 There are 2 problems with changing blocksize in the middle of the stream:= 1) pn isn't recomputed. Easy to fix 2) bufio doesn't change the size. Difficult and ugly to fix. So I applied your patch. Thanks > --- pxe-broken.c 2010-08-30 10:52:03.717580213 -0400 > +++ pxe-fixed.c 2010-08-30 10:52:49.370957060 -0400 > @@ -281,7 +281,7 @@ > o.gateway_ip =3D disk_data->gateway_ip; > grub_strcpy ((char *)&o.filename[0], data->filename); > o.tftp_port =3D grub_cpu_to_be16 (GRUB_PXE_TFTP_PORT); > - o.packet_size =3D grub_pxe_blksize; > + o.packet_size =3D data->block_size; > grub_pxe_call (GRUB_PXENV_TFTP_OPEN, &o); > if (o.status) > { > > Cheers, > > --Ian > > =20 > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig1104DEE3E6FE60B08D166E1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAkyAHq0ACgkQNak7dOguQglQ2AD/SkKU8r8+9nddbQoIR7C8AFVg eOw1wqsftEnP6ob4QKkA/3BpyiCoX6672aJa7AIhXXhb7SstuaSa8Zd+v4qKGqq8 =zcBC -----END PGP SIGNATURE----- --------------enig1104DEE3E6FE60B08D166E1F--