"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>[ I've CCed John Tobey as I'm not sure if he has assigned the
> copyright. ]
>
> For such a small change a copyright assigment isn't needed.
For GNU Mach, copyright assignments are not needed at all. That is
what the FSF told me.
--
Marco
For GNU Mach, copyright assignments are not needed at all. That is
what the FSF told me.
Oh, cool... Didn't know about that.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
[ I've CCed John Tobey as I'm not sure if he has assigned the
copyright. ]
For such a small change a copyright assigment isn't needed.
Long time ago we got a bug report in Debian with a patch for Oskit
Mach.
What bug does it fix? (the bit you quoted only had lots of "ifs")
As for
--- Derek L Davies <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I find I have have to apply the following patch to get the oskit mach
> branch from the gnumach cvs module on subversions:
>
> diff -u -r1.22.2.20 Makefile.in
> --- Makefile.in 23 May 2002 06:36:21 - 1.22.2.20
> +++ Makefile.in
I can't make any promises. It's obvious from how little I've done since
the last several times I said I planned to do something, that I am not
doing very much. Anyway, there is never any reason someone else shouldn't
work on it if they want to.
As for merging changes upstream, post to oskit-us
Roland McGrath <[EMAIL PROTECTED]> writes:
> Do info regs and disas $pc in that gdb too.
>
Here it is:
(gdb) disas $pc
Dump of assembler code for function copyout_retry:
0x13c285 : mov%cr3,%ecx
0x13c288 : mov%edi,%eax
0x13c28a : shr$0x16,%eax
0x13c28d : mov0x
Do info regs and disas $pc in that gdb too.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
It does not for me. Anyway having $prefix/lib/oskit as OSKIT_LIBDIR is
confusing IMO.
Here is what I get:
hramrach@hurd:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-gnu/3.2/specs
Configured with: /cdrom/build/gcc/gcc-3.2-3.2ds0/src/configure -v
--enable-languages=c,c++,f77,proto,objc --p
The configure check finds OSKIT_LIBDIR just fine for me.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
This patch changes:
- makes makefile require OSKIT_LIBDIR=$prefix/lib instead of $prefix/lib/oskit
- removes the OSKIT_LIBDIR detection which does not work from configure
- adds a check for $OSKIT_LIBDIR/oskitt/multiboot.o
- adds an error message saying you should set OSKIT_libdir manually
T
On Sat, Sep 14, 2002 at 12:04:41AM +0200, Joachim Nilsson wrote:
> OSKIT_LIBDIR=/usr/local/lib/oskit \
It looks like this: you install oskit into $prefix (=/usr/local) and the libs go to
$prefix/lib (=/usr/local/lib) and you set OSKIT_LIBDIR to $prefix/lib/oskit
(=/usr/local/lib/oskit). Is this
> As James noted, there is no oskit_smp in oskit now. I further checked
> with: "grep -n smp `find . -name Makefile\*`" and there is no mention
> of `smp' in there. Although, their release notes don' mention
> dropping support.
Oops. I never noticed because my machine has an old installation s
On Fri, Apr 19, 2002 at 07:17:16PM -0400, Roland McGrath wrote:
> As to the removal of -loskit_smp, that obviously breaks the SMP build.
> Having the library there when building without SMP is harmless.
As James noted, there is no oskit_smp in oskit now. I further checked
with: "grep -n smp `fi
> This should not be required. My build is fine without it.
Did you have oskit 2001 installed in /usr/lib before you installed oskit 2002?
>
> The compiler by itself with the CC and CFLAGS settings you put in the
> environment (or don't) for configure need to be correct for finding the
> os
> At lunch I started a compile of oskit with gcc-3, and it appears to
> have built. I'm going to play with an all gcc-3 based
> oskit+oskit-mach when I get home tonight.
Ok. I don't know what to expect from this. The problems of compiler vs
linux drivers tend to be of the nature that an indivi
On Fri, Apr 19, 2002 at 05:04:57PM -0400, Roland McGrath wrote:
> > I had a moment, so I decided to try building oskit-mach with
> > gcc-3.0. Note that this is linked against an oskit build with
> > gcc-2.95.4. It appears to work (boot, mount filesystem, ping
> > localhost)
> Great! Thanks fo
> I had a moment, so I decided to try building oskit-mach with gcc-3.0.
> Note that this is linked against an oskit build with gcc-2.95.4. It
> appears to work (boot, mount filesystem, ping localhost)
Great! Thanks for verifying that this works.
> Aside from the usual two patches, it compiled
> What ethernet driver are you using?
The card is ne2000 compatible. The old 8390 driver is used.
During booting the system I see this:
"Use of the PCI-NE2000 driver with this card is recommended!"
Using a newer driver could solve my problem.
wagi
--
Daniel Wagner "
--- Daniel Wagner <[EMAIL PROTECTED]> wrote:
> I've been playing around with some ping flooding. As it seems
> oskit-mach is not stable enough for these kind of torturing.
> Here are some things I tried and what happened. I didn't have
> analyzed the problems more deeply. I just wanted them to re
It seems oskit-20020317 works fine with oskit-mach.
Unfortunatly there are some small things which were reportet
on the oskit mailling list, but not fixed yet.
Basically the problems are sbrk-hack.c is not needed anymore (as it
seems) and the obscure GFP_ATOMIC definition in skbufio.h.
I will
--- Jeroen Dekkers <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 17, 2002 at 04:18:27PM -0800, James Morrison wrote:
> > Well, I compiled the newest version of oskit today, I added the tlan
> driver to
> > oskit and oskit-mach compiled and run with the following patch.
>
> That's nice. I don't know
On Sun, Mar 17, 2002 at 04:18:27PM -0800, James Morrison wrote:
> Well, I compiled the newest version of oskit today, I added the tlan driver to
> oskit and oskit-mach compiled and run with the following patch.
That's nice. I don't know if it's possible to just change all the
Linux driver code t
Daniel Wagner <[EMAIL PROTECTED]> writes:
> Calling device_write with an invalid data_count, device_write will return
> an error (D_INVALID_SIZE). I didn't checked the return value, instead
> I tested for the bytes_written and of course there's only a bogus
> value.
This is a general rule for
> ds_device_write_error_reply call in ds_device_write. What is the actual
> failure mode now?
You were completetly right. There's no bug. Sorry, for bothering you.
Calling device_write with an invalid data_count, device_write will return
an error (D_INVALID_SIZE). I didn't checked the return v
> ds_net_write_inband makes first a sanity check for the given paramenters.
> If this fails it just returns without setting bytes_written to 0.
That is as it should be. I thought you were talking about a successful call.
The out parameters are not examined when the return value is nonzero,
so it
> That is pretty strange. There are two things here that are not right.
> That value from ops->write_inband (61) is bogus for that call. But,
> whatever is in *bytes_written at that point definitely ought to make it
> back to the user. To debug the latter case, please do "finish" from that
> fr
> In order to trigger the bug again, I setted data_count to 4. bytes_written
> return the value 18677512. But bytes_written does not match to size which
> the driver returns:
That is pretty strange. There are two things here that are not right.
That value from ops->write_inband (61) is bogus for
Roland McGrath <[EMAIL PROTECTED]> writes:
> > libstore uses device_map with size and offset being null.
>
> Urmph. To my mind, this just illustrates that the current io_map interface
> model is really wrong and that an io_map call that takes offset and size
> parameters is the way to go (as
Sorry for being so unclear, I'm trying to be more specific.
I was referring to this (stolen from the mach docs):
kern_return_t device_write (device_t device,
dev_mode_t mode,
recnum_t recnum,
io_buf_ptr_t data
> Just one thing: The last argument should return the number of written
> bytes. When an error has occured, the return values does not match the
> bytes_written variable in ds_device_write.
Sorry, I am not following you at all. Please be more specific (show a patch).
It sounds like you are tal
> Please try the ds_routines.c change I just committed and tell me if it
> helps or harms.
Your patch helps.
Just one thing: The last argument should return the number of written
bytes. When an error has occured, the return values does not match the
bytes_written variable in ds_device_write.
> And, some variables (like X in device/net_io.c) `might be used
> uninitialized'. They are mostly register `int's set to 0 in case of
> `#if lint', but unset normally. This may have reasons concerning
> speed. Can we be sure, that gcc sets them to zero or should they get
> initialized?
The warni
> libstore uses device_map with size and offset being null.
Urmph. To my mind, this just illustrates that the current io_map interface
model is really wrong and that an io_map call that takes offset and size
parameters is the way to go (as is already my plan for large-file mapping).
> I am no
Please try the ds_routines.c change I just committed and tell me if it
helps or harms.
Thanks,
Roland
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Hmm, I think I may have eyeballed the problem. When the server function
(ds_device_write) returns something other than KERN_SUCCESS (zero) or
MIG_NO_REPLY, then the message body will get destroyed by the kernel.
What's happening is that we call vm_map_copyout, which consumes the ool
stuff in the
I don't really have any ideas off hand what the problem might be. Can you
step through the return from ds_device_write in gdb and follow what happens
from there until the crash?
The only other idea that occurs to me for narrowing it down is to try you
test program with device_write_inband and se
The bug is triggered, when from an underlying layer (driver layer, I think)
an error via the return value is reported. I tried several values for the
size parameter. If it's reasonable large, for example 64 bytes, the system
stays stable. But count = 4 will trigger the bug. To be on sure side I t
> I have a system here that I want to run headless - I was thinking
> since I don't need the console on it, it might be cool to run
> oskit-mach on it.
Cool, yes. But off hand I would still recommend gnumach rather than
oskit-mach for anyone who is not actively interested in debugging an
unstabl
I guess that I see something that is 'normal', because I observerd the same
thing without my program running. As you can see, I setted a breackpoint on
ds_device_write and letted the kernel continue. After some time the
breakpoint was hit with the result: kmsg != kmsg->ikm_next->ikm_prev.
wagi
Daniel Wagner <[EMAIL PROTECTED]> writes:
> I have a question about the kmsg. Is the datastructer holding all kmsg is
> double linked circular list? I'm asking this, because I can't see it
> with gdb. For example following ikm_next and then comparing with
> the value of ikm_prev seems never to ma
> You may have to slowly track down what pages got
> used for what and how things got the way they are.
I have a question about the kmsg. Is the datastructer holding all kmsg is
double linked circular list? I'm asking this, because I can't see it
with gdb. For example following ikm_next and then
On Thu, 22 Nov 2001, Roland McGrath wrote:
> Does your program use device_write or device_write_inband? Try making both
Yes, it used device_write. I have changed it to use device_write_inband
with the result that my programm crashes:
gauss:/mnt/newton/cache/hurd/oskit-mach-debug# ./xmit -r et
> (gdb) p/x *kmsg
> $1 = {ikm_next = 0x4081700, ikm_prev = 0xff10, ikm_size = 0x100,
> ikm_marequest = 0x0, ikm_header = {msgh_bits = 0x80001200, msgh_size = 0xa0,
> msgh_remote_port = 0x0, msgh_local_port = 0x4, msgh_seqno = 0x5,
> msgh_id = 0x7788}}
If this is right (and it loo
On Tue, 20 Nov 2001, Roland McGrath wrote:
> I take it your second program uses device_set_filter on its own to select
> some of the packets.
Yes, that's right.
> First, by
> program should both be sending and receiving packets. We need to figure
> looking in the mach_msg_trap frame, you can s
I take it your second program uses device_set_filter on its own to select
some of the packets. That should be perfectly valid and both your program
and pfinet should get copies of each packet.
I'd like to understand better exactly what is happening when the kernel
crashes, and I don't think it s
On Sun, 28 Oct 2001, Roland McGrath wrote:
> It seems likely that this crash is due to improper reentrance. I am
> suspicious of your other patch, because the situation it disables the check
> for is just the kind of situation I would suspect in this kind of lossage.
As you have foreseen, attac
The patch removes the not needed assertion.
wagi
2001-11-15 Daniel Wagner <[EMAIL PROTECTED]>
* oskit/osenv_mem.c (free_for_oskit): Don't test for the
OSENV_NONBLOCKING flag. Instead decide on the address which flavor
of memory is to be freed.
Index: osenv_mem.
> The question was: How do I allocate memory? I'm asking this, because
> there might be a difficulty at this point. We can not use kfree to free
> some memory, so kalloc would fail also, right?
It's the context that's not clear. There are numerous kinds of memory
allocation. The only kinds that
> I'm not really following your question. If you are not hitting this panic
> now, then let's not worry about it until you do.
The question was: How do I allocate memory? I'm asking this, because
there might be a difficulty at this point. We can not use kfree to free
some memory, so kalloc would
I'm not really following your question. If you are not hitting this panic
now, then let's not worry about it until you do.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> panic ("free_for_oskit of virtual memory from interrupt level");
>
> If that happens, we'll have to come up with some hairy solution. That's
> because you can't call kfree at interrupt level, so we'd need to maintain a
> to-be-freed list at interrupt level and process it later and it w
On Tue, 06 Nov 2001, Roland McGrath wrote:
> No, that doesn't quite make sense. The mflags argument to
Of course :)
> Try changing that kmalloc call to use __GFP_HIGH instead (that's what
> GFP_ATOMIC is defined to in oskit/linux/src/include/linux/mm.h).
Using __GFP_HIGH helped. So it seems d
No, that doesn't quite make sense. The mflags argument to
oskit_skbufio_mem_alloc uses OSENV_* flag bits, not GFP_* flag bits.
kmalloc needs GFP_* flag bits. However, note the assert early in
oskit_skbufio_mem_alloc, so you know mflags is always just OSENV_NONBLOCKING.
So just calling it with G
On Mon, 05 Nov 2001, Roland McGrath wrote:
> You said "fixing kmalloc was easy", but I didn't see you post any change to
> the oskit code. I'm not at all sure that kmalloc should change.
Ok, here is what I fixed. mflags is passed to oskit_skufio_mem_alloc but
it is not passed to kamlloc. If it
You said "fixing kmalloc was easy", but I didn't see you post any change to
the oskit code. I'm not at all sure that kmalloc should change.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> On Mon, 29 Oct 2001, Daniel Wagner wrote:
>
> > oskit and not for oskit-mach. So I will write a patch for oskit and then
> > I'll see what happends.
>
> It seems that the oskit wrappers for kmalloc and kfree don't pass the
> right flags to oskit_linux_mem_alloc and oskit_linux_mem_free.
I w
On Mon, 05 Nov 2001, Daniel Wagner wrote:
> On Mon, 29 Oct 2001, Daniel Wagner wrote:
>
>
> Fixing kmalloc was easy, but I've some problems with kfree. kfree takes
Oops, it should be oskit_skbufio_mem_alloc and not kmalloc. Here is the
bt for freeing memory:
#0 panic (
fmt=0x209960 "../.
On Mon, 29 Oct 2001, Daniel Wagner wrote:
> oskit and not for oskit-mach. So I will write a patch for oskit and then
> I'll see what happends.
It seems that the oskit wrappers for kmalloc and kfree don't pass the
right flags to oskit_linux_mem_alloc and oskit_linux_mem_free.
Fixing kmalloc was
Hi Roland!
On Sun, 28 Oct 2001, Roland McGrath wrote:
> It seems likely that this crash is due to improper reentrance. I am
> suspicious of your other patch, because the situation it disables the check
> for is just the kind of situation I would suspect in this kind of lossage.
Hmm, but the ke
It seems likely that this crash is due to improper reentrance. I am
suspicious of your other patch, because the situation it disables the check
for is just the kind of situation I would suspect in this kind of lossage.
I am not going to be comfortable with any tweak-around-the-edges approach
to
On Sat, Oct 13, 2001 at 03:58:40PM -0400, Roland McGrath wrote:
> > in oskit-mach, the RSS for the oskit-mach kernel in proc is bogus:
> > 0159744
Damn. I meant to type -159744.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann
On Sat, Oct 13, 2001 at 03:58:40PM -0400, Roland McGrath wrote:
> > in oskit-mach, the RSS for the oskit-mach kernel in proc is bogus:
> > 0159744
> >
> > The vmem size seems to be okay with 122M. The user time is 0, which also
> > seems to be bogus, while the system time is okay.
>
> Uh, ok.
> in oskit-mach, the RSS for the oskit-mach kernel in proc is bogus:
> 0159744
>
> The vmem size seems to be okay with 122M. The user time is 0, which also
> seems to be bogus, while the system time is okay.
Uh, ok. Are the numbers more pleasing in gnumach? I can't think of any
reason they sh
On Sun, Oct 07, 2001 at 05:53:53PM -0400, Roland McGrath said:
> I put your code into oskit-mach with some small changes.
> Please test the code currently in CVS and send any fixes relative to that.
I tried the networking code from CVS (checked out today), and it works
for me with a quick test (p
On Tue, Oct 09, 2001 at 01:22:20AM +0200, Daniel Wagner said:
> Hello
>
> When compiling oskit-mach without any optimation, the linker will
> complain about cli not defined in oskit-mach/i386/i386/pic.c. Compiling
> with -O2 helps, but then gdb is confused. Gdb doesn't know where the
> current pc
> When compiling oskit-mach without any optimation, the linker will
> complain about cli not defined in oskit-mach/i386/i386/pic.c. Compiling
> with -O2 helps, but then gdb is confused. Gdb doesn't know where the
> current pc refers to the right source file. Something seems to be
> broken, but wha
I put your code into oskit-mach with some small changes.
Please test the code currently in CVS and send any fixes relative to that.
Thanks again,
Roland
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Thanks.
Is the following patch acceptable for checkin?
2001-10-02 Gordon Matzigkeit
* Makefile.in (clean): Don't remove acconfig.h and cpus.h.
From Daniel Wagner <[EMAIL PROTECTED]>.
diff -u -r1.22.2.12 Makefile.in
--- Makefile.in 2001/08/17 09:03:30 1.22.2.12
+++ Makefi
On Tue, 02 Oct 2001, Gordon Matzigkeit wrote:
> cpus.h appears to be the only file that's being missed.
If you do 'make clean' it will be deletet because the
clean rule deletes all header files in the build directory.
I changed Makefile.in this way:
nr_headerfiles = config.h cpus.h
headerfil
It's still working! And it's much more faster than before, since there are no
blockings in the traphandler anymore. I hope that's still correct. I also changed
all enable/disable calls from intr to softintr.
> I'm glad to hear it's working for you, but that's still not quite the way
> I'd like t
I'm glad to hear it's working for you, but that's still not quite the way
I'd like to see it. (The only errors I see are in the conservative
direction, i.e. it works fine, it just blocks interrupts more of the time
than it needs to.) Again, thanks a lot for hacking on this and being so
receptive
Good news. The applied patch seems to work correctly. I tested oskit-mach
for about an hour with a stress test. No panics:)
Please look through the patch, and tell me how far away from a good patch
I am.
wagi
Index: osenv_timer.c
==
On Sun, 23 Sep 2001, Roland McGrath wrote:
> I haven't thought through in full detail what your code does. But I think
> it is dubious in fundamental ways. I don't understand the rationale behind
> using base_irq_soft* and diddling with osenv_intr_*.
I copied everything direct from oskit itsel
First, a trivial thing (typo): Your softclock_oskit code calls
base_irq_softint_enabled where you want base_irq_softint_enable.
I haven't thought through in full detail what your code does. But I think
it is dubious in fundamental ways. I don't understand the rationale behind
using base_irq_sof
Ok, here is my first attempt. White the patch below oskit-mach should
work. Unfortunately there is a (some?) bug(s). Under heavy net load
oskit-mach traps after some time. Maybe someone know what I have done wrong.
wagi
Index: pc/osenv_timer.c
==
Finaly, I managed to it get working! Roland, your tips were excactly
what I needed! Many thanks. I will send a patch after I have clean up
the new code. Right now it's just a big hack, but still it works :)
cheers,
wagi
--
Daniel Wagner
email: [EMAIL PROTECTED]
GnuPG: 1024D/DCDE890A (public ke
On Tue, Jul 10, 2001 at 12:19:16AM -0400, Roland McGrath wrote:
> > I've always supposed that Roland didn't include the DC_NO_ONLCR flag on
> > purpose, if not I hope he accepts your patch.
>
> That's right (I even added that flag to the oskit just for this use). You
> don't want the oskit doing
> I checked out oskit-mach from CVS and linked it with oskit-0.97.20010214
> that I got from the debian archive. It boots and seems to work. It
> recoginses everything and even gets to starting up the system servers.
Great! I suggest that everyone use this oskit version then. I don't think
ther
On Mon, Jul 09, 2001 at 10:10:42PM +0200, Jeroen Dekkers wrote:
> I tried old version of both oskit-mach and oskit (Jeff suggested me that on
> irc), oskit-mach works almost with version 2505 and with version 2901
> I get IRQ probing problems. Oskit-mach linked with oskit-2505 doesn't
On Thu, May 31, 2001 at 04:24:35PM -0400, Roland McGrath wrote:
> Please try this patch, which I have just checked in.
You forgot to move "#include " to the top of the file.
Jeroen Dekkers
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.or
Thanks for finding that. It looks like the last time I was hacking on
oskit-mach SMP, I left it so that the only thing that would boot was a
kernel compiled for SMP and booted on a uniprocessor! Heh.
Please try this patch, which I have just checked in.
Index: mp_desc.c
===
On Tue, May 29, 2001 at 05:02:29PM -0400, Roland McGrath wrote:
> This probably the first time interrupts have been enabled since early in
> the boot process. There will immediately be a clock interrupt, since one
> surely fired a little bit earlier and was blocked until the "sti" insn.
> There m
> After rebooting a lot of times (I should really get a serial cable to do
> remote debugging) I found out that the sti instruction near the of the
> function is causing the troubles. At the moment I've no idea what's wrong, I
> have to read a lot of documentation and code before knowing what's
On Sat, May 26, 2001 at 07:59:50PM -0400, Roland McGrath wrote:
> > I've just pulled the oskit-mach source from CVS build it and tried to
> > boot it. Unfortunately, it didn't work.
>
> Well, I'm very glad that you are trying and are interested in debugging it.
>
I'm interested in developing i
> I've just pulled the oskit-mach source from CVS build it and tried to
> boot it. Unfortunately, it didn't work.
Well, I'm very glad that you are trying and are interested in debugging it.
> I've managed to track down the problem to spl0() (defined in
> i386/i386/spl.S). Here's how it happens:
On Sun, May 13, 2001 at 09:17:42PM +0200, Gibran Hasnaoui wrote:
> Sorry,
> I'm trying to get OSKit-Mach working but I have a
> problem with the generated Makefile.
> It seems that there is no target kernel: , that is needed
> by all:
oskit-kernel-ide (or something alike) seems to be a valid tar
On Thu, Dec 21, 2000 at 11:52:07PM -0500, Roland McGrath wrote:
> Someone in the Utah group just noticed that the oskit's header file
> defines CR4_PGE with the wrong value (0x20 should be 0x80).
Maybe that's why I had those problems booting with oskit-mach
unless I disabled setting the PGE flag.
On Sat, Sep 30, 2000 at 09:41:55PM -0400, Roland McGrath wrote:
> > The reboot comes from a `panic' call from the `free_for_oskit' routine
> > in [gnumach]/oskit/osenv_mem.c. Here's that piece of code:
>
> Interesting. Can you show me the stack trace? The oskit panic routine
> should print out
> The reboot comes from a `panic' call from the `free_for_oskit' routine
> in [gnumach]/oskit/osenv_mem.c. Here's that piece of code:
Interesting. Can you show me the stack trace? The oskit panic routine
should print out a stack trace. You can feed the addresses to addr2line to
get the functio
Finally, I've been able to find the source of my mysterious
reboots when booting oskit-mach.
The reboot comes from a `panic' call from the `free_for_oskit' routine
in [gnumach]/oskit/osenv_mem.c. Here's that piece of code:
--- snip ---
if (in_oskit_interrupt)
{
/* oy */
On Sun, Jul 30, 2000 at 05:31:11PM +0200, Marcus Brinkmann wrote:
> On Sat, Jul 29, 2000 at 07:05:27PM +0200, Mark Kettenis wrote:
> > You'll probably need to provide alternatives for more (all) of the
> > functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach
> > synch.c.
>
> This wo
Date: Sun, 30 Jul 2000 17:31:11 +0200
From: Marcus Brinkmann <[EMAIL PROTECTED]>
On Sat, Jul 29, 2000 at 07:05:27PM +0200, Mark Kettenis wrote:
> You'll probably need to provide alternatives for more (all) of the
> functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach
On Sat, Jul 29, 2000 at 07:05:27PM +0200, Mark Kettenis wrote:
> You'll probably need to provide alternatives for more (all) of the
> functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach
> synch.c.
This would be osenv_intr_save_disable(), which is the only one not defined i
oskit-ma
You'll probably need to provide alternatives for more (all) of the
functions in oskit-0.97.2505/dev/x86/synch.c in the oskit-mach
synch.c.
Mark
94 matches
Mail list logo
