9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: arisawa <arisawa@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
Date: Fri, 17 May 2013 21:36:40 +0900	[thread overview]
Message-ID: <5C06F2D4-2D81-4CF1-9E04-67E8A00F9109@ar.aichi-u.ac.jp> (raw)
In-Reply-To: <trinity-ecfe26f4-99bc-40f1-a24d-f518d3f0164f-1368711883853@3capp-gmx-bs41>

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 <cinap_lenrek@gmx.de> wrote:

> when the hex numbers count in (2), it means its reading
> the kernel file from the disk into memory.
> 
> 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.
> 
> 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.
> 
> 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?
> 
>> Gesendet: Donnerstag, 16. Mai 2013 um 02:16 Uhr
>> Von: arisawa <arisawa@ar.aichi-u.ac.jp>
>> An: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
>> Betreff: Re: [9fans] 9pccpu: can't open /dev/sdXX/nvram
>> 
>> Hello Erik,
>> 
>> the problem is not in transmission speed of network.
>> mine is based on 9front. 
>> 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.
>> 
>> 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.
>> 
>> Kenji Arisawa
>> 
>> P.S.
>> I accessed http://ftp.9atom.org/other/9paecpu to try your 9atom.
>> however I got "Object not found".
>> 
>> 
>> On 2013/05/16, at 6:18, erik quanstrom <quanstro@quanstro.net> wrote:
>> 
>>> On Wed May 15 16:57:59 EDT 2013, arisawa@ar.aichi-u.ac.jp wrote:
>>>> 
>>>> PXE + (nvram on usb flash) is much faster than usb flash only boot.
>>> 
>>> 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.
>>> 
>>> - erik
>>> 
> 




      reply	other threads:[~2013-05-17 12:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-28  3:30 arisawa
2012-07-28  8:19 ` David du Colombier
2012-07-28 13:41   ` arisawa
2012-07-28 14:33     ` David du Colombier
2012-07-29  7:30       ` arisawa
2012-07-29  9:43         ` Richard Miller
2012-07-29 11:45           ` arisawa
2012-07-29 14:16             ` Richard Miller
2012-07-29 22:49               ` arisawa
2012-07-30  9:19                 ` arisawa
2012-07-30 14:46                   ` erik quanstrom
2012-07-30 20:45                     ` cinap_lenrek
2012-08-17  2:15                       ` arisawa
2012-08-17  3:27                         ` cinap_lenrek
2013-05-13 16:37                   ` Skip Tavakkolian
2013-05-13 21:32                     ` arisawa
2013-05-13 21:53                       ` Matthew Veety
2013-05-13 23:06                       ` erik quanstrom
2013-05-15  9:56                         ` arisawa
2013-05-15 20:56                           ` arisawa
2013-05-15 21:18                             ` erik quanstrom
2013-05-16  0:16                               ` arisawa
2013-05-16  1:25                                 ` erik quanstrom
2013-05-16 13:44                                 ` kernel panic
2013-05-17 12:36                                   ` arisawa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5C06F2D4-2D81-4CF1-9E04-67E8A00F9109@ar.aichi-u.ac.jp \
    --to=arisawa@ar.aichi-u.ac.jp \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).