Andi Kleen wrote:
> This implements new vDSO for x86-64. The concept is similar
> to the existing vDSOs on i386 and PPC. x86-64 has had static
> vsyscalls before, but these are not flexible enough anymore.
>
> A vDSO is a ELF shared library supplied by the kernel that is mapped into
> user
Andrew Morton wrote:
On Tue, 01 May 2007 15:42:30 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
hm, a genuine oom on an all-ext3 data=ordered i386 system, just like a
million other people. How very weird.
I assume all those pages on the LRU are pagecache pages which for some
reason we're
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
>> Vivek Goyal <[EMAIL PROTECTED]> writes:
>>
>>
>> >> At least without a core file it is working on with gdb 6.4.
>> >>
>> >
>> > This seems to be a problem with gdb 6.5. I transferred
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog.
On Tue, 01 May 2007 15:42:30 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > hm, a genuine oom on an all-ext3 data=ordered i386 system, just like a
> > million other people. How very weird.
> >
> > I assume all those pages on the LRU are pagecache pages which for some
> > reason we're unable
Hi.
Does anyone have VMware working on x86_64 with 2.6.21? It's working fine
for me with 2.6.20, but freezes the whole computer with 2.6.21. Before I
start a git-bisect, I thought I might ask if anyone knew of some
compilation option I might have missed.
Regards,
Nigel
signature.asc
Andrew Morton wrote:
On Sun, 29 Apr 2007 11:28:05 +0100 Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
Hi all,
today, with 2.6.21, my laptop had a really odd behaviour. It started
writing to disk for a few minutes with no interactivity at all (no
redraw on screen, only hdd led on). It's the
On Tue, 1 May 2007 08:24:56 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The bug is in firstfloor only, and the fix (if present) will be there too.
> >
> >
> >
> > Nope,
> >
> > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
> >
> > is identical to
> >
> >
Eric W. Biederman wrote:
> I'm not going to worry about going farther until the patches in flight
> settle down a little bit, but this looks promising.
>
Is there any value in adding an "early-putchar" function pointer into
the structure somehow? I could easily arrange for the domain builder
William Lee Irwin III <[EMAIL PROTECTED]> writes:
> On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote:
>> From: [EMAIL PROTECTED]
>> When in PAE mode we require that the user kernel divide to be
>> on a 1G boundary. The 2G/2G split does not have that property
>> so require !X86_PAE
>>
Rusty Russell wrote:
>
> BTW, wrt. a new "platform type" field, should it go something like this?
>
> -0235/3 N/A pad2Unused
> +0235/1 2.07+ platform_type Runtime platform (see below)
> +0236/2 N/A pad2Unused
> ...
> + platform_type:
> +
> The bug is in firstfloor only, and the fix (if present) will be there too.
>
>
>
> Nope,
>
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/sched-clock-share
>
> is identical to
>
>
Vivek Goyal <[EMAIL PROTECTED]> writes:
>> At least without a core file it is working on with gdb 6.4.
>>
>
> This seems to be a problem with gdb 6.5. I transferred the dump to a
> different machine having GNU gdb 6.4, and it works fine there.
Ok. The difference between those two symbols
On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
>
> >> At least without a core file it is working on with gdb 6.4.
> >>
> >
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb
On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
> Andi Kleen a ?crit :
> >From: [EMAIL PROTECTED]
> >
> >When in PAE mode we require that the user kernel divide to be
> >on a 1G boundary. The 2G/2G split does not have that property
> >so require !X86_PAE
> >
> >Signed-off-by: Eric
On Mon, 30 Apr 2007 22:16:24 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > I was hitting the same thing on i386 uniprocessor, but I thought it got
> > > fixed.
> >
> > Yes.
>
> Fixed where? Merged into mainline or in your firstfloor patches?
The bug is in firstfloor only, and the fix
On Mon, Apr 30, 2007 at 10:16:24PM -0700, Randy Dunlap wrote:
> On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:
>
> > > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> > > randomish times (presumably in the timer irq handler) when netconsole and
> > > printk-time are
William Lee Irwin III a ?crit :
>> There's some sort of insanity going on here. Since when is 0x7800
>> a 2GB/2GB split? Mark, dare I ask what you were thinking? That should
>> be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if
>> nothing else, as it's certainly not 2GB/2GB.
On Tue, 1 May 2007 05:43:30 +0200 Andi Kleen wrote:
> > Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> > randomish times (presumably in the timer irq handler) when netconsole and
> > printk-time are enabled.
>
> A backtrace would be good. Does nmi_watchdog=2 show anything
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
drivers/soc/Kconfig| 22 +
drivers/soc/Makefile
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h
Hello linux-kernel,
In contemporary systems, lots of functionality oftentimes handled by various
kinds of SoCs (system-on-chip), representing a number of deversified
controllers packaged in one chip. Handling them is arguably an ongoing
problem, as diversity and number of devices included make
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c | 106
Hello linux-kernel,
Intro: This is a header with hardware definitions for ASIC3 chip,
contributed by HP/Compaq. It is provided as-is, as a vendor-originated
header.
-
ipaq-asic3.h: Hardware definitions for ASIC3 chip, found in ~12
handheld devices from HP/Compaq and HTC.
Signed-off-by:
On Mon, Apr 30, 2007 at 10:20:53PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
> >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> >> >
> >> > Currently because vmlinux does not reflect
William Lee Irwin III wrote:
>> The CONFIG_VMSPLIT config options were merged for such cases.
>> It should be able to split on any 4MB-aligned boundary in
>> CONFIG_HIGHMEM4G. CONFIG_VMSPLIT_3G_OPT appears to do something of
>> this sort to use an entire 1GB RAM with minimal user address space
>>
On Mon, Apr 30, 2007 at 08:45:25PM -0400, Jeff Garzik wrote:
> Chris Wright wrote:
> > 2) you can add them
> > runtime in userspace (and for pcmcia too after patch in question is
> > applied), so we've historically avoided that kind of patch for -stable.
>
>
> Due to distro installer
Hi.
I am working on an audio device driver development on Linux (sh4 architecture).
I have a userthread which makes ioctl calls to the kernel and once it reaches
inside the kernel it waits on a semaphore. It then does some work inside the
kernel and continuously keeps looping between the kernel
William Lee Irwin III a écrit :
On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote:
From: [EMAIL PROTECTED]
When in PAE mode we require that the user kernel divide to be
on a 1G boundary. The 2G/2G split does not have that property
so require !X86_PAE
Signed-off-by: Eric W. Biederman
Hi Linus,
Please consider pulling from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git
to receive updates for input subsystem.
Changelog:
--
Andres Salomon (1):
Input: psmouse - allow
On Mon, 2007-04-30 at 21:00 -0700, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > Rusty Russell wrote:
> >> It'd be nicer if there were a "struct boot_params" declaration, but we
> >> can't have everything.
> >
> > It's in my patchset-under-development.
> >
> > (Preview snapshot:
> >
On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote:
> From: [EMAIL PROTECTED]
> When in PAE mode we require that the user kernel divide to be
> on a 1G boundary. The 2G/2G split does not have that property
> so require !X86_PAE
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
[cc'ing linux-ide and Albert, Hi!]
William Thompson wrote:
> On Mon, Apr 30, 2007 at 12:22:21PM +0200, Tejun Heo wrote:
>> William Thompson wrote:
>>> I've been playing with libata on a few machines and I found that this
>>> machine
>>> (An old Dell Dimension L866r) gives me this when it loads
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote:
> Daniel Walker wrote:
> >
> > I'm interested in which clocksource is getting used, which is in the
> > boot log.
>
> Well then, send me a patch that dumps that information out just before it
> locks up.
> We know (first post in this thread)
Wow, I'd forgotten all about this one.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
dann frazier wrote:
> hey,
> I noticed that the moxa input checking security bug described by
> CVE-2005-0504 appears to remain unfixed upstream.
>
> The issue is described here:
>
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote:
> Daniel Walker wrote:
> >
> > I'm interested in which clocksource is getting used, which is in the
> > boot log.
>
> Well then, send me a patch that dumps that information out just before it
> locks up.
> We know (first post in this thread)
The first patch I sent out did not have a sign-off; I had trouble with my patch
tools.
This patch fixes all warnings seen on powerpc during compilation of the
CFS patch. It also fixes errors (side-effect of the warnings), where
some of the data is printed as negative values.
Applies on top of
Andi Kleen a écrit :
From: [EMAIL PROTECTED]
When in PAE mode we require that the user kernel divide to be
on a 1G boundary. The 2G/2G split does not have that property
so require !X86_PAE
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/Kconfig |1 +
1 files changed, 1
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
>> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
>> >
>> > Currently because vmlinux does not reflect that the kernel is relocatable
>> > we still have to support
Andrew Morton wrote:
On Mon, 30 Apr 2007 08:44:14 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote:
On Mon, 30 Apr 2007 07:35:00 -0700 (PDT) David Rientjes wrote:
Only declare mega_proc_dir_entry() in CONFIG_PROC_FS. We should call
mega_create_proc_entry() only in this configuration so make
This is the last place that needs changing since get_property was changed
to return "const void *".
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
--
Cheers,
Stephen Rothwell
These are all the remaining instances of get_property. Simple rename of
get_property to of_get_property.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/ata/sata_svw.c |2 +-
drivers/char/agp/uninorth-agp.c|2 +-
drivers/char/briq_panel.c
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/e820.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
Index: linux/arch/i386/kernel/e820.c
===
--- linux.orig/arch/i386/kernel/e820.c
+++
This was supposed to see the full memory on a ASUS A8SX motherboard
with 4GB RAM where the northbridge reports less memory, but it didn't
help there. But it's a reasonable change so let's include it anyways.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/mm/k8topology.c |2
Fix:
In file included from include2/asm/apic.h:5,
from include2/asm/smp.h:15,
from linux/arch/x86_64/kernel/genapic_flat.c:18:
linux/include/linux/pm.h: In function âcall_platform_enable_wakeupâ:
linux/include/linux/pm.h:331: error: âEIOâ undeclared
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc,
H. Peter Anvin wrote:
> Rusty Russell wrote:
>> It'd be nicer if there were a "struct boot_params" declaration, but we
>> can't have everything.
>
> It's in my patchset-under-development.
>
> (Preview snapshot:
> http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch)
Just pushed out a
- Remove #if that is always set
- Fix warning
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/smpboot.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: linux/arch/i386/kernel/smpboot.c
===
access_ok checks this case anyways, no need to check twice.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/lib/usercopy.c |7 ---
1 file changed, 7 deletions(-)
Index: linux/arch/i386/lib/usercopy.c
===
---
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/boot/setup.S |2
arch/x86_64/boot/video.S | 2043 ---
2 files changed, 1 insertion(+), 2044 deletions(-)
Index: linux/arch/x86_64/boot/setup.S
The option never worked well and functionlist wasn't well maintained.
Also it made the build very slow on many binutils version.
So just remove it.
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/Kconfig |8
arch/x86_64/Makefile
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/compat.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux/fs/compat.c
===
--- linux.orig/fs/compat.c
+++ linux/fs/compat.c
@@ -371,13 +371,14 @@ static
Check some CPUID bits that are needed for compiler generated early in boot.
When the system is still in real mode before changing the VESA BIOS mode
it is possible to still display an visible error message on the screen.
Similar to x86-64.
Includes cleanups from Eric Biederman
Signed-off-by:
Redefine cpu_has() to evaluate cpu features already checked in early
boot at compile time. This way the compiler might eliminate some dead code.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/cpufeature.h |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
RDTSCP is already synchronous and doesn't need an explicit CPUID.
This is a little faster and more importantly avoids VMEXITs on Hypervisors.
Original patch from Joerg Roedel, but reworked by AK
Also includes miscompilation fix by Eric Biederman
Cc: "Joerg Roedel" <[EMAIL PROTECTED]>
Syncs up with x86-64.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/intel.c |4 +++-
include/asm-i386/cpufeature.h |1 +
include/asm-i386/tsc.h|4
3 files changed, 4 insertions(+), 5 deletions(-)
Index: linux/arch/i386/kernel/cpu/intel.c
Following x86-64
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/cpufeature.h |1 +
1 file changed, 1 insertion(+)
Index: linux/include/asm-i386/cpufeature.h
===
--- linux.orig/include/asm-i386/cpufeature.h
Ported from x86-64.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/alternative.h | 15 +++
1 file changed, 15 insertions(+)
Index: linux/include/asm-i386/alternative.h
===
---
From: David P. Reed <[EMAIL PROTECTED]>
- Use 64bit TSC calculations to avoid handling overflow
- Use 32bit unsigned arithmetic for the APIC timer. This
way overflows are handled correctly.
- Fix exit check of loop to account for apic timer counting down
Signed-off-by: [EMAIL PROTECTED]
This implements new vDSO for x86-64. The concept is similar
to the existing vDSOs on i386 and PPC. x86-64 has had static
vsyscalls before, but these are not flexible enough anymore.
A vDSO is a ELF shared library supplied by the kernel that is mapped into
user address space. The vDSO
- Introduce a wd_ops structure
- Convert the various nmi watchdogs over to it
- This allows to split the perfctr reservation from the watchdog
setup cleanly.
- Do perfctr reservation globally as it should have always been
- Remove dead code referenced only by unused EXPORT_SYMBOLs
Signed-off-by:
Needed for followon patch
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/boot/Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/arch/i386/boot/Makefile
===
---
From: Suresh Siddha <[EMAIL PROTECTED]>
Set the node_possible_map at runtime on x86_64. On a non NUMA system,
num_possible_nodes() will now say '1'.
Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Eric
Follows i386 and useful cleanup.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/boot/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/x86_64/boot/Makefile
===
---
Dead to magic numbers!
Generated code is the same.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/verify_cpu.S | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
Index: linux/arch/x86_64/kernel/verify_cpu.S
This mainly removes a lot of code, replacing it with calls into the new 32bit
perfctr-watchdog.c
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/Makefile |3
arch/x86_64/kernel/nmi.c| 678 ++--
include/asm-x86_64/nmi.h|
Define a new IGNORE_IOCTL() to let a compat ioctl not be warned about even when
it is not implemented.
This is the same as COMPATIBLE_IOCTL internally, but better self documentng.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs
call it on others
The kernel doesn't implement it, but some programs like java use it
anyways. Shut the code up.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
fs/compat_ioctl.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/fs/compat_ioctl.c
On Mon, 2007-04-30 at 20:45 -0700, H. Peter Anvin wrote:
> Rusty Russell wrote:
> >
> > It'd be nicer if there were a "struct boot_params" declaration, but we
> > can't have everything.
>
> It's in my patchset-under-development.
Ah ha: excellent!
> > +typedef unsigned long long u64;
> >
Hi Alan,Nick
Thanks for your inputs. I was able to solve the problem of mapping kernel
buffer to user space. Just FYI, I am working on a sh4 based architecture
proprietary board with Linux kernel 2.6.17.3
Initially I was adopting the following approach:
1.The kernel thread was copying some
vfat implements compat handlers for these ioctls, but when they
were executed on other file systems the kernel would still complain
about an unknown compat ioctl. Just declare them as compatible
and let them be rejected when not needed by the normal path.
This makes wine runs a lot quieter
From: [EMAIL PROTECTED]
When in PAE mode we require that the user kernel divide to be
on a 1G boundary. The 2G/2G split does not have that property
so require !X86_PAE
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
arch/i386/Kconfig |1 +
1 files changed, 1 insertions(+), 0
From: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
include/asm-i386/i387.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux/include/asm-i386/i387.h
asm-offsets.c is valid source code and needs to be diffed.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
Documentation/dontdiff |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/Documentation/dontdiff
From: Jan Kiszka <[EMAIL PROTECTED]>
There are two callers of __unlazy_fpu, unlazy_fpu and __switch_to, and
none of them appear to require additional preempt_disable/enable here.
Let's open-code save_init_fpu in __unlazy_fpu to save a few ops.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
Rusty Russell <[EMAIL PROTECTED]> writes:
> On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
>> Reading this it occurs to me what I object to wasn't that clear.
>>
>> I have no problem with the testing of %cs to see if we are not in ring0.
>> That part while a little odd is fine, and
The last batch of x86 patches for .22 to review.
This one contains various patches that haven't hit l-k yet. Please
review closely.
- Finally vDSO support for x86-64
* glibc support still missing unfortunately
- New early CPUID checking for i386
- Restructured NMI watchdog code
- Dynamic MCE
From: Tim Hockin <[EMAIL PROTECTED]>
Background:
We've found that MCEs (specifically DRAM SBEs) tend to come in bunches,
especially when we are trying really hard to stress the system out. The
current MCE poller uses a static interval which does not care whether it
has or has not found MCEs
On Mon, 30 Apr 2007 22:58:47 +0200 Rafał Bilski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have Wyse 3360SE terminal running Linux 2.6.21-rc7. Everything
> works great with one small exception. Natsemi DP83815 driver is
> filling log with:
> > ezri user.info kernel: eth0: DSPCFG accepted after
On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> >
> > Currently because vmlinux does not reflect that the kernel is relocatable
> > we still have to support CONFIG_PHYSICAL_START. So this patch adds a small
> > c program
On Mon, Apr 30, 2007 at 06:33:09PM -0700, H. Peter Anvin wrote:
>Hi all,
>
>I'm rewriting the i386 setup code in C, instead of assembly, and before
>I spend a very large amount of time translating all the various
>card-specific probes, I want to ask the following question...
>
>Does *anyone* care
Eric W. Biederman wrote:
>
> I would be very surprised if the high volume commodity boards have
> exceeded 8 megabits.
>
Most of the high-capacity chips are used on laptops, not conventional
motherboards.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Rusty Russell wrote:
>
> It'd be nicer if there were a "struct boot_params" declaration, but we
> can't have everything.
It's in my patchset-under-development.
(Preview snapshot:
http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch)
> diff -r 9a673a220ad6
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Andi Kleen <[EMAIL PROTECTED]> writes:
>>
Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
and ubiquitousness,
>>> Simplicity? That must be why x86 motherbords are shipping with
On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
> Reading this it occurs to me what I object to wasn't that clear.
>
> I have no problem with the testing of %cs to see if we are not in ring0.
> That part while a little odd is fine, and we will certainly need a test
> to skip the
Andi Kleen wrote:
>
> At least my Asus board with 8Mb flash doesn't have anything called that.
> There is also no special preboot environment
>
> iirc Asus ships dual BIOS though, but even half that compressed is a lot.
>
8 Mb or 8 MB? Big difference...
So you have 512K worth of compressed
Daniel Walker wrote:
I'm interested in which clocksource is getting used, which is in the
boot log.
Well then, send me a patch that dumps that information out just before it locks
up.
We know (first post in this thread) that the lockup occurs just after
these two messages:
"switched to
On Tue, May 01, 2007 at 12:14:11PM +1000, Neil Brown wrote:
> I don't think this BUG_ON is correct. If a readdir finds zero entries,
> then will be some trailer information in the 'tail', but page_len will
> be 0. I think the following patch is correct and could fix that.
Yep.
> Bruce: does
On Mon, Apr 30, 2007 at 07:54:27PM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
> >> and ubiquitousness,
> >
> > Simplicity? That must be why x86 motherbords are shipping with (compressed)
> > 8MB BIOS flash chips
On Mon, 30 Apr 2007 19:46:12 -0700 (PDT) David Rientjes <[EMAIL PROTECTED]>
wrote:
> So, due to the whacky implementation of __attribute_used__, we can just do
> this:
> ---
> arch/i386/pci/init.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git
Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
>>> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
>>> and ubiquitousness,
>> Simplicity? That must be why x86 motherbords are shipping with (compressed)
>> 8MB BIOS flash chips now.
>
> Those would be
The latest maintenance release GIT 1.5.1.3 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.1.3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.1.3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.1.3.tar.{gz,bz2}
Andi Kleen <[EMAIL PROTECTED]> writes:
>> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
>> and ubiquitousness,
>
> Simplicity? That must be why x86 motherbords are shipping with (compressed)
> 8MB BIOS flash chips now.
Those would be 8 megabit chips, and those would
On Mon, Apr 30, 2007 at 07:43:54PM -0700, Linus Torvalds wrote:
> Doubtful. The Tseng ET4000 cards may have been the gold standard in 1991,
> but I don't think most people even _remember_ them.
heh. it was only recently I gave away a _dual head_ pci et4000.
One of our X guys grabbed it
Andi Kleen wrote:
>> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
>> and ubiquitousness,
>
> Simplicity? That must be why x86 motherbords are shipping with (compressed)
> 8MB BIOS flash chips now.
Very little of that is the actual BIOS, though. Most of it is
> Not that the x86 BIOS is bad. It is nearly a marvel in it's simplicity
> and ubiquitousness,
Simplicity? That must be why x86 motherbords are shipping with (compressed)
8MB BIOS flash chips now.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Andi Kleen wrote:
>
> It's still unclear to me why exactly you want to rewrite it?
> Are there any particular bugs in the current code you want to fix?
>
It's more the sheer degree of unmaintainability which is grating on my
nerves. There is way too much hocus-pocus going on, and I dare to say
> Andi: unprocessor x86_64 running rc7-mm2 is hanging early in boot at
> randomish times (presumably in the timer irq handler) when netconsole and
> printk-time are enabled.
A backtrace would be good. Does nmi_watchdog=2 show anything
interesting or if not sysrq-t?
>
> I was hitting the same
On Mon, 30 Apr 2007, Andrew Morton wrote:
> On Mon, 30 Apr 2007 07:34:52 -0700 (PDT) David Rientjes <[EMAIL PROTECTED]>
> wrote:
>
> > The automatic 'type' variable is unused in !CONFIG_PCI_DIRECT and
> > !CONFIG_PCI_MMCONFIG.
> >
> > Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >
On Mon, 30 Apr 2007, H. Peter Anvin wrote:
>
> Does *anyone* care about these anymore?
Doubtful. The Tseng ET4000 cards may have been the gold standard in 1991,
but I don't think most people even _remember_ them. And if they have them
in their machines, they probably tend to run a Linux-1.2
1 - 100 of 1318 matches
Mail list logo
