Jeremy Fitzhardinge wrote:
>
> Interesting. I haven't really been following this thread, but doesn't
> it mean something isn't being initialized properly if this patch makes a
> difference?
>
Specifically boot_params.screen_info isn't being properly set up by the
caller.
-hpa
_
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
YH
___
Virtualization mailing list
Virtualization
yhlu wrote:
> On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> You might try a git-bisect, or if it is just these patches
>> walking through them one-by-one.
>
> f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
> commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
> Author: Gerd H
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann <[EMAIL PROTECTE
Herbert Xu wrote:
> Sorry, I had forgotten that I've already concluded previously that
> this doesn't work because we don't want to prevent the interface
> from being brought up (and other reasons). My memory is failing me :)
>
> So I think the best option now is to get rid of the delay on carrier
yhlu <[EMAIL PROTECTED]> writes:
> Eric,
>
> i tried to load vmlinux with kexec and got
> Ramdisks not supported with generic elf arguments
>
> So i use mkelfImage with my patch ( convert elf64 to elf32) to make
> another elf32. and loaded with kexec and can not get vga console too.
> ---serial co
the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj
YH
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foun
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.
the mkelfImage 2.7 patch is
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
setup.S is never executed while doing kexec (unless somebody chooses to
do a real mode entry) and these patches don't change this beahviour.
Tomorrow I will test VGA behaviour on my machine. Are you using some
special frame buffer mode etc?
I
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Yes. setup.S has always been skipped by bzImage via the kexec path
unless you explicitly tell /sbin/kexec to use the 16bit entry point.
Is not having a VGA console a new thing, or it something you just noticed?
Eric
before the changes,
On Tue, May 08, 2007 at 09:41:09AM -0700, yhlu wrote:
> On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >Vivek Goyal <[EMAIL PROTECTED]> writes:
> >
> >> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
> >>> Jeremy Fitzhardinge wrote:
> >>> >
> >>> > So the bzImage structu
yhlu <[EMAIL PROTECTED]> writes:
> Eric,
>
> With the latest change that make vmlinux to be elf64 and make bzImage
> do switch to 64bit long mode, the kernel started via kexec can not get
> VGA console. but the serial console works well. I wonder if the
> setup.S is skipped in bzImage via kexec pa
On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>> >
>> > So the bzImage structure is currently:
>> >
>> >1. old-style boot sector
>> >2. old-st
On Tue, 8 May 2007, Rusty Russell wrote:
> 1) Bridging via host is broken: we need to set "promisc" bit in MAC
>address published by the host so the guest sends us everything.
>Thanks James Morris for the report (I don't use bridging).
>
> 2) Lguest network device uses 0 to mean "noone at
[NET]: Remove link_watch delay for up even when we're down
Currently all link carrier events are delayed by up to a second
before they're processed to prevent link storms. This causes
unnecessary packet loss during that interval.
In fact, we can achieve the same effect in preventing storms by
on
On Mon, May 07, 2007 at 02:10:27PM -0700, Jeremy Fitzhardinge wrote:
>
> > We should just change this to use netif_device_attach and
> > netif_device_detach.
>
> Like this?
Sorry, I had forgotten that I've already concluded previously that
this doesn't work because we don't want to prevent the in
1) Bridging via host is broken: we need to set "promisc" bit in MAC
address published by the host so the guest sends us everything.
Thanks James Morris for the report (I don't use bridging).
2) Lguest network device uses 0 to mean "noone at this slot". It used to
use 0xFF, and one spot w
17 matches
Mail list logo
