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
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
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.
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.
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
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 loader,
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
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
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.
>
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.
Something
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 certainly
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
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
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
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
> 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
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.
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
> -
> 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
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 after
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, 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-rc1-mm2 with
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.
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 the
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,
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).
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
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,
31 matches
Mail list logo
