Re: [9fans] 9pccpu: can't open /dev/sdXX/nvram
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 aris...@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 quans...@quanstro.net wrote: On Wed May 15 16:57:59 EDT 2013, aris...@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
Re: [9fans] 5l bug
Gesendet: Montag, 29. April 2013 um 21:34 Uhr
Von: Richard Miller 9f...@hamnavoe.com
An: 9fans@9fans.net
Betreff: Re: [9fans] 5l bug
following up, theres my naive fix for this. instead of
emiting conditional division instruction by 5c... dont and
keep the branch. does this make any sense?
I think it should be corrected in 5l. Some ARM versions do
have a hardware divide instruction, which could one day be
supported by 5l, so 5c should be kept more generic.
The compiler already assumes things that would be not true for
native divide instructions. For example, we assume that divide
modifies the condition flags, which would not be the case for
native SDIV/UDIV, but is the case for the emulated ones because
its implemented as a subroutine:
(from /sys/src/cmd/5c/peep.c)
/*
* Depends on an analysis of the encodings performed by 5l.
* These seem to be all of the opcodes that lead to the S bit
* being set in the instruction encodings.
*
* C_SBIT may also have been set explicitly in p-scond.
*/
int
modifiescpsr(Prog *p)
{
return (p-scondC_SBIT)
|| p-as == ATST
|| p-as == ATEQ
|| p-as == ACMN
|| p-as == ACMP
|| p-as == AMULU
|| p-as == ADIVU
|| p-as == AMUL
|| p-as == ADIV
|| p-as == AMOD
|| p-as == AMODU
|| p-as == ABL;
}
the change i made just avoids the branch optimization for these
instructions not executing them conditionally. the whole idea of
this pass is to avoid the branching arround *short* conditional
code sequences (4 instructions at max).
with the emulated instructions the _div call setup already takes
more than 4 instructions and just reintroducing a branch in the
linker counters what the optimization pass tried to archive in the
first place.
but maybe its not really worth thinking about because conditional
divide seems quite rare (?) and emulated divide will be slow in any
case (?) so it wont matter if we readd conditional branch in the linker?
still, the dependency between 5l - 5c above remains... otherwise,
one would need to write condition flag preserving version... for
these instructions to make them behave exactly like the native
instructions... perhaps emulate the instructions by traping in the
kernel? seems even slower... how ignorant do we want 5c to be at
what cost?
--
cinap
Re: [9fans] 5l bug
i is not ovious to me why that would work without adding a conditiona branch. maybe my assumptions are wrong. can you show the resulting assembly for the testcase? Gesendet: Dienstag, 30. April 2013 um 11:07 Uhr Von: zephyr.pelle...@gmail.com An: 9fans@9fans.net Betreff: Re: [9fans] 5l bug Patching p - scond = q - scond in /sys/src/cmd/5l/noop.c fixes this unfortunate linker bug. -- cinap
Re: [9fans] Go Plan9 ARM Dreamplug
go is using switch on vlongs. support for this was backported to plan9 c compiler some time ago. just update the compilers from sources. Von: Skip Tavakkolian skip.tavakkol...@gmail.com /usr/fst/Go1/src/cmd/gc/reflect.c:1022[/usr/fst/Go1/src/cmd/gc/reflect.c:3400] switch _expression_ must be integer
Re: [9fans] Go Plan9 ARM Dreamplug
yes. you are right, it doesnt work for 5c. -- cinap Gesendet: Montag, 15. April 2013 um 10:43 Uhr Von: Gorka Guardiola pau...@gmail.com An: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net Betreff: Re: [9fans] Go Plan9 ARM Dreamplug On Mon, Apr 15, 2013 at 10:31 AM, kernel panic cinap_len...@gmx.de wrote: go is using switch on vlongs. support for this was backported to plan9 c compiler some time ago. just update the compilers from sources. Last time I checked (like a week ago) it did not work with 5c. G.
[9fans] Tdmaxpkt in usbehci
in the ehci driver, it uses: Tdmaxpkt = 0x5000, /* max buffer for a Td */ a td has 5*4K pages giving the 20K above, but i think this only applies if the first pointer is page aligned (page offset = 0) so all the pages can be filled completely. The EHCI spec says this: The buffer pointer list in the qTD is long enough to support a maximum transfer size of 20K bytes. This case occurs when all five buffer pointers are used and the first offset is zero. A qTD handles a 16Kbyte buffer with any starting buffer alignment. The buffer pointer isnt page aligned as far as i can see, so make Tdmaxpkt = 0x4000 instead? -- cinap
Re: [9fans] Tdmaxpkt in usbehci (no html)
yes, that would work too. -- cinap Gesendet: Donnerstag, 11. April 2013 um 15:05 Uhr Von: erik quanstrom quans...@quanstro.net An: 9fans@9fans.net Betreff: Re: [9fans] Tdmaxpkt in usbehci (no html) in the ehci driver, it uses: Tdmaxpkt = 0x5000, /* max buffer for a Td */ a td has 5*4K pages giving the 20K above, but i think this only applies if the first pointer is page aligned (page offset = 0) so all the pages can be filled completely. The EHCI spec says this: The buffer pointer list in the qTD is long enough to support a maximum transfer size of 20K bytes. This case occurs when all five buffer pointers are used and the first offset is zero. A qTD handles a 16Kbyte buffer with any starting buffer alignment. The buffer pointer isnt page aligned as far as i can see, so make Tdmaxpkt = 0x4000 instead? i wonder if it would make more sense to align the buffer. (the unaligned case for iso-data looks wierd, too.) - erik
[9fans] wired loop in usbehci / isohsinit()
this td-buffer[i] access makes no sense.
static void
isohsinit(Ep *ep, Isoio *iso)
{
int ival, p;
long left;
ulong frno, i, pa;
Itd *ltd, *td;
iso-hs = 1;
ival = 1;
if(ep-pollival 8)
ival = ep-pollival/8;
left = 0;
ltd = nil;
frno = iso-td0frno;
for(i = 0; i iso-nframes; i++){
td = itdalloc();
td-data = iso-data + i * 8 * iso-maxsize;
pa = PADDR(td-data) ~0xFFF;
for(p = 0; p 8; p++)
td-buffer[i] = pa + p * 0x1000; // - HERE
td-buffer[0] = PADDR(iso-data) ~0xFFF |
ep-nb Itdepshift | ep-dev-nb Itddevshift;
if(ep-mode == OREAD)
td-buffer[1] |= Itdin;
else
td-buffer[1] |= Itdout;
td-buffer[1] |= ep-maxpkt Itdmaxpktshift;
td-buffer[2] |= ep-ntds Itdntdsshift;
if(ep-mode == OREAD)
td-mdata = 8 * iso-maxsize;
else{
td-mdata = (ep-hz + left) * ep-pollival / 1000;
td-mdata *= ep-samplesz;
left = (ep-hz + left) * ep-pollival % 1000;
}
coherence();
iso-itdps[frno] = td;
coherence();
itdinit(iso, td);
if(ltd != nil)
ltd-next = td;
ltd = td;
frno = TRUNC(frno + ival, Nisoframes);
}
}
--
cinap
[9fans] SSE on Plan9
I see linux code doing SSE instructions. Has anyone started SSE support for plan9 kernel yet? Will the AMD64 port contain SSE support? -- cinap
Re: [9fans] broken smtpd
erik quanstrom wrote:
d'oh! the return value from catchalarm looks reversed. from notify(2)
[...] A handler must
return a non-zero number if the note was recognized (and
resolved); otherwise it must return zero. When the system
i think you're getting into some sort of note loop. i think it would
be helpful to log all notes. i would try something like this
its not a good idea to call syslog() in a note handler, because it
aquires locks
and calls into the memory allocator by strdup() (that too aquires locks).
if the note interrupts the program while in syslog() or the allocator,
it will deadlock.
--
cinap
static int
catchalarm(void *, char *msg)
{
static int chattycathy;
if(chattycathy++ 5)
return 0;
if(senders.first rcvers.first)
syslog(0, smtpd, note: %s-%s: %s,
s_to_c(senders.first-p),
s_to_c(rcvers.first-p), msg);
else
syslog(0, smtpd, note: %s, msg);
if(pp){
syskillpg(pp-pid);
pp = 0;
}
return strstr(msg, alarm) != 0;
}
but at a minimum, i would reverse the return values.
- erik
Re: [9fans] photos of iwp9
Roman Shaposhnik wrote: On Nov 6, 2008, at 3:01 AM, Kernel Panic wrote: http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0213.jpg This one is truly awesome! yeah :-) Thanks, Roman.
[9fans] photos of iwp9
I put the photos in my contrib on sources yesterday. The http file listing on sources seems broken currently... so here are the urls: http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0181.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0182.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0183.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0184.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0185.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0186.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0187.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0188.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0189.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0190.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0191.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0192.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0193.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0194.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0195.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0196.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0197.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0198.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0199.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0200.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0201.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0202.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0203.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0204.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0205.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0206.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0207.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0208.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0209.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0210.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0211.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0212.jpg http://plan9.bell-labs.com/sources/contrib/cinap_lenrek/photos/iwp9.2008/dscn0213.jpg -- cinap
Re: [9fans] mmap and shared libraries
[EMAIL PROTECTED] wrote: A thought ... Shared libraries do 2 possibly useful things: 1) save space 2) stop you having to re-link when a new library is released. Now 2) doesn't really happen anyway, due to .so versioning hell, so we're left with 1) ... I know it's kind-of hacky and unstructured (how do you know the venti block size?), but could you not block-align the library members in the .a, so venti would do the sharing on disk for you? Look at this: http://gsoc.cat-v.org/people/mjl/blog//2007-08-06-1_Rabin_fingerprints As a further step, you could also page align the text segments of the library members, then implement a venti-like scheme for read-only pages in memory, so that when the executable loads, it gets any common library pages shared. Dave. P.S. Sorry not to make Volos: where are the rest of the photos?
Re: [9fans] notes and traps
erik quanstrom wrote: it would also be interesting to know if you are seeing this randomly or if you can reliable reproduce this condition. i can reproduce it with this: http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/ 8c test.c 8a int80.s 8l test.8 int80.8 ./8.out 8.out 12490667: suicide: sys: trap: general protection violation pc=0x1333 the parent process loops and does fake syscalls while the child posts notes to it. - erik -- cinap
Re: [9fans] notes and traps
Kernel Panic wrote: http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/ 8c test.c 8a int80.s 8l test.8 int80.8 ./8.out 8.out 12490667: suicide: sys: trap: general protection violation pc=0x1333 the parent process loops and does fake syscalls while the child posts notes to it. arg... swap parent - child... but you'll see it in the code. -- cinap
[9fans] notes and traps
I run into an interesting problem with linuxemu.
The problem *seems* to be that traps can be
enqueued in the process note array *after* some
other note causing notify() to kill us.
Please correct me if i miss(understand) something
here. It just hit my mind after hours of late night
debugging.
The case:
If some other process sends a note with postnote(). The
kernel will enqueue the note in the target process.
(The note is marked as Nuser)
notestate of the target process:
note[0] = {Nuser, usernote}
nnote = 1
notified = 0
This note will be delivered when notify() is called.
notify is called on:
- after a syscall
- after interrupt/trap handling (timer interrupt?)
Now, in our case, the receiving process causes a trap.
It enters the kernel from the vector table
and /sys/src/9/pc/trap.c:trap() is called.
trap() decodes the error and enqueues a note
with the Ndebug flag.
the target process note state now looks like
this:
note[0] = {Nuser, usernote}
note[1] = {Ndebug, sys: trap: some trap}
nnote = 2
notified = 0
trap() now calls notify() because nnote != 0.
notify() delivers the usernote and sets
notified = 1;
we return to userspace with kexit() and we
pop out in the note handler to process the
usernote.
the note state looks now like this:
note[0] = {Ndebug, sys: trap: some trap}
nnote = 1
notified = 1
now strange things happen. if we enter
the kernel for some reason (syscall, timer
interrupt?)
notify() will kill us:
/* n is the address of the 0th entry from the note array */
if(n-flag!=NUser (up-notified || up-notify==0)){
if(n-flag == NDebug)
pprint(suicide: %s\n, n-msg);
qunlock(up-debug);
pexit(n-msg, n-flag!=NDebug);
}
if we are lucky, we could do a noted() inside
the notehandler and it will set up-notified to
zero before some the timer interrupt arrives.
What i need is that i get the Ndebug-note in the
notehandler *first*. it doesnt make sense to me to
queue traps.
Something similar i found in postnote():
if(flag != NUser (p-notify == 0 || p-notified))
p-nnote = 0;
but obviously this only works if it has already notified
the process. why?
--
cinap
Re: [9fans] mmap
Joel C. Salomon wrote: On Wed, Jul 30, 2008 at 11:29 AM, Enrico Weigelt [EMAIL PROTECTED] wrote: Convenience is one point (sometimes be a big point), but another important one is sharing. Without mmap(), an (real) shared library support most likely will require special kernel support. Actually, almost any kernel support for shared libraries will need something like mmap() internally. I forget who said it, and the local firewall won't allow me to search the online copy of /sys/games/lib/fortunes, but there should be a line there about Linux having 200+ system calls, most of them emulatable with mmap(). what nonsense is that? --Joel cinap
Re: [9fans] sad commentary
sqweek wrote: On Wed, Jul 2, 2008 at 8:35 PM, erik quanstrom [EMAIL PROTECTED] wrote: Also, public 9grids. Though judging by gdiaz's experiences with sirviente, there's a bit of work to be done in that area - I get the impression things are fairly unstable once the machine gets under memory pressure. -sqweek i think this is an artifact of setting up heavily-used systems combining venti, fossil, auth and cpu server. ... sure crashing is antisocial. the alternative is to add very large amounts of code to the kernel. Swap doesnt work reliable here. :-( I have disabled swaping and let the kernel kill the biggest process skipping any critical server processes and it works well. got ~100 days uptime and i use this machine for linuxemu development/testing. no adding very large amounts of code... maybe fix the swap... or even remove it alltogether. Back when this was first posted I wanted to protest the point that a large kernel modification is necessary, since I figured you can do a good enough job with just an interface to tell the kernel not to kill the important server processes. Obviously I decided to let it lie, but I just discovered this can be done without modifying the kernel at all when I happened across an interesting line in termrc: /rc/bin/termrc:dontkill '^(ipconfig|factotum|mntgen|fossil|cs|dns|listen|reboot)$' The default cpurc doesn't use dontkill, but I suspect it could be a big help for all-in-one servers. Figured I'd point it out as it seems easy to miss. ... plus everyone can use a good scare every now and then, and what better way than to resurrect sad commentry? -sqweek :D good to know :-) cinap
Re: [9fans] 8 cores
Iruata Souza wrote: On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? only for the fun of it, I'm slowly trying to port it to my SGI O2. nice! whats the status of your port? have an SGI indy (IP22) and would like to contribute if i find the time :-) please put it somewhere! iru cinap
Re: [9fans] 8 cores
Charles Forsyth wrote: I could imagine that databases use mmap() havily it's a little mystery for me why they would do that since it's slower (or ought to be), because the trap path and fault recovery must do more work than syscall (perhaps much more). it's also difficult then to optimise the replacement strategy for the application without madvise calls (and you trust those implicitly?) but those are system calls that cost time. makes sense of course... but at least mysql uses mmap() for some table types as a caching mechanism. http://www.mysqlperformanceblog.com/2006/05/26/myisam-mmap-feature-51/ this may just be an exception and real databases use read()/write() syscalls and implement the caching themself. but where should i know... i dont need/use databases and have not looked at the sourcecode of one. cinap
Re: [9fans] why not Lvx for Plan 9?
ron minnich wrote: futex? http://en.wikipedia.org/wiki/Futex so do we need a futtocks device? i think this can be implemented without any additional devices... wtf?! ron cinap
Re: [9fans] venti survery results
Richard Miller wrote: I am surprised that there are people out there with 4+ year old servers. You take very good care of your disks. An arena can be older than the disk it's on -- you can copy arenas verbatim from an old disk to a new one without changing the timestamps. 1756289 324119 12.6 11.4 1984 oldest That is the case... I wanted to save some power and I migrated from my old P-II 4x IDE disk server to a tiny VIA C7 2x SATA disk one. They are always running and are backed up by UPS. I use always fs mirror for the arena partitions with 2 disks from different brands. but no luck yet... no disks got bad on these machines so far. By the way... the VIA machine is the one that got me lots of trouble with the SATA until i hacked a bruteforce retry-n-reset-loop in the ide driver, now works perfectly stable (84 days uptime for now) :-) cinap
Re: [9fans] venti survery results
Richard Miller wrote: the VIA machine is the one that got me lots of trouble with the SATA until i hacked a bruteforce retry-n-reset-loop in the ide driver, Me too. Maybe one of us should submit a patch? this is the driver that works for me: http://9hal.ath.cx/usr/cinap_lenrek/viamod/sdata.c -- Richard I'm lazy as hell cinap
