Werner Almesberger <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
> > Something like that.I have yet to see a even a proof of concept
> > of the idea of passing device information, to clean up probes.
>
> Yes, the kexec-based boot loader first, then this. For a
> kexec-based boot load
On Fri, 21 Jan 2005, Catalin(ux aka Dino) BOIE wrote:
I really suggest to push this limit to 4k. My reason is that under UML I need
to put a lot of stuff in command line and uml crash if I not extend this
limit. Can we make it depend on arhitecture?
another nice feature would be the kernel ignori
Eric W. Biederman wrote:
> For detecting devices especially in the case that takes
> a while that isn't something we need to do early
> in the boot process.
Yes, but I'd rather have a generic mechanism that works in all
reasonable cases. Things have a tendency of growing in the oddest
directions.
Werner Almesberger <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
> > Actually this is trivial to do by using a file in initramfs.
> > If we need something in a well defined format anyway.
>
> Yes, constructing an additional initramfs, or modifying an existing
> one to hold such data is c
Eric W. Biederman wrote:
> Actually this is trivial to do by using a file in initramfs.
> If we need something in a well defined format anyway.
Yes, constructing an additional initramfs, or modifying an existing
one to hold such data is certainly a possibility.
I think there are mainly three choi
Werner Almesberger <[EMAIL PROTECTED]> writes:
> Andi Kleen wrote:
> > It's dependent on the architecture already. I would like to enable
> > it on i386/x86-64 because the kernel command line is often used
> > to pass parameters to installers, and having a small limit there
> > can be awkward.
>
Andi Kleen wrote:
> It's dependent on the architecture already. I would like to enable
> it on i386/x86-64 because the kernel command line is often used
> to pass parameters to installers, and having a small limit there
> can be awkward.
Something to keep in mind when extending the command line is
Matt Domsch wrote:
On Fri, Jan 21, 2005 at 08:11:44AM +0100, Andi Kleen wrote:
I really suggest to push this limit to 4k. My reason is that under UML I
need to put a lot of stuff in command line and uml crash if I not extend
this limit. Can we make it depend on arhitecture?
It's dependent on the
On Fri, Jan 21, 2005 at 08:11:44AM +0100, Andi Kleen wrote:
> > I really suggest to push this limit to 4k. My reason is that under UML I
> > need to put a lot of stuff in command line and uml crash if I not extend
> > this limit. Can we make it depend on arhitecture?
>
> It's dependent on the ar
> I really suggest to push this limit to 4k. My reason is that under UML I
> need to put a lot of stuff in command line and uml crash if I not extend
> this limit. Can we make it depend on arhitecture?
It's dependent on the architecture already. I would like to enable
it on i386/x86-64 because t
On Thu, 20 Jan 2005, Andi Kleen wrote:
AOL:
- lilo 22.6.1
- CONFIG_EDD=y
- 2.6.10-mm1 and 2.6.11-rc1 did boot
- 2.6.11-rc1-mm1 and 2.6.11-rc1-mm2 didn't boot
- 2.6.11-rc1-mm2 with this ChangeSet reverted boots.
What I gather so far the problem seems to only happen with lilo
and EDID together. grub
On Thu, 20 Jan 2005, Adrian Bunk wrote:
>
> On Thu, Jan 20, 2005 at 12:13:22AM +0100, Janos Farkas wrote:
> >
> > Isn't this define a lilo dependence?
>
> AOL:
> - lilo 22.6.1
> - CONFIG_EDD=y
> - 2.6.10-mm1 and 2.6.11-rc1 did boot
> - 2.6.11-rc1-mm1 and 2.6.11-rc1-mm2 didn't boot
> - 2.6.11-rc
> AOL:
> - lilo 22.6.1
> - CONFIG_EDD=y
> - 2.6.10-mm1 and 2.6.11-rc1 did boot
> - 2.6.11-rc1-mm1 and 2.6.11-rc1-mm2 didn't boot
> - 2.6.11-rc1-mm2 with this ChangeSet reverted boots.
What I gather so far the problem seems to only happen with lilo
and EDID together. grub appears to work. Or did
On Thu, Jan 20, 2005 at 12:13:22AM +0100, Janos Farkas wrote:
> Hi Andi!
>
> I had difficulties booting recent rc1-bkN kernels on at least two
> Athlon machines (but somehow, on an *old* Pentium laptop booted with the
> a very similar system just fine).
>
> The kernel just hung very early, just
FYI, I found that the problem I was having was caused by the "BIOS Enhanced
Disk Drives" turned on. It was on in previous versions as well, and they
worked ok, so I assume that something has changed. In anycase turning it off
fixed my problem.
Chris Bruner
On Wed January 19 2005 06:13 pm, Ja
Hi Andi!
I had difficulties booting recent rc1-bkN kernels on at least two
Athlon machines (but somehow, on an *old* Pentium laptop booted with the
a very similar system just fine).
The kernel just hung very early, just after displaying "BIOS data check
successful" by lilo (22.6.1). Ctrl-Alt-Del
16 matches
Mail list logo
