From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: arisawa In-Reply-To: Date: Fri, 17 May 2013 21:36:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5C06F2D4-2D81-4CF1-9E04-67E8A00F9109@ar.aichi-u.ac.jp> References: <85af690eff1ce236dd281a2a86b4f481@hamnavoe.com> <6436ed69830a1193bf7566be810e705b@ladd.quanstro.net> <9A159701-1047-44BC-9692-8B893460A0D4@ar.aichi-u.ac.jp> , <259935D3-4933-4C59-A376-CF0726CE2B23@ar.aichi-u.ac.jp> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] 9pccpu: can't open /dev/sdXX/nvram Topicbox-Message-UUID: 5951e9e4-ead8-11e9-9d60-3106f5b1d025 thanks panic, it does not take long time to switch message from (1) to (2). the problem is in (2) that read single 512 byte block of data. Kenji Arisawa On 2013/05/16, at 22:44, kernel panic wrote: > when the hex numbers count in (2), it means its reading > the kernel file from the disk into memory. >=20 > 9fronts 9boot loader uses the bios for all device access. > to read a single 512 byte block of data from a harddrive > (or usb flash drives as they are emulated as harddrives by > the bios), we switch from 32bit protected mode to realmode, > do the bios call and return to protected mode copying the > block from stack in low memory to its final destination. >=20 > doing these single block reads might be inefficient with > your bios implementation. tho it never has been a problem > with ide/sata harddrives or cdroms. >=20 > when it takes long from (1) to (2), this could be a problem > with the usleep() code. after we read plan9.ini, we wait > a bit for keyboard input so one can interrupt the automatic > boot process. maybe that wait loop is not working right? >=20 >> Gesendet: Donnerstag, 16. Mai 2013 um 02:16 Uhr >> Von: arisawa >> An: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> >> Betreff: Re: [9fans] 9pccpu: can't open /dev/sdXX/nvram >>=20 >> Hello Erik, >>=20 >> the problem is not in transmission speed of network. >> mine is based on 9front.=20 >> messages that come from booting process is as follows: >> (1) the content in plan9.ini. >> (2) then single letter hexadecimal messages 0 1 ... a b .. f 0 1 ... >> (3) and then "boot". the message comes from bootfat. >> (4) finally "Plan9" message from the loaded kernel. >>=20 >> the message (2) is very slow and takes much time to finish. >> I suspect bootfat takes too much time to find a specified kernel in = fat partition. >> the time is mother board dependent. >> my new one is sufficiently fast, but old one (GA-G31M-S2L) is = irritatingly slow. >>=20 >> Kenji Arisawa >>=20 >> P.S. >> I accessed http://ftp.9atom.org/other/9paecpu to try your 9atom. >> however I got "Object not found". >>=20 >>=20 >> On 2013/05/16, at 6:18, erik quanstrom wrote: >>=20 >>> On Wed May 15 16:57:59 EDT 2013, arisawa@ar.aichi-u.ac.jp wrote: >>>>=20 >>>> PXE + (nvram on usb flash) is much faster than usb flash only boot. >>>=20 >>> my experience has been that usb flash boot can be faster due >>> to networking quirks. for example, spanning tree or even switch = uplink >>> connect times can be measured in many seconds. >>>=20 >>> - erik >>>=20 >=20