Davide Libenzi a écrit :
> Core code for the fdmap implementation. Random allocation, exact allocation,
> de-allocation and lookup are all O(1) operations. It also support the "legacy"
> sequential (compact) file descriptor allocation, that is O(N) like the old
> fdtable implementation.
> Like the
On Jun 6 2007 16:42, Andrew Morton wrote:
>> If so then you sent to it me :)
>
>You merged it ;)
>
>> Should I drop it?
>
>Sure, Jan will fix it up, I assume. I might have broken it while repairing
>the reject storm which occurred when that durned HAS_IOMEM thing went in
>all over the tree.
/me
Jiri Slaby wrote:
> Andrew Morton napsal(a):
>> On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote:
>>
>>> Mikael Pettersson napsal(a):
On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
> Andrew Morton napsal(a):
>> ftp://ftp.kernel.org/pub/linux/kernel/people/
On Wed, 6 Jun 2007 23:42:31 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> create-the-zone_movable-zone.patch breaks the build on sparc32.
On Wed, Jun 06, 2007 at 11:51:31PM -0700, Andrew Morton wrote:
> Nope, there are no instances of GFP_HIGH_MOVABLE in the tree once all
> patches ar
On Wed, 6 Jun 2007 23:42:31 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
> > - Basically a bugfixed version of 2.6.22-rc4-mm1. N
Peer Chen wrote:
> Add the MCP73/MCP77 support to ahci driver.
> The patch base on kernel 2.6.22-rc4
Please resend in plain text. My recommendations...
1. If you can setup a linux machine with working MTA, use
git-format-patch and git-send-email. If you don't feel comfortable with
git, you can
On Thu, Jun 07, 2007 at 12:59:13AM -0500, Matt Mackall wrote:
>On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote:
>> On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote:
>> >On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[EMAIL PROTECTED]> wrote:
>> >
>> >> On Wed, Jun 06, 2007 at 0
On 6/6/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
On 6/6/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 06, 2007 at 06:04:17PM +0530, Nitin Gupta wrote:
> > Hi,
> >
> > This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
> > version only).
> >
> > * Changes sinc
[EMAIL PROTECTED] wrote:
> On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
> This one died a horrid death at boot time - console log indicates it found the
> hard drive OK, found the 2 partitions on
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
> - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem
> trees were repulled, several bad patches were dropped, a few were
On 6/7/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi,
I remember this one ...
On 6/7/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, May 31, 2007 at 10:26:10AM -0500, [EMAIL PROTECTED] wrote:
> >
> > I wasn't actually able to reproduce the bug myself, but I guess it is
> > pretty obvious tha
On Thu, 2007-06-07 at 02:17 +0200, Martin Peschke wrote:
> Ingo Molnar wrote:
> > * Martin Peschke <[EMAIL PROTECTED]> wrote:
> >
> >> The output has changed from a terribly wide table to an enormously
> >> long list (just the generic way the statistics code prints data).
> >
> > Sigh, why dont
From: Mikael Pettersson <[EMAIL PROTECTED]>
Date: Thu, 7 Jun 2007 08:24:57 +0200 (MEST)
> I'm away from my ultra5 right now, but I should be able to do
> this test on Monday next week.
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On Wed, 06 Jun 2007 16:22:10 -0700 (PDT), David Miller <[EMAIL PROTECTED]>
wrote:
> > From: Mikael Pettersson <[EMAIL PROTECTED]>
> > Date: Wed, 30 May 2007 21:33:18 +0200 (MEST)
> >
> > > You were spot on. 2.6.21 + patches up to but not including
> > > the first one above works. Adding that one
2007/6/6, Tejun Heo <[EMAIL PROTECTED]>:
Let's see where we're failing.
[ 186.849280] ata_piix :00:07.1: version 2.11
[ 186.849665] scsi0 : ata_piix
[ 186.850241] scsi1 : ata_piix
[ 186.850596] ata1: PATA max UDMA/33 cmd 0x000101f0 ctl 0x000103f6
bmdma 0x00010860 irq 14
[ 186.851203] a
[ BUG: circular locking deadlock detected! ]
udev_run_hotplu/720 is deadlocking current task modprobe/690
1) modprobe/690 is trying to acquire this lock:
[f7019558] {&info->lock}
.. ->owner: f6e52032
.. hel
On Wed, Jun 06, 2007 at 06:09:24PM -0700, Andrew Morton wrote:
> ooh, yes, lockdep_init() really does want to be called before anything
> else.
> So do we take it that this code hasn't been tested with lockdep? Please
> don't forget that step - lockdep finds some pretty nasty bugs sometimes.
> Thi
On Wed, Jun 06, 2007 at 06:26:32PM +0100, Richard Purdie wrote:
> +/* Which machines to allow unaligned accesses on */
> +#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64)
> +#define LZO_UNALIGNED_OK_2
> +#define LZO_UNALIGNED_OK_4
> +#endif
> +
This is silly, just use get/put_unaligned(). This
On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote:
> On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote:
> >On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
> >> >
> >> >ftp://ftp.kernel
Hello,
David Greaves wrote:
> Just to be clear. This problem is where my system won't resume after s2d
> unless I umount my xfs over raid6 filesystem.
This is really weird. I don't see how xfs mount can affect this at all.
[--snip--]
> So now this compiles but it does cause the problem:
>
> um
Hi,
I remember this one ...
On 6/7/07, Greg KH <[EMAIL PROTECTED]> wrote:
On Thu, May 31, 2007 at 10:26:10AM -0500, [EMAIL PROTECTED] wrote:
>
> I wasn't actually able to reproduce the bug myself, but I guess it is
> pretty obvious that I shouldn't have called cpufreq_unregister_notifier
> with
> "Russ" == Russ Anderson <[EMAIL PROTECTED]> writes:
Russ> Tony Luck wrote:
>> > I used the sn2_defconfig in the tree :)
>>
>> So there is something odd happening. Russ complained that he was
>> still seeing several errors from the sn2_defconfig build too when I
>> posted the "last fix" to
This patch basically copies the gnulib version of memmem() into
scripts/kallsyms.c. While a useful function, it isn't in POSIX so some
systems (like Darwin) choose to omit it. How do others feel ?
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
--- a/scripts/kallsyms.c
+++ b/scripts/kallsy
Jeff Dike wrote:
> On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote:
>
>>> -static int rmode_tss_base(struct kvm* kvm)
>>> +static unsigned long rmode_tss_base(struct kvm* kvm)
>>>
>> Should use gpa_t instead.
>>
>
> Right you are, I didn't notice that type.
>
>
Some ext
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
- Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem
trees were repulled, several bad patches were dropped, a few were fixed.
Boilerplate:
- See the `hot-fixes' directory for any impo
On 6/6/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 6 Jun 2007 23:27:01 -0400 "Albert Cahalan" <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman writes:
> > Badari Pulavarty <[EMAIL PROTECTED]> writes:
>
> >> Your recent cleanup to shm code, namely
> >>
> >> [PATCH] shm: make sysv ipc shared
On Thu, May 31, 2007 at 10:26:10AM -0500, [EMAIL PROTECTED] wrote:
>
> I wasn't actually able to reproduce the bug myself, but I guess it is
> pretty obvious that I shouldn't have called cpufreq_unregister_notifier
> with a spinlock held. I haven't been doing this long enough to know
> exactly wh
On 6/6/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
Nitin: Have you any objections to this version? If not, I'll finish
analysing the PTR_ code changes and then hopefully we can get something
into -mm...
Your code now looks nice and clean. But I don't know what you want. I
already spent lot
On Thu, Jun 07, 2007 at 02:17:45AM +0200, Martin Peschke wrote:
> Ingo Molnar wrote:
> >, quite some work went into it - NACK :-(
>
> Considering the amount of code.. ;-)I am sorry.
>
> But seriously, did you consider using some user space tool or script to
> format this stuff the way you lik
This patch fixes the problem of page protection introduced by
CONFIG_DEBUG_RODATA for x86_64 architecture. As per Andi
Kleen's suggestion, the kernel text pages are marked writeable
only for a short duration to insert or remove the breakpoints.
Signed-off-by: Prasanna S P<[EMAIL PROTECTED]>
Ack-e
On Thu, Jun 07, 2007 at 11:12:32AM +1200, Ian McDonald wrote:
> On 6/7/07, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> >On 06/06/2007 04:47 PM, Ian McDonald wrote:
> >> Hi there,
> >>
> >> We've seen a report of a problem with dccp_probe as shown below. The
> >> user has also verified that it occurs
On Wed, Jun 06, 2007 at 10:11:20PM -0500, [EMAIL PROTECTED] wrote:
> greg
> with CONFIG_USB_DEVICE_CLASS=y
> scanner /dev/scanner- show up xsane is working now
>
> SCANNER PROBLEM SOLVED
Great, thanks for verifying this. This config option is by default
enabled, so you need to work hard
On Wed, 6 Jun 2007 23:27:01 -0400 "Albert Cahalan" <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman writes:
> > Badari Pulavarty <[EMAIL PROTECTED]> writes:
>
> >> Your recent cleanup to shm code, namely
> >>
> >> [PATCH] shm: make sysv ipc shared memory use stacked files
> >>
> >> took away one of
This is a minor fix, but what is currently there is essentially wrong.
In do_page_fault, if the faulting address from user code happens to be
in kernel address space (int *p = (int*)-1; p = 0xbed;) then the
do_page_fault handler will jump over the local_irq_enable with the
goto bad_area_nosemap
On Wed, 2007-06-06 at 22:20 -0400, Jeff Dike wrote:
> On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
> > What Ben was talking about was stealing a synchronous SEGV from a task
> > without stopping it, and as Ben says that makes no sense.
> > Intercepting a signal and stopping the t
Eric W. Biederman writes:
Badari Pulavarty <[EMAIL PROTECTED]> writes:
Your recent cleanup to shm code, namely
[PATCH] shm: make sysv ipc shared memory use stacked files
took away one of the debugging feature for shm segments.
Originally, shmid were forced to be the inode numbers and
they sh
On Wed, 2007-06-06 at 08:35 -0700, Linus Torvalds wrote:
> So now we should do "recalc_sigpending()" only when signals may be
> *added*
> (where messing with the "blocked" mask obviously is a form of adding
> signals, and possibly the most common reason for having to recalculate
> the
> sigpendi
On Wed, 2007-06-06 at 08:35 -0700, Linus Torvalds wrote:
>
> So I think that the *right* place to clear TIF_SIGPENDING is actually in
> "get_signal_to_deliver()", because that function is called _only_ by the
> actual per-architecture "I'm going to deliver a signal now".
That was my initial ide
On Wed, 2007-06-06 at 03:59 -0700, Roland McGrath wrote:
> Oleg and I were just discussing this issue in relation to other problems.
> We established that it is never safe to clear TIF_SIGPENDING on another
> thread. But I hadn't really thought through that it's sometimes not safe
> to clear your
On Wed, 2007-06-06 at 08:52 -0400, Jeff Dike wrote:
> On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
>
>
On Thu, Jun 07, 2007 at 10:13:42AM +0800, Li, Xin B wrote:
> >-static int rmode_tss_base(struct kvm* kvm)
> >+static unsigned long rmode_tss_base(struct kvm* kvm)
>
> Should use gpa_t instead.
Right you are, I didn't notice that type.
Will fix.
Jeff
--
Work ema
greg
with CONFIG_USB_DEVICE_CLASS=y
scanner /dev/scanner- show up xsane is working now
SCANNER PROBLEM SOLVED
thanx
xboom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/ma
On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
> What Ben was talking about was stealing a synchronous SEGV from a task
> without stopping it, and as Ben says that makes no sense.
> Intercepting a signal and stopping the task is reasonable, and that is
> what ptrace does, and I ass
greg this is part of my config
(we are talking now 2.6.22-rc4-200706042030-cfq7 #160 SMP PREEMPT Mon
Jun 4 20:55:02 CDT 2007 x86_64 x86_64 x86_64 GNU/Linux)
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set -
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEN
On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote:
>On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1
This path adds validation of the MMCONFIG table against the ACPI reserved
motherboard resources. If the MMCONFIG table is found to be reserved in
ACPI, we don't bother checking the E820 table. The PCI Express firmware spec
apparently tells BIOS developers that reservation in ACPI is required and
E8
>
>The long return value of rmode_tss_base is truncated by its declared
>return type of int.
>
>Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
>--
> drivers/kvm/vmx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>Index: kvm/drivers/kvm/vmx.c
>===
On Wed, 2007-06-06 at 11:23 +0100, Alan Cox wrote:
> > > Better yet just don't compile in the old IDE stuff, lguest doesn't have a
> > > PCI or ISA bus anyway.
> >
> > Sure, but the "run the same kernel as guest and host" is a really nice
> > feature.
>
> Modules dear boy, modules ;)
For some re
do_generic_mapping_read currently samples the i_size at the start
and doesn't do so again unless it needs to call ->readpage to load
a page. After ->readpage it has to re-sample i_size as a truncate
may have caused that page to be filled with zeros, and the read()
call should not see these.
Howe
On Wed, 6 Jun 2007 23:53:28 +0400 Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> Eliminate UltraATA/133 support for HPT374 -- the chip isn't capable of this
> mode
> according to the manual, and doesn't even seem to tolerate 66 MHz DPLL
> clock...
>
> Signed-off-by: Sergei Shtylyov <[EMAIL PROTEC
Rob Landley wrote:
> On Wednesday 06 June 2007 7:41 pm, H. Peter Anvin wrote:
>> This makes vmlinux (normally stripped) recoverable from the bzImage file
>> and so anything that is currently booting vmlinux would be serviced by
>> this scheme.
>
> Would this make it sane to strip the initramfs ima
The following two patches fix a couple of bugs which trigger when read
races with truncate.
As there is no locking between read and truncate, we need to be
careful about sequencing. In some cases were aren't careful enough.
The first patch ensures that we check i_size *after* gaining a
referenc
The do_loop_readv_writev implementation of readv breaks out of the
loop as soon as a single read request didn't fill it's buffer:
if (nr != len)
break;
The generic_file_aio_read version doesn't. So if it hits EOF
before the end of the list of buffers, it w
On Wednesday 06 June 2007 7:41 pm, H. Peter Anvin wrote:
> This makes vmlinux (normally stripped) recoverable from the bzImage file
> and so anything that is currently booting vmlinux would be serviced by
> this scheme.
Would this make it sane to strip the initramfs image out of vmlinux with
objd
>-Original Message-
>From: Andrew Morton [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, June 06, 2007 6:39 PM
>To: Thomas Gleixner
>Cc: Pallipadi, Venkatesh; Stable Team; LKML; Len Brown; Ingo
>Molnar; Arjan van de Ven; Andi Kleen; Udo A. Steinberg; Dave Jones
>Subject: Re: [PATCH] ACPI:
Thomas,
Can you replace my previous patch with this one. This one includes the
fix for i386.
-- Steve
Index: linux-2.6.21-rt9/arch/x86_64/mm/fault.c
===
--- linux-2.6.21-rt9.orig/arch/x86_64/mm/fault.c
+++ linux-2.6.21-rt9/arch/x86_
On Wed, 06 Jun 2007 11:37:53 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> From: Udo A. Steinberg <[EMAIL PROTECTED]>
>
> The chip set doc for IHC4 says:
>
> 1.In general, software should not attempt any non-posted accesses during
> arbiter disable except to the ICH4's power management regi
On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
> On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
>
> > >
> > > As far as a 100% CPU bound task being a valid thing to do, it has been
> > > done for many years on SMP machines. Any kernel limitation on
On Wed, Jun 06, 2007 at 05:26:49PM -0700, Davide Libenzi wrote:
> I'm sure there's a good reason behind, but why are those variables
> replicated in every architecture?
> Those are global variables, defined in global include files, and AFAICS
> they could be moved in a single kernel/init_task.c f
On Wed, 6 Jun 2007 17:32:33 -0700 "Paul Menage" <[EMAIL PROTECTED]> wrote:
> On 6/6/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> >
> > (1) build for i386 with my .config
> > (2) attempt to boot in qemu's i386 system simulator
> >
> > I'm not seeing the sort of nondeterminism Andy Whitcro
H. Peter Anvin wrote:
> It doesn't if we simply declare that a certain chunk of memory is
> available to it, for the case where it runs in the native configuration.
> Since it doesn't have to support *any* ELF file, just the kernel one,
> that's an option.
>
I suppose. But given that its alway
--- Jared Hulbert <[EMAIL PROTECTED]> wrote:
> The vma->flags = 1875 = 0x753
>
> This is:
> VM_READ
> VM_WRITE
> VM_MAYREAD
> VM_MAYEXEC
> VM_GROWSDOWN
> VM_GROWSUP
> VM_PFNMAP
>
There was a mistake in Jared's previous post in this
thread. The vm_flags were already in hex, i.e. 0x1875
The settin
looking at a simple program:
int main()
{
if (fork()) return 0;
printf("pid = %i\n", getpid());
while (1) sleep(3600);
}
and where my / and /var/tmp are on the same partition:
# gcc test.c -o /usr/sbin/MOO
# /usr/sbin/MOO
pid = 17144
# readlink /proc/17144/exe
/usr/sbin/MOO
# gcc test.c -o /
On Wed, 6 Jun 2007 23:20:46 +0200 "Steinar H. Gunderson" <[EMAIL PROTECTED]>
wrote:
> [Please Cc on reply]
>
> Hi,
>
> I recently bought an USB MIDI interface from ESI (called “ESI MIDI Mate”). It
> claims to work with Linux, but doesn't -- I've already asked the manufacturer
> for an explanati
> I suppose as a cleaner alternative we could
> add a container_subsys->inherit_defaults() handler, to be called at
> container_clone(), and for cpusets this would set cpus and mems to
> the parent values - sibling exclusive values. If that comes to nothing,
> then the attach_task() is still refu
Jeremy Fitzhardinge wrote:
>
> Certainly, but much harder to implement. The ELF parser needs to be
> prepared to move itself around to get out of the way of the ELF file.
> It's a fairly large change from how it works now.
>
It doesn't if we simply declare that a certain chunk of memory is
ava
On Wed, 06 Jun 2007 12:10:28 +0200 Miloslav Trmac <[EMAIL PROTECTED]> wrote:
> From: Miloslav Trmac <[EMAIL PROTECTED]>
>
> Add TTY input auditing, used to audit system administrator's actions.
> TTY input auditing works on a higher level than auditing all system
> calls within the session, which
CONFIG_X86_TSC makes the TSC mandatory, but since the TSC may be
unstable, we still have to be able to operate without it.
Furthermore, with CONFIG_X86_GENERIC we still compile in the RDTSC
instructions.
In the end, the only significant effect is has is that it makes the
"notsc" flag inoperable, w
From: Kevin Lloyd <[EMAIL PROTECTED]>
This patch is derived from the 2.6.22-rc4 kernel source and adds support for the
new TRU-install (C) feature (without this support new devices will not work),
and
add new UMTS device VID/PIDs.
There was a previous submission on Tuesday June 5th, it was poin
On Wed, 2007-06-06 at 20:53 +0200, Thomas Klein wrote:
> This patch fixes a possible kernel panic due to not checking the vlan group
> when processing received VLAN packets and a malfunction in VLAN/hypervisor
> registration.
>
>
> Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
> ---
>
>
> dif
On Thu, 7 Jun 2007, Arnd Bergmann wrote:
> On Thursday 07 June 2007, Davide Libenzi wrote:
> > The sys_socketcall() system call has been also changed to support
> > a new SYS_SOCKET2 indentifier.
>
> I thought the general agreement was that sys_socketcall is a bad
> idea to start with. Is there a
Dave Hansen wrote:
On Wed, 2007-06-06 at 23:33 +0200, Martin Peschke wrote:
struct statistic_interface {
/* private: */
struct list_head list;
- struct dentry *debugfs_dir;
- struct dentry *data_file;
- struct dentry *def_file;
+
On 6/6/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
(1) build for i386 with my .config
(2) attempt to boot in qemu's i386 system simulator
I'm not seeing the sort of nondeterminism Andy Whitcroft is. It breaks
every time when I try this.
Looks to be lockdep related - it's reproducibl
On Thursday 07 June 2007, Davide Libenzi wrote:
> The sys_socketcall() system call has been also changed to support
> a new SYS_SOCKET2 indentifier.
I thought the general agreement was that sys_socketcall is a bad
idea to start with. Is there any benefit in adding new calls to
it instead of using
Hey All,
With 2.6.21 and the current -git, we're seeing the following oops when
we try sysrq-m:
...
Node 1 Normal: 85*4kB 34*8kB 20*16kB 4*32kB 3*64kB 0*128kB 1*256kB
0*512kB 1*1024kB 0*2048kB 953*4096kB =
3906020kB
Swap cache: add 0, delete 0,
I'm sure there's a good reason behind, but why are those variables
replicated in every architecture?
Those are global variables, defined in global include files, and AFAICS
they could be moved in a single kernel/init_task.c file. No?
- Davide
-
To unsubscribe from this list: send the line "u
Thanks - it looks almost right but you missed mknod case and your
patch had some whitespace/formatting problems.
Could you try the following and make sure it works for you? If so will merge.
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index f085db9..8e86aac 100644
--- a/fs/cifs/dir.c
+++ b/fs/ci
H. Peter Anvin wrote:
> I was thinking prescriptive, having the decompressor read the output
> stream and interpret it as ELF. I guess a descriptive approach could be
> made to work, too (I haven't really thought about that avenue of
> approach), but the prescriptive model seems more powerful, at
Ingo Molnar wrote:
* Martin Peschke <[EMAIL PROTECTED]> wrote:
- lock_time_inc() vs. statistic_add_util()
please fix the coding style in lib/statistic.c. It's full of:
{
unsigned long long i;
if (value <= stat->u.histogram.range_min)
return 0;
put a newline a
Ingo Molnar wrote:
* Martin Peschke <[EMAIL PROTECTED]> wrote:
The output has changed from a terribly wide table to an enormously
long list (just the generic way the statistics code prints data).
Sigh, why dont you _ask_ before doing such stuff?
A nice diffstat is always worth a try, isn't
Andrew Lyon wrote:
Could this also cause a system to be unstable? my abit athlon64 at
work will not run x64 with more than 1gb ram, and i have a colo server
with supermicro & 2 x dual core xeons that will not run with more than
2gb.
Both systems have long uptimes but if i add ram they crash with
Jeremy Fitzhardinge wrote:
>
> I'm not sure I fully understand the mechanism you're proposing. You
> have the 16-bit setup code, the 32-bit decompressor, and an ELF.gz. Once
> the decompressor has extracted the actual ELF file, are you proposing
> that it properly parse the ELF file and follow it
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > > I wasn't paying close enough attention to understand why you couldn't
> > > do it in two steps - make the container, and then populate it with
> > > resources.
> >
> > Sorry, please clarify - are you saying that now you do understand, or
> > that I s
Andrew Morton wrote:
Yeah, this caused test.kernel.org to fail as well.
There are a couple of fixes in
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/hot-fixes/
which should get things going again.
Robert, I spent some time picking at
mmconfig-validate-a
H. Peter Anvin wrote:
> I still believe that we should provide, in effect, vmlinux as a
> (compressed) ELF file rather than provide the intermediate stage. It
> would reduce the complexity of testing (all information provided about a
> stage have to be both guaranteed to even make sense in the fut
Reinaldo de Carvalho wrote:
This laptop have a nVidia 10de:0244 with 256Mb of RAM. No shared memory.
Reinaldo de Carvalho
00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express
Bridge (rev a2) (prog-if 00 [VGA])
Subsystem: Hewlett-Packard Company Unknown device 30b5
Jeremy Fitzhardinge wrote:
> This patch makes the payload of the bzImage file an ELF file. In
> other words, the bzImage is structured as follows:
> - boot sector
> - 16bit setup code
> - ELF header
> - decompressor
> - compressed kernel
>
> A bootloader may find the start of the ELF file
On Thu, 7 Jun 2007 07:28:31 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 06, 2007 at 01:24:39PM -0700, Andrew Morton wrote:
> >
> > > And for some reason the whole Cryptographic API is under the main level
> > > of menu
> > > (please find .config and menu.png attached).
> >
> > err
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
---
include/linux/elf_boot.h | 15 +++
1 file changed, 15 insertions(+)
===
--- /dev/null
+++ b/include/linux/elf_boot.h
@@ -0,
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/elf.h | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
===
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -1,9 +1,10 @
This patch uses the updated boot protocol to do paravirtualized boot.
If the boot version is >= 2.07, then it will do two things:
1. Check the bootparams loadflags to see if we should reload the
segment registers and clear interrupts. This is appropriate
for normal native boot and some p
Proposed updates for version 2.07 of the boot protocol. This includes:
load_flags.KEEP_SEGMENTS- flag to request/inhibit segment reloads
hardware_subarch- what subarchitecture we're booting under
hardware_subarch_data - per-architecture data
kernel_payload - address of the raw
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/linkage.h |6 ++
1 file changed, 6 insertions(+)
===
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -34,6 +34,12 @@
name:
#endif
This patch cleans up image generation in several ways:
- Firstly, it removes tools/build, and uses binutils to do all the
final construction of the bzImage. This removes a chunk of code
and makes the image generation more flexible, since we can compute
various numbers rather than be forc
This patch makes the payload of the bzImage file an ELF file. In
other words, the bzImage is structured as follows:
- boot sector
- 16bit setup code
- ELF header
- decompressor
- compressed kernel
A bootloader may find the start of the ELF file by looking at the
setup_size entry in the boo
This series:
1. Updates the boot protocol to version 2.07
2. Clean up the existing build process, to get rid of tools/build and
make the linker do more heavy lifting
3. Make the bzImage payload an ELF file. The bootloader can extract
this as a naked ELF file by skipping over boot_params
On Wed, 6 Jun 2007 21:58:38 +0100 Grant Wilson <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 June 2007 10:07:37 Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
> Patch 'usb-try-to-debug-bug-8561' triggers when I plug in a usb flas
On Wednesday, June 6, 2007 4:15 pm Justin Piszcz wrote:
> On Wed, 6 Jun 2007, Randy Dunlap wrote:
> > On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
> >> Hm, not sure if it was from the patch or what but I ran this:
> >>
> >> 1. swapoff -a
> >> 2. ./eatmem
> >
> > You usually have to
On Thu, 7 Jun 2007, Alan Cox wrote:
> > > prctl(PR_SPARSEFD, 1);
> > >
> > > to turn on sparse fd allocation for a process ?
> >
> > There was a little discussion where I tried to whisper something similar,
> > but Linus and Uli shot me :) - with good reasons IMO.
> > You may link to runtimes
On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
> > The mem= approach though looks slightly off, but I haven't looked
> > at x86_64's mem= handling to see why. From a high level though,
> > adjusting end_pfn is the right thing to do, since theoretically
> > mem= could choose to make holes
1 - 100 of 531 matches
Mail list logo
