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
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
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
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
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
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
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
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;
I see linux code doing SSE instructions. Has anyone started SSE support
for plan9 kernel yet? Will the AMD64 port contain SSE support?
--
cinap
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
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.
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
[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
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
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
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.
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.
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
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
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
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
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
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:
23 matches
Mail list logo
