Hi Finn,
>> Don't know about Mac,
>
> It may be possible to boot Linux with MacOS running in 24-bit mode, and
> ISTR that this leads to a large number of memory chunks. The Penguin
The chunk size would still be 16 MB, perhaps?
(Unless Geert is right and interleaving means multiple small memory
c
Hi Finn,
On Tue, Apr 1, 2014 at 2:23 PM, Finn Thain wrote:
>> but I have some memories of interleaved banks and such...
>
> There are some Mac models with memory controllers that do interleaving. I
> don't know whether interleaving is relevant here.
I meant that if you have e.g. 16 MiB of RAM, b
On Tue, 1 Apr 2014, Geert Uytterhoeven wrote:
> On Tue, Apr 1, 2014 at 1:52 AM, Michael Schmitz wrote:
> > > > do we know the size of the first memory chunk early enough in
> > > > head.S? Maybe it's time to increase INIT_MAPPED_SIZE at least in
> > > > cases where we know that there's more tha
schmitz writes:
> What size FastRAM did precipitate that bug for you, Andreas?
It's the combination of kernel size and FastRAM setting that matters.
You can easily watch it by adding the bootmem_debug kernel parameter.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 5
schmitz dixit:
> Didn't dak use to do that, too?
I’ve got no idea; I was a Debian user back in slink times when APT
was new and highly experimental and discouraged ;) and then only
in modern times. Lots of BSD in between, though.
bye,
//mirabilos
--
Ich gebs zu, jupp ist cool
-- theftf
Hi Geert,
Hi Michael,
On Tue, Apr 1, 2014 at 9:39 AM, schmitz
wrote:
On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz
wrote:
do we know the size of the first memory chunk early enough in head.S?
Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
we know that ther
Hi Michael,
On Tue, Apr 1, 2014 at 10:12 AM, schmitz
wrote:
> While poking around in head.S, I came across a comment that stated the
> second page at the start of the kernel is used for the kernel page dir -
> that is the second page of virtual address space (FastRAM, in the case we
> care about
Thorsten,
① The other sort of removals (drop binary packages that are no
longer built from source packages when a new upload of any binary
packages from that source package happens), dpo mini-dak does
*too* eagerly: it doesn’t check if the old binary package is
still depended on before it
Hi Geert,
do we know the size of the first memory chunk early enough in head.S?
Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
we know that there's more than 4 MB in the first memchunk ...
How do you know? You would have to reimplement the check paging_init
does
Hi Geert
Hi Michael,
On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz wrote:
do we know the size of the first memory chunk early enough in head.S?
Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
we know that there's more than 4 MB in the first memchunk ...
"get_
Hi Michael,
On Tue, Apr 1, 2014 at 9:45 AM, schmitz
wrote:
> do we know the size of the first memory chunk early enough in head.S?
> Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
> we know that there's more than 4 MB in the first memchunk ...
How do yo
Hi Michael,
On Tue, Apr 1, 2014 at 9:39 AM, schmitz
wrote:
>> On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz
>> wrote:
>>> do we know the size of the first memory chunk early enough in head.S?
>>> Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
>>> we know that there's mo
Ondrej Riha dixit:
>linux-headers-2.6-* and linux-image-2.6-* and linux-doc-2.6-*
These packages no longer exist, they have been removed from unstable.
Debian-Ports mini-dak does not generally follow this sort¹ of removals
automatically, so they will eventually be cleaned up manually.
The packa
Hi Michael,
On Tue, Apr 1, 2014 at 1:52 AM, Michael Schmitz
wrote:
>> Michael Schmitz writes:
>> > do we know the size of the first memory chunk early enough in head.S?
>> > Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
>> > we know that there's more than 4 MB in the first
Hi Michael,
On Mon, Mar 31, 2014 at 11:24 PM, Michael Schmitz wrote:
> do we know the size of the first memory chunk early enough in head.S?
> Maybe it's time to increase INIT_MAPPED_SIZE at least in cases where
> we know that there's more than 4 MB in the first memchunk ...
"get_bi_record BI_ME
15 matches
Mail list logo