Hi,
Thomas Schwinge, le Wed 25 Apr 2007 18:45:44 +0200, a écrit :
> diff -N i386/i386/io_perm.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ i386/i386/io_perm.c 25 Apr 2007 16:36:32 -
...
> +kern_return_t
> +i386_io_perm_create (ipc_port_t master_port, io_port_t from, io_port_t to,
> +
Hello!
I think there's some misunderstanding or miscommunication here.
On Wed, Apr 25, 2007 at 12:14:56PM -0700, Roland McGrath wrote:
> The skips are there because those msgids were used for something different
> in the past. It's best not to reuse them.
I'm aware of that and in fact that's ex
The skips are there because those msgids were used for something different
in the past. It's best not to reuse them.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
ily provide it.
I worked on integrating Marcus's work into the GNU Mach branch and did
not really check that all the low level details are correct -- I would
assume that checking those has been done at the time Marcus's patch was
installed into the OSKit-Mach branch.
With this patch
to
gnumach-1-branch: i386_set_gdt, i386_get_gdt'']
* i386/include/mach/i386/mach_i386.defs (i386_set_gdt, i386_get_gdt):
Shift by two to maintain rpc id compatibility with OSKit-Mach.
#v-
Regards,
Thomas
signature.asc
Description: Digital signature
_
Hi,
Thomas Schwinge, le Wed 25 Apr 2007 15:32:28 +0200, a écrit :
> As there is already at least one person (Samuel) to use the
> `i386_set_gdt' and `i386_get_gdt' routines on GNU Mach (in glibc)
I'm not using it: the code in glibc is still not enabled. I'd say
gnumach1 should be fixed instead.
ask #5878 --- ``Backport code from GNU Mach's trunk to
> gnumach-1-branch: i386_set_gdt, i386_get_gdt'']
>
> * i386/include/mach/i386/mach_i386.defs (i386_set_gdt,
> i386_get_gdt):
> New routines.
> [...]
This patc
Hello!
On Tue, Apr 24, 2007 at 03:04:26PM +0200, Richard Braun wrote:
> On Tue, Apr 24, 2007 at 02:50:52PM +0200, Thomas Schwinge wrote:
> > Okay, a new zalloc zone would be overkill, but I've implemented a tiny
> > new kernel object, lumped it all together -- and it even works, it seems!
> >
> >
On Tue, Apr 24, 2007 at 02:50:52PM +0200, Thomas Schwinge wrote:
> Okay, a new zalloc zone would be overkill, but I've implemented a tiny
> new kernel object, lumped it all together -- and it even works, it seems!
>
> But then noticed that I had forgotten to deallocate the kernel object's
> `kallo
Hello!
Continuing my monologue...
On Wed, Apr 11, 2007 at 06:08:07PM +0200, I wrote:
> On Sun, Apr 08, 2007 at 12:16:25PM +0200, I wrote:
> > But where would be the correct place in GNU Mach to store these
> > ``io_port_t from, to'' values?
> >
> >
ect place in GNU Mach to store these
> ``io_port_t from, to'' values?
>
> [OSKit-Mach]/oskit/ds_oskit.h
> #v+
> struct device {
> [...]
> union {
> struct {
> oskit_blkio_t *io;
> oskit_u32_t size; /* block size */
> #define MA
On Mon, Apr 02, 2007 at 01:26:51PM -0700, Roland McGrath wrote:
> The old device_emulation_ops stuff in i386at is similar,
> i.e. it provides hooks to implement the device RPCs.
But where would be the correct place in GNU Mach to store these
``io_port_t from, to'' values?
[O
Hello!
On my endavor to understand the MIG magic better, I stumbled over the
following:
On Fri, Mar 08, 2002 at 01:39:49AM +0100, Marcus Brinkmann wrote:
> [...]
i386/include/mach/i386/mach_i386.defs
> +type io_port_t = MACH_MSG_TYPE_INTEGER_16;
> +type io_perm_t = mach_port_t
> +
The old device_emulation_ops stuff in i386at is similar,
i.e. it provides hooks to implement the device RPCs.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Hello!
Since it's been six and a half years, let me first give some context
here...
On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> here is a patch to implement I/O permission control in OSKit-Mach.
>
> What do you get?
>
>
"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 lot
[ I've CCed John Tobey as I'm not sure if he has assigned the
copyright. ]
Hi,
Long time ago we got a bug report in Debian with a patch for Oskit
Mach. Here it is:
In gnumach/oskit/osenv_mem.c, consider_lmm_collect() looks as if it
can stop short of transfering the optimal numbe
> Soeren D. Schulze wrote:
> >>It just won't die! :-)
> > Could you tell how you exactly got it working? I tried the binary on
> > this machine (i686) naively with
> >
> > title Debian GNU/Hurd Mach 2
>
> root (hd0,1)
>
> > kern
On Sat, Apr 16, 2005 at 08:28:46PM +0200, Soeren D. Schulze wrote:
> Could you tell how you exactly got it working? I tried the binary on
> this machine (i686) naively with
>
> kernel (hd0,1)/boot/oskit-mach-2005-04-13 root=device:hd0s2
>
> and it rebooted immediatly after
Soeren D. Schulze wrote:
It just won't die! :-)
Could you tell how you exactly got it working? I tried the binary on
this machine (i686) naively with
title Debian GNU/Hurd Mach 2
root (hd0,1)
kernel (hd0,1)/boot/oskit-mach-2005-04-13 root=device:hd0s2
kernel /boot/oskit-mach-2005-04-13
> Michael Banck wrote:
> > Anybody tried to build oskit-mach recently and could tell me which
> > compiler/configure options/patches to use? I have attached the oskit
> > modules file (I also tried another one, with the same result).
>
> Actually, being the stubborn h
Joachim Nilsson wrote:
> Actually, being the stubborn hard-ass that I am I managed to build and
> successfully boot oskit-mach today. It's weird, but I've put up the
> resulting kernel, build scripts and modules file, free for testing at
Amazing :-)
> It just won't d
Michael Banck wrote:
Anybody tried to build oskit-mach recently and could tell me which
compiler/configure options/patches to use? I have attached the oskit
modules file (I also tried another one, with the same result).
Actually, being the stubborn hard-ass that I am I managed to build and
Michael Banck wrote:
I get this error on two different machines, a P2-400 and a P-M-1500.
Marco told me that this error is also experienced by several other
people.
Yes, I've often experienced this on some machines too. There were some
clues in the mailing lists, but I couldn't find them with Goo
Hi Michael!
It was ages since I did any work with OSKit-Mach, glad to see
that someone is still trying. Ognyan and I once fiddled around
with these pages on the wiki, now and again I see Ognyan poking
with them:
http://hurd.gnufans.org/bin/view/Mach/BuildingOskitMach
http
Hello,
I tried to build and run oskit-mach today. Building (see below) went
fine, but when I try to boot it, I get the following (transcribed):
Welcome to GNU Mach 1.91!
Kernel page fault at address 0x1, eip = 0x1
Kernel Page fault trap, eip 0x1
kernel trap, type 14, code = 0
Dump of trap_state
First of all I appologise for the horrible late reply, but better late
then never, eh?
It looks like an interrupt routine is causing the SEGV? (eip is
0x1, wouldn't this be in the x86 interrupt vector?, would that
explain why the backtrace cant give specific info?)
Well, the info in fram
Hi,
I occasionally ask this question but no one ever answers. Time has
come to try again :)
I have two problems that may or may not be related. I'm running
oskit/mach (GNUmach 2.0) from up to date CVS ('cvs up' for both oskit
and mach last night).
The first problem is tha
Using the OSKIT patch I submitted earlier today (and modifying
oskit/dev/linux_ethernet.h for my network card), I successfully compiled
oskit-mach using 'make kernel-ide+floppy+ethernet_rtl8139'.
When I boot, I get the following output:
Welcome to GNU Mach 1.91!
Kernel page fault
This patch adds oskit/libc/string/stpcpy.c to the OSKIT source. This
adds this function to the minimal oskit c library liboskit_c.a, so that
the call to stpcpy from gnumach/oskit/ds_bus.c line 46 succeeds on linking.
diff -Nrup oskit.orig/libc/string/stpcpy.c oskit/libc/string/stpcpy.c
--- os
On Tue, Feb 18, 2003 at 08:04:01PM +0100, Peter 'p2' De Schrijver wrote:
>
> Ok. Any idea were I can find one more recent than the debian packages on
> alpha.gnu.org ?
I had a look at this a while ago, i think the only working version is in CVS.
i hadn't time to check it. if you verify that vers
Hi Marcus,
On Sun, Feb 16, 2003 at 02:18:29PM +0100, Marcus Brinkmann wrote:
> On Sun, Feb 16, 2003 at 01:29:26PM +0100, Peter 'p2' De Schrijver wrote:
> > Hi,
> >
> > I'm trying to get marcus' console to run on hurd with oskit mach. I get
> > an
On Sun, Feb 16, 2003 at 01:29:26PM +0100, Peter 'p2' De Schrijver wrote:
> Hi,
>
> I'm trying to get marcus' console to run on hurd with oskit mach. I get
> an illegal instruction exception at the first outb instruction. It seems
> the process does not have th
Hi,
I'm trying to get marcus' console to run on hurd with oskit mach. I get
an illegal instruction exception at the first outb instruction. It seems
the process does not have the correct I/O permissions to access the VGA
card. Has anyone tried this before ? I'm running the latest v
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I think this usually points to a small typo in the GRUB boot script. Mach
> is extremely picky about it, and it doesn't provide useful diagnostics on
> certain errors. Fixing that would be nice.
A small workaround could be to provide a small script
On Fri, Jan 31, 2003 at 11:34:21AM +0200, Ognyan Kulev wrote:
> Hi,
>
> I have 440BX motherboard with PCI CMD649 ATA-100 controller. All my GNU
> Mach 2 kernels stop at this assertion:
>
> ../gnumach/ipc/ipc_port.c:1126: failed assertion `port->ip_srights > 0'
I think this usually points to a s
Hi,
I have 440BX motherboard with PCI CMD649 ATA-100 controller. All my GNU
Mach 2 kernels stop at this assertion:
../gnumach/ipc/ipc_port.c:1126: failed assertion `port->ip_srights > 0'
It seems that it's triggered right after GNU Mach 2 tries to execute
ext2fs.static. GNU Mach 1.x from the t
--- 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 -
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 22 Jan 2003 19:51:48 -
@@ -329,7 +329,7 @@
kernel-%.o
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 22 Jan 2003 19:51:48 -
@@ -329,7 +329,7 @@
kernel-%.o
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
I doscovered today that oskit-mach is unhappy when the system has no
floppy drive controller. gnumach1 works fine.
Roland: You had mentioned that you might consider spending some time to
update the Oskit to 2.4 drivers. Do you have a timeframe for that? If
it's not soon, I might see if
Joachim Nilsson <[EMAIL PROTECTED]> writes:
> 1. Change the OSKit version dependency in configure.in to,
> at least, NEEDED_OSKIT_VERION=20010214. The changes for
Yes, that's not a bad idea.
> 2. When I build an optimized kernel, only IDE and one
> ethernet card, e
Hello!
I have a couple of small suggestions regarding the build of GNUmach2
(oskit-mach). These are just simple stuff that I've found a bit annoying.
My make-fu is too weak [1] for me to present a patch though.
1. Change the OSKit version dependency in configure.in to,
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
Hi,
I am trying to figure out why the oskit/mach I built isn't working:
I get the following:
(gdb) p cmd->path
$4 = 0x2127 "/lib/ld.so.1"
(gdb) p cmdline
$5 = 0x1e13504 "/lib/ld.so.1"
boot_script_exec_cmd (hook=0x2, task=0x1e12c3c, path=0x2127
"/lib/ld.so.
Btw, I tried compiling oskit-mach using gcc-3.2 (actually RH's 3.2-7) and
it is fine with -O but breaks with -O2. I haven't looked into it, but it
shouldn't be too hard to fix (once found) since there aren't dozens of
places like drivers to worry about, just a relatively sma
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 should make the build easier for people who did not follow oskit-mach
development from the beginning and do not know this quirk. Hopefully it
does not break anything.
--
Michal Suchanek
[EMAIL PROTECTED]
diff -u -x CVS gnumach/Makefile.in gnumach-mod/Makefile.in
--- gnumach/Makefile.in Wed
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
> > The UTCB is a central information page for L4 userspace threads
> > and it's pretty difficult to find another x86 register that can
> > be used to point to it.
>
> What's wrong with %fs? But anyway, that is fine if the one word at %gs:0
> can be made available for user use. Ideally that wor
> The UTCB is a central information page for L4 userspace threads
> and it's pretty difficult to find another x86 register that can
> be used to point to it.
What's wrong with %fs? But anyway, that is fine if the one word at %gs:0
can be made available for user use. Ideally that word would be w
Roland McGrath wrote:
> > I know this is irrelevant for oskit-mach proper, but it may be
> > interesting to know if you're introducing any dependency in,
> > say, glibc/pthreads:
> >
> > In the L4 V4 spec, Appendix A (x86 Interface), register %gs
> &
> I know this is irrelevant for oskit-mach proper, but it may be
> interesting to know if you're introducing any dependency in,
> say, glibc/pthreads:
>
> In the L4 V4 spec, Appendix A (x86 Interface), register %gs
> is used to point to the UTCB of the current threa
Roland, Jeroen,
I know this is irrelevant for oskit-mach proper, but it may be
interesting to know if you're introducing any dependency in,
say, glibc/pthreads:
In the L4 V4 spec, Appendix A (x86 Interface), register %gs
is used to point to the UTCB of the current thread (read
Ah, I was thinking wrong. The segment limit field is only 20 bits, so for
segments larger than that you set the SZ_G bit and the granularity of the
limit is 4kb (fill_descriptor in oskit/x86/seg.h does this). So try making
ldt.c use VM_MAX_ADDRESS-VM_MIN_ADDRESS-PAGE_SIZE, because the fencepost
On Tue, Apr 23, 2002 at 05:00:35PM -0400, Roland McGrath wrote:
> Ah, I was thinking wrong. The segment limit field is only 20 bits, so for
> segments larger than that you set the SZ_G bit and the granularity of the
> limit is 4kb (fill_descriptor in oskit/x86/seg.h does this). So try making
> l
> 0xc004 gives the same problems. Note that the assertion was right
> in the first place, the GS segment didn't trigger it, only the DS
> segment.
Humph! You're right, the %gs:0 word should never have a fault anyway
because those pages and page tables are always in core. I backed out my
cha
On Tue, Apr 23, 2002 at 04:01:12PM -0400, Roland McGrath wrote:
> > No, the assert happens using the DS segment. Hmm, I guess something
> > more is wrong here. It looks like the segment isn't protecting us here
> > and the segmentation fault just happens because of there is nothing
> > mapped at 0
> No, the assert happens using the DS segment. Hmm, I guess something
> more is wrong here. It looks like the segment isn't protecting us here
> and the segmentation fault just happens because of there is nothing
> mapped at 0xc000 and it gets a page fault. If the segment would
> protect us we
On Tue, Apr 23, 2002 at 03:16:34PM -0400, Roland McGrath wrote:
> > On Tue, Apr 23, 2002 at 01:27:11PM -0400, Roland McGrath wrote:
> > > > When hitting the send button I recalled that I had to remove an
> > > > assert, see the patch.
> > >
> > > Thanks. I put in a modified assert; please test t
> On Tue, Apr 23, 2002 at 01:27:11PM -0400, Roland McGrath wrote:
> > > When hitting the send button I recalled that I had to remove an
> > > assert, see the patch.
> >
> > Thanks. I put in a modified assert; please test that I got it right.
>
> No, the assert gets hit when trying to access 0xc
On Tue, Apr 23, 2002 at 01:27:11PM -0400, Roland McGrath wrote:
> > When hitting the send button I recalled that I had to remove an
> > assert, see the patch.
>
> Thanks. I put in a modified assert; please test that I got it right.
No, the assert gets hit when trying to access 0xc000. I gue
> When hitting the send button I recalled that I had to remove an
> assert, see the patch.
Thanks. I put in a modified assert; please test that I got it right.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Sun, Apr 21, 2002 at 03:26:56PM -0400, Roland McGrath wrote:
> > You forgot to make the page table entries also user accessible. Other
> > than that, everything works perfect. Thank you.
>
> Great. Thanks for the fix, and thanks for testing. Have you/can you also
> test to be absolutely sure
> I tried to acces %gs:4 and this failed with an "illegal
> instruction". I also tried to access 0xc000 which got a
> segmentation fault. I don't know if I have to test more.
That's the basics. Thanks for testing it. I suppose the ideal test would
be a program that systematically explores t
On Tue, Apr 23, 2002 at 07:08:08PM +0200, Jeroen Dekkers wrote:
> On Sun, Apr 21, 2002 at 03:26:56PM -0400, Roland McGrath wrote:
> > > You forgot to make the page table entries also user accessible. Other
> > > than that, everything works perfect. Thank you.
> >
> > Great. Thanks for the fix, a
> You forgot to make the page table entries also user accessible. Other
> than that, everything works perfect. Thank you.
Great. Thanks for the fix, and thanks for testing. Have you/can you also
test to be absolutely sure that users cannot access anything but the one
word from %gs, and that the
he debian tarball Jeff made of oskit 2002, nor
my install of oskit 2002 doesn't have liboskit_smp anymore.
The other part of the patch adds consistency to all compile lines. I don't
know if I had /local/lib in my LD_LIBRARY_PATH when I compiled oskit-mach, but
I found this to be a simpler sol
On Sun, Apr 07, 2002 at 08:12:01PM -0400, Roland McGrath wrote:
> I have implemented the %gs:0 pseudo-register in oskit-mach. If you are
> already using oskit-mach, please update and try out the new code. What you
> should now see is that in user threads %gs has a different value
> 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
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
> > loca
> 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,
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)
Aside from the usual two patches, it compiled fine. However,
i386asm.symc has the following
gh the arm autobuilder should pick it up)
I do not beleive that it compiles with Gcc-3. Patches welcome (Just
file bugs against the oskit package in Debian. I will deal with them
is Ed asks me to continue hacking on this).
Because this now works, I'm now starting to provide various oskit
I have implemented the %gs:0 pseudo-register in oskit-mach. If you are
already using oskit-mach, please update and try out the new code. What you
should now see is that in user threads %gs has a different value from %ds.
You should be able to read and write one and only one word at %gs:0. This
* Marcus Brinkmann writes:
> On Sat, Mar 23, 2002 at 05:53:05PM +0100, Alfred M. Szmidt wrote:
>> Try compiling with out any optimisation..
> Never ever try that with any of the core packages in the Hurd. Use
> at least -O. In this case, -O2 works as well.
> Optimization is required to preve
On Sat, Mar 23, 2002 at 05:53:05PM +0100, Alfred M. Szmidt wrote:
>
> Try compiling with out any optimisation..
Never ever try that with any of the core packages in the Hurd.
Use at least -O. In this case, -O2 works as well.
Optimization is required to prevent some hassle with inline functions
Try compiling with out any optimisation.. Or use GCC 3.x.
--
Alfred M. Szmidt
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Sat, Mar 23, 2002 at 08:37:18AM -0800, James Morrison wrote:
> Hi,
>
> I'm trying to compile the hurd in the hurd while using oskit-mach, but I'm
> getting the following error:
> ../../libdiskfs/file-syncfs.c:61: Internal compiler error:
> ../../libdiskfs/file
Hi,
I'm trying to compile the hurd in the hurd while using oskit-mach, but I'm
getting the following error:
../../libdiskfs/file-syncfs.c:61: Internal compiler error:
../../libdiskfs/file-syncfs.c:61: internal error--unrecognizable insn:
(insn/i 112 111 113 (parallel[
> 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 d
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 report
right now. I used for this test the ne
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
--- 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.
>
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
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.
However, I did notice that my oskit-mach kernel did not boot the Hurd directly.
I had to go back to using serverboot.
2002-03-17 James A. Morrison
On Sun, Mar 10, 2002 at 10:07:32PM -0500, Roland McGrath wrote:
> The question is basically whether or not you have a free
> list for fast allocation.
Ah, ok.
> > New patch, for now without a zone for iopb's, at
> > http://www.debian.org/~brinkmd/iopb-2002-03-11.patch
>
> Go ahead and put it in
Great work!
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
> Do you think the performance increase is worth the memory overhead of a
> zone, esp if you preallocate iopb's (each being 8192 bytes huge)?
What memory overhead are you talking about? The zone_t data structure is
just a few words. The question is basically whether or not you have a free
list
On Fri, Mar 08, 2002 at 07:14:46PM -0500, Roland McGrath wrote:
> The io_bitmap_* functions can be static (and get inlined), no?
Yes, done.
> You left machine_task_zone.
Uh, removed.
> Btw, you could use a zone for the iopb's instead of
> kalloc, since they are all the same size. It's not muc
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
1 - 100 of 310 matches
Mail list logo
