Re: Testing requested for the next version of GNU Mach

Richard Braun, on Tue 15 Mar 2016 00:40:40 +0100, wrote: > On Tue, Mar 15, 2016 at 12:32:43AM +0100, Samuel Thibault wrote: > > Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > > > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > > > After poking around a bit more, it

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 15, 2016 at 12:32:43AM +0100, Samuel Thibault wrote: > Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > > After poking around a bit more, it seems that the space is eaten by > > > debug info. Appending -g0

Re: Testing requested for the next version of GNU Mach

Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > After poking around a bit more, it seems that the space is eaten by > > debug info. Appending -g0 to CFLAGS allowed gnumach to boot > > successfully and resulted in this:

Re: Testing requested for the next version of GNU Mach

On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > The realtek board shouldn't be working without DDE... Something looks > > wrong in your test setup. > > I've been using it almost exclusively for the last three or four years > without DDE. It works fine for me until I try to

Re: Testing requested for the next version of GNU Mach

On Sun, Mar 13, 2016 at 9:06 AM, Richard Braun wrote: > On Fri, Mar 11, 2016 at 05:38:06PM -0500, David Michael wrote: >> I didn't get a chance to try with Debian yet, but after looking a bit >> more, the failure I'm getting is from linux_kmem_init() allocating >> memory. It

Re: Testing requested for the next version of GNU Mach

On Fri, Mar 11, 2016 at 05:38:06PM -0500, David Michael wrote: > I didn't get a chance to try with Debian yet, but after looking a bit > more, the failure I'm getting is from linux_kmem_init() allocating > memory. It panics in vm_page_grab_contig() when allocating the 29th > (i=28) chunk. This

Re: Testing requested for the next version of GNU Mach

David Michael, on Fri 11 Mar 2016 17:38:06 -0500, wrote: > but I will try to see what Debian is doing differently over the > weekend. Debian simply doesn't use those drivers any more, but netdde instead. Samuel

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 08, 2016 at 12:15:25PM -0500, David Michael wrote: > I've just removed linux/src/drivers/net/rtl8139.c and dropped all > references to rtl8139 from the following files Please use --disable-rtl8139 instead, and only use GRUB as configured by Debian so that we restrict the variables of

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 8, 2016 at 10:00 AM, David Michael wrote: > On Tue, Mar 8, 2016 at 5:06 AM, Richard Braun wrote: >> In any case, this isn't a regression caused by my work, and I don't >> intend to fix in-kernel drivers, in particular when we have a good >>

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 8, 2016 at 5:06 AM, Richard Braun wrote: > In any case, this isn't a regression caused by my work, and I don't > intend to fix in-kernel drivers, in particular when we have a good > user space replacement. As a result, I suggest we remove the rtl8139 > driver from

Re: Testing requested for the next version of GNU Mach

On Mon, Mar 07, 2016 at 11:01:47PM -0500, David Michael wrote: > Yes, this was when booting gnumach in QEMU with -device rtl8139 for a > net device. Here is the situation : At some point in 2006 (but apparently merged in 2009), netdrivers, the network drivers written by Donald Becker, were

Re: Testing requested for the next version of GNU Mach

On Mon, Mar 7, 2016 at 8:56 PM, Richard Braun wrote: > On Tue, Mar 08, 2016 at 12:00:03AM +0100, Richard Braun wrote: >> On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: >> > Yes, that did it. The latest gnumach can be booted with GRUB when >> > those options are

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 08, 2016 at 12:00:03AM +0100, Richard Braun wrote: > On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: > > Yes, that did it. The latest gnumach can be booted with GRUB when > > those options are disabled. > > It seems we've been having this bug for a long time, but noone

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: > On Sun, Feb 28, 2016 at 3:37 PM, Richard Braun wrote: > > On Sun, Feb 28, 2016 at 03:27:50PM -0500, David Michael wrote: > >> The same GRUB has no problem booting older gnumach (bee3f0) or Linux. > >> Are you aware

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 03:50:06PM -0500, David Michael wrote: > > It's not related to GRUB at all apparently. My guess is something got > > wrong in the Linux glue code for in kernel drivers. Could you build > > gnumach with --disable-net-group --disable-pcmcia-group > > --disable-wireless-group

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 3:37 PM, Richard Braun wrote: > On Sun, Feb 28, 2016 at 03:27:50PM -0500, David Michael wrote: >> The same GRUB has no problem booting older gnumach (bee3f0) or Linux. >> Are you aware of any patches required by GRUB to boot the X15 >> multiboot/biosmem

Re: Testing requested for the next version of GNU Mach

On Sun, Feb 28, 2016 at 03:27:50PM -0500, David Michael wrote: > The same GRUB has no problem booting older gnumach (bee3f0) or Linux. > Are you aware of any patches required by GRUB to boot the X15 > multiboot/biosmem bits? Thanks for your report. It's not related to GRUB at all apparently. My

Re: Testing requested for the next version of GNU Mach

Hi, I haven't been able to boot gnumach with upstream GRUB since this X15 code was imported. It does boot successfully with QEMU's multiboot arguments, and it seems fine when it's running. When booting the latest gnumach (689810) with GRUB (both old versions and today's beta3 release) built for

Testing requested for the next version of GNU Mach

Hello, As part of the next GNU Mach release, the physical allocator has been completely changed in favor of a more standard buddy allocator (finally) and the kernel allocator can service much more memory for its objects, making kernel memory exhaustion very unlikely. Considering we can now