On Nov 7, 2006 1:55 AM, Peer Chen <[EMAIL PROTECTED]> wrote:
> Modified and resent out the patch as attachment.
> Description about the patch:
> Add SGPIO support in sata_nv.c.
> SGPIO (Serial General Purpose Input Output) is a sideband serial 4-wire
> interface that a storage controller uses to co
[ Bernd, Josip, and Fabio, I think I finally nailed this
cpu hang bug we were all seeing on sparc64. ]
[FUTEX]: Fix address computation in compat code.
compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:
(void __user *)entry + futex_offset
'entry
On Nov 7, 2007 2:11 PM, Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Hello.
>
> Casey Schaufler wrote:
> > Fine grained capabilities are a bonus, and there are lots of
> > people who think that it would be really nifty if there were a
> > separate capability for each "if" in the kernel. I personally
>
--- Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Hello.
>
> Casey Schaufler wrote:
> > Fine grained capabilities are a bonus, and there are lots of
> > people who think that it would be really nifty if there were a
> > separate capability for each "if" in the kernel. I personally
> > don't see need
Getting this when booting 2.6.24-rc2:
sysctl table check failed: /kernel .1 Writable sysctl directory
Call Trace:
[c2047b60] [c000e204] .show_stack+0x54/0x1f0 (unreliable)
[c2047c10] [c006ea50] .set_fail+0x60/0x90
[c2047ca0] [c006ef64] .sysctl_check_
Dan Williams wrote:
> The following patch, also attached, cleans up cases where the code looks
> at sh->ops.pending when it should be looking at the consistent
> stack-based snapshot of the operations flags.
I tried this patch (against a stock 2.6.23), and it did not work for
me. Not only did I/
Annoying gcc warning:
fs/fat/inode.c: In function 'fat_fill_super':
fs/fat/inode.c:1222: warning: comparison is always false due to limited range
of data type
logical_sector_size can never be more than 16 bits worth, but switching
it to an int silences gcc. It's a sanity check that can never fai
I found syscall audit does not work on SH(SuperH).
I made patch to support syscall audit for SH.
Signed-off-by: Yuichi Nakamura<[EMAIL PROTECTED]>
---
arch/sh/kernel/entry-common.S |8 ++--
arch/sh/kernel/ptrace.c | 19 +++
include/asm-sh/thread_info.h |2 ++
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 06 Nov 2007 20:34:33 -0800 (PST)
> [FUTEX]: Fix address computation in compat code.
Sorry, I just noticed there is a second handle_futex_death()
call in compat_exit_robust_list() which has the same
address computation bug.
Here is an updated patc
I tried this out and it works great.
Thanks!
Later, JOSH
On 11/1/07, Francois Romieu <[EMAIL PROTECTED]> wrote:
> Josh Logan <[EMAIL PROTECTED]> :
> [...]
> > I have had this board for a few months as well and I have needed to
> > patch the driver to use 0x0001 as well.
>
> Ok.
>
> Can people g
On Wed, Nov 07, 2007 at 02:04:46PM +0900, Yuichi Nakamura wrote:
> I found syscall audit does not work on SH(SuperH).
> I made patch to support syscall audit for SH.
>
> Signed-off-by: Yuichi Nakamura<[EMAIL PROTECTED]>
Looks fine, but it's too late for 2.6.24. So this will go in to the 2.6.25
qu
On Mon, 2007-11-05 at 10:37 +0100, Cyrus Massoumi wrote:
> Zhang, Yanmin wrote:
> > On Thu, 2007-11-01 at 11:02 +0100, Cyrus Massoumi wrote:
> >> Zhang, Yanmin wrote:
> >>> On Wed, 2007-10-31 at 17:57 +0800, Zhang, Yanmin wrote:
> On Tue, 2007-10-30 at 16:36 +0800, Zhang, Yanmin wrote:
> >
This is a special announcement for the latest -rt patches. This is
actually announcing more than one tree (pay close attention to the
differences between -rt7, -rt8 and -rt9).
2.6.23.1-rt6
- Removed BUG_ON in exit (Steven Rostedt and Daniel Walker)
- Turn RCU preempt boost on by default
Gregory Haskins wrote:
> Anthony Liguori wrote:
>
>
>> Right now, we would have to have every PCI vendor/device ID pair in the
>> virtio PCI driver ID table for every virtio device.
>>
>
> I realize you guys are probably far down this road in the design
> process,
That doesn't mean we can'
On Wed, Nov 07, 2007 at 12:04:51AM +0100, Sam Ravnborg wrote:
> This serie of patches unify the X86 Kconfig files.
> Next step is to enable use of "make ARCH=x86" and kill
> "make ARCH=i386/x86_64".
> But that will wait till tomorrow.
>
> The allmodconfig kernel is still building here.
> Testing /
Glauber de Oliveira Costa wrote:
> This is the host part of kvm clocksource implementation. As it does
> not include clockevents, it is a fairly simple implementation. We
> only have to register a per-vcpu area, and start writting to it periodically.
>
> Signed-off-by: Glauber de Oliveira Costa <[E
On Wednesday 07 November 2007 13:52:29 Anthony Liguori wrote:
> This patch fixes a typo in vring_init().
Thanks, applied.
I've put it in the new, experimental virtio git tree on git.kernel.org.
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, Nov 07, 2007 at 12:01:12AM +0100, Sam Ravnborg wrote:
>...
> config X86_SPEEDSTEP_CENTRINO
> - tristate "Intel Enhanced SpeedStep"
> + tristate "Intel Enhanced SpeedStep (deprecated)"
> select CPU_FREQ_TABLE
> - select X86_SPEEDSTEP_CENTRINO_TABLE
> + select X86_SPEED
After discussion with Anthony, the virtio config has been simplified. We
lose some minor features (the virtio_net address must now be 6 bytes) but
it turns out to be a wash in terms of complexity, while simplifying PCI.
This can be found in the new virtio git tree, in the "patches/1" branch
(new
On Tue, Nov 06, 2007 at 11:17:39PM +0100, Romano Giannetti wrote:
> On Tue, 2007-11-06 at 22:48 +0100, Romano Giannetti wrote:
>
> > I do really suspect a software bug.
> >
>
> Well, I started bisecting it. It will be a long shot, I suspect...
>
> Romano
>
> BTW: I noticed that if I chang
> On Fri, 2 Nov 2007 19:34:20 +0100 "Hemmann, Volker Armin" <[EMAIL PROTECTED]>
> wrote:
> Hi,
(cc linux-ide)
> for some time (and I can't say for how long, but the board is less than a
> month old) I get this error on boot:
>
> [ 42.116273] ahci :00:0a.0: version 2.2
> [ 42.116482] ACP
> On Fri, 02 Nov 2007 12:10:00 -0500 Jordan Russell <[EMAIL PROTECTED]> wrote:
> Hi,
>
> With 2.6.23.1 (stock and Fedora), roughly 50% of the time my system
> hangs indefinitely during the kernel boot process. The hangs occur in
> places where normally a brief delay is seen, such as when detecting
> On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> Al Boldi wrote:
> > There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
> > entries) using a simple ls -l.
> >
> > On 2.6.23 client and server running userland rpc.nfs.V2:
> > first try: time -p ls -l <
> On Tue, 06 Nov 2007 05:08:07 -0500 Chris Snook <[EMAIL PROTECTED]> wrote:
> Don Porter wrote:
> > From: Donald E. Porter <[EMAIL PROTECTED]>
> >
> > In the bulk page allocation/free routines in mm/page_alloc.c, the zone
> > lock is held across all iterations. For certain parallel workloads, I
>
> On Thu, 01 Nov 2007 15:57:27 -0300 (GFT) "werner" <[EMAIL PROTECTED]> wrote:
> Kernel Crash -- Details see below
> globc 2.7 glib2 2.14.2
> W.Landgraf
> www.copaya.yi.org
> =
> 2.6.24-rc1-
Glauber de Oliveira Costa wrote:
>> +union kvm_hv_clock {
>> + struct {
>> + u64 tsc_mult;
>> + u64 now_ns;
>> + /* That's the wall clock, not the water closet */
>> + u64 wc_sec;
>> + u64 wc_nsec;
>>
Do we really nee
Rusty Russell wrote:
On Wednesday 07 November 2007 16:40:13 Avi Kivity wrote:
Gregory Haskins wrote:
but FWIW: This is a major motivation for the reason that the
IOQ stuff I posted a while back used strings for device identification
instead of a fixed length, centrally managed namespac
Avi Kivity wrote:
> Glauber de Oliveira Costa wrote:
>
>>> +union kvm_hv_clock {
>>> + struct {
>>> + u64 tsc_mult;
>>> + u64 now_ns;
>>> + /* That's the wall clock, not the water closet */
>>> + u64 wc_sec;
>>> + u64 wc
On Wednesday 07 November 2007 16:40:13 Avi Kivity wrote:
> Gregory Haskins wrote:
> > but FWIW: This is a major motivation for the reason that the
> > IOQ stuff I posted a while back used strings for device identification
> > instead of a fixed length, centrally managed namespace like PCI
> > vend
> On Thu, 1 Nov 2007 23:30:13 +0200 "Denys" <[EMAIL PROTECTED]> wrote:
> Finally i got full DMESG with 1GB card till end. Seems not readable too.
>
> Linux version 2.6.24-rc1-git10-embedded ([EMAIL PROTECTED]) (gcc
> version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #1 Thu Nov 1 23:12:53 EET 2007
> BIOS-provi
> On Fri, 2 Nov 2007 06:23:48 -0700 (PDT) Alex Dubov <[EMAIL PROTECTED]> wrote:
> After a much longer, than expected, time I managed to implement a support for
> MemoryStick (read-only currently, as there's still a subtle data corruption
> bug with writes) and MemoryStick Pro cards. The implement
On Tue, 6 Nov 2007 22:15:37 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 2 Nov 2007 06:23:48 -0700 (PDT) Alex Dubov <[EMAIL PROTECTED]>
> > wrote:
> >
> > I also wonder, where do I send the patches if nobody currently maintains
> > this thing?
> >
>
> Me, Pierre, lkml?
I'm not
On Tue, Oct 30, 2007 at 05:50:56PM +0900, Simon Horman wrote:
> On Tue, Oct 30, 2007 at 12:36:22AM -0700, David Miller wrote:
> > From: Simon Horman <[EMAIL PROTECTED]>
> > Date: Tue, 30 Oct 2007 16:15:13 +0900
> >
> > > Though curiuously with my config nothing uses per_cpu_offset()
> > > (I added
In message <[EMAIL PROTECTED]>, David Howells writes:
> From: David Howells <[EMAIL PROTECTED]>
>
> Stop the UnionFS filesystem from using iget() and read_inode(). Replace
> unionfs_read_inode() with unionfs_iget(), and call that instead of iget().
> unionfs_iget() then uses iget_locked() directl
per_cpu_offset() was added as part of a lockdep patch,
"[PATCH] lockdep: add per_cpu_offset()"
(a875a69f8b00a38b4f40d9632a4fc71a159f0e0d),
but ia64 doesn't have lockdep, nor does it use per_cpu_offset()
anywhere else.
This came up because Yu Lumming noticed that the ia64 version
of per_cpu_offset(
On Wed, Nov 07, 2007 at 02:26:09PM +1100, Stephen Rothwell wrote:
> On Wed, 7 Nov 2007 14:17:17 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
> > >
> > > Could you try with the attached 4 patches? Two of them are expected to
NAK for now.
I'm trying to add lockdep , so please don't delete it until it could
be proved really useless...
Please don't hurry...
On 11/7/07, Simon Horman <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 30, 2007 at 05:50:56PM +0900, Simon Horman wrote:
> > On Tue, Oct 30, 2007 at 12:36:22AM -0700, Dav
From: David Howells <[EMAIL PROTECTED]>
Stop UnionFS from using iget() and read_inode(). Replace
unionfs_read_inode() with unionfs_iget(), and call that instead of iget().
unionfs_iget() then uses iget_locked() directly and returns a proper error
code instead of an inode in the event of an error
On Wed, Nov 07, 2007 at 07:02:20AM +0100, Adrian Bunk wrote:
> On Wed, Nov 07, 2007 at 12:01:12AM +0100, Sam Ravnborg wrote:
> >...
> > config X86_SPEEDSTEP_CENTRINO
> > - tristate "Intel Enhanced SpeedStep"
> > + tristate "Intel Enhanced SpeedStep (deprecated)"
> > select CPU_FREQ_TABLE
>
On 11/7/07, David Chinner <[EMAIL PROTECTED]> wrote:
> Ok, so it's not synchronous writes that we are doing - we're just
> submitting bio's tagged as WRITE_SYNC to get the I/O issued quickly.
> The "synchronous" nature appears to be coming from higher level
> locking when reclaiming inodes (on the
On Wed, Nov 07, 2007 at 08:06:44AM +0100, Sam Ravnborg wrote:
> On Wed, Nov 07, 2007 at 07:02:20AM +0100, Adrian Bunk wrote:
> > On Wed, Nov 07, 2007 at 12:01:12AM +0100, Sam Ravnborg wrote:
> > >...
> > > config X86_SPEEDSTEP_CENTRINO
> > > - tristate "Intel Enhanced SpeedStep"
> > > + tristate "
If __alloc_bootmem_core was given a goal, it will first try to allocate
memory above that goal. If failed, it will try from the low pages.
Sometimes we don't want this behavior, we want the goal to be strict.
This patch introduce a strict_goal parameter to __alloc_bootmem_core,
If strict_goal i
Try to allocate sparse vmemmap block above 4G on x64 system.
On some single node x64 system with huge amount of physical memory e.g >
64G. the memmap size maybe very big.
If the memmap is allocated from low pages, it may occupies too much
memory below 4G.
then swiotlb could fail to reserve boun
NAK for now.
I'm trying to add lockdep , so please don't delete it until it could
be proved really useless...
Please don't hurry...
On 11/7/07, Simon Horman <[EMAIL PROTECTED]> wrote:
> per_cpu_offset() was added as part of a lockdep patch,
> "[PATCH] lockdep: add per_cpu_offset()"
> (a875a69f8b0
Hi,
oom-killer got invoked while running ltp-runall on the 2.6.24-rc2 kernel.
python invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Call Trace:
[] oom_kill_process+0x4f/0xf5
[] out_of_memory+0x1bc/0x22d
[] __alloc_pages+0x282/0x313
[] __wait_on_bit_lock+0x5b/0x66
[] __do_page_
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Fri, 26 Oct 2007 18:04:22 -0600
> So if this is really something we want to stop doing we should
> be able to take a few extra moments remove the code from the
> two problem drivers, and remove the exports.
I've killed the references in dlm and rr
On Tuesday November 6, [EMAIL PROTECTED] wrote:
> > On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> > Al Boldi wrote:
> > > There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
> > > entries) using a simple ls -l.
> > >
> > > On 2.6.23 client and server
Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
---
diff -urNp linux-2.6.24-rc2-orig/drivers/ata/sata_nv.c
linux-2.6.24-rc2/drivers/ata/sata_nv.c
--- linux-2.6.24-rc2-orig/drivers/ata/sata_nv.c 2007-11-07 10:28:41.0
+0900
+++ linux-2.6.24-rc2/drivers/ata/sata_nv.c 2007-
On Wednesday 07 November 2007 17:19, Andrew Morton wrote:
> > On Tue, 06 Nov 2007 05:08:07 -0500 Chris Snook <[EMAIL PROTECTED]> wrote:
> >
> > Don Porter wrote:
> > > From: Donald E. Porter <[EMAIL PROTECTED]>
> > >
> > > In the bulk page allocation/free routines in mm/page_alloc.c, the zone
> > >
Kamalesh Babulal wrote:
> Hi,
>
> oom-killer got invoked while running ltp-runall on the 2.6.24-rc2 kernel.
>
> python invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
>
> Call Trace:
> [] oom_kill_process+0x4f/0xf5
> [] out_of_memory+0x1bc/0x22d
> [] __alloc_pages+0x282/0x313
>
401 - 450 of 450 matches
Mail list logo
