On Sun, Dec 16, 2007 at 12:45:01PM +0100, Eric Dumazet wrote:
> While examining vmlinux namelist on i686, I noticed :
>
> c0581300 D random_table
> c0581480 d input_pool
> c0581580 d random_read_wakeup_thresh
> c0581584 d random_write_wakeup_thresh
> c0581600 d blocking_pool
>
> That means that the
On Wed, Dec 12, 2007 at 07:54:52PM +0100, Kristoffer Ericson wrote:
> On Thu, 13 Dec 2007 03:45:58 +0900
> Paul Mundt <[EMAIL PROTECTED]> wrote:
> > On Wed, Dec 12, 2007 at 07:22:07PM +0100, Kristoffer Ericson wrote:
> > > * This patch fixes the HP Jornada 6xx keyboard default keymap which
> > > ha
On Sun, Dec 16, 2007 at 07:56:56PM +0800, Herbert Xu wrote:
>
> What's spooky is that I just did a google and we've had reports
> since 1998 all crashing on exactly the same line in tcp_recvmsg.
However, there's been no reports at all since 2000 apart from this
one so the earlier ones are probably
> But use of this filesystem is still valid when this filesystem is used with
> policy based mandatory access control (such as SELinux, TOMOYO Linux)
> because this filesystem guarantees where policy based mandatory access control
> can't guarantee (i.e. filename and its attribute).
>
Policy base
From: Linus Torvalds <[EMAIL PROTECTED]>
This shouldn't really change behavior all that much, but the single
rather complex function with read-ahead inside a loop etc is broken up
into more manageable pieces.
The behaviour is also less subtle, with the read-ahead being done up-front
rather than
No differences except for the defintion of local_add_return on
X86_64. The X86_32 version is just fine as it is protected with
ifdef CONFIG_M386 so use it directly.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-x86/local.h| 149 ++-
Simplify code by moving max_sane_readahead() calls into
force_page_cache_readahead().
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/fadvise.c |2 +-
mm/filemap.c |3 +--
mm/madvise.c |3 +--
mm/readahead.c |1 +
4 files changed, 4 insertions(+), 5 deletions(-)
---
When the user explicitly sets MADV_SEQUENTIAL, we should really avoid the slow
readahead size ramp-up phase and start full-size readahead immediately.
This patch won't change behavior for the auto-detected sequential mmap reads.
Its previous read-around size is ra_pages/2, so it will be doubled to
It is insane and error-prone to insist on the call sites to check for async
readahead after doing any sync one. I.e. whenever someone do a sync readahead:
if (!page)
page_cache_sync_readahead(...);
He must try async readahead
Change mmap read-around to share the same code style and data structure
with readahead code.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/filemap.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
--- linux-2.6.24-rc4-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc4-mm1
Make ra_submit() non-static and callable from other files.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
---
include/linux/mm.h |3 +++
mm/readahead.c |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
--- linux-2.6.24-rc4-mm1.orig/include/linux/mm.h
+++ linux-2.6.24-rc4-mm
Remove do_page_cache_readahead().
Its last user, mmap read-around, has been changed to call ra_submit().
Also, the no-readahead-if-congested logic is not appropriate here.
Raw 1-page reads can only makes things painfully slower, and
users are pretty sensitive about the slow loading of executables
Apply the max_sane_readahead() limit in ondemand_readahead().
Just in case someone aggressively set a huge readahead size.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/readahead.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc4-mm1.orig/mm/readahead.c
Auto-detect sequential mmap reads and do sync/async readahead for them.
The sequential mmap readahead will be triggered when
- sync readahead: it's a major fault and (prev_offset==offset-1);
- async readahead: minor fault on PG_readahead page with valid readahead state.
It's a bit conservative to
Andrew,
Here are the mmap read-around related patches initiated by Linus.
They are for linux-2.6.24-rc4-mm1. The one major new feature -
auto detection and early readahead for mmap sequential reads - runs
as expected on my desktop :-)
[PATCH 1/9] readahead: simplify readahead call scheme
[PATCH
Hello.
David Newall wrote:
> > You won't be able to login to the system because /sbin/mingetty
> > fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode.
>
> Good point. So, if only root can modify files in /dev, what's the
> problem you're fixing? (I'm sure you tried to expla
Introduce macros to deal with X86_32 using longs and X86_64
using quads. Small comment fixes to make files match.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-x86/local.h| 17 +
include/asm-x86/local_32.h | 28 ++--
include/as
Common prefix from both files moved to local.h
Change __inline__ to inline
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-x86/local.h| 19 +--
include/asm-x86/local_32.h | 34 ++
include/asm-x86/local_64.h | 25 ++-
Use the shorter +m form rather than =m and m.
Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]>
---
include/asm-x86/local_64.h | 30 ++
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/include/asm-x86/local_64.h b/include/asm-x86/local_64.h
index da6
Tetsuo Handa wrote:
I meant that "/dev must be mounted for read-write mode"
Again, why?
You won't be able to login to the system because /sbin/mingetty
fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode.
Good point. So, if only root can modify files in /de
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> Dec 7 17:20:53 sata_fileserver kernel: Code: 6c 39 df 74 59 8d b6 00
>> 00 00 00 85 db 74 4f 8b 55 cc 8d 43 20 8b 0a 3b 48 18 0f 88 f4 05 00
>> 00 89 ce 2b 70 18 8b 83 90 00 00 00 <0f> b6 50 0d 89 d0 83 e0 02 3c
>> 01 8b 43 50 83 d6 ff 39 c6 0f 82
While examining vmlinux namelist on i686, I noticed :
c0581300 D random_table
c0581480 d input_pool
c0581580 d random_read_wakeup_thresh
c0581584 d random_write_wakeup_thresh
c0581600 d blocking_pool
That means that the two integers random_read_wakeup_thresh and
random_write_wakeup_thresh use a
> cat /proc/kpageflags on sparc64 causes the box to lock.
> I can not write on any terminal - but I can issue sysrqs and switch
> between consoles.
>
> cat process hangs in read(3, ...
cat /proc/kpagecount produces similar symptoms. box is locked - sysrq-w sshd
trace:
__down
__down_inte
Hello.
> > I meant that "/dev must be mounted for read-write mode"
>
> Again, why?
You can mount / partition for read-only mode if you wish to do so.
But you cannot make /dev directory for read-only.
You won't be able to login to the system because /sbin/mingetty
fails to "chown/chmod" /dev/tty*
Tetsuo Handa wrote:
David Newall wrote:
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root.) Thi
Hello.
David Newall wrote:
> Tetsuo Handa wrote:
> > /dev needs to be writable, but this means that files on /dev might be
> > tampered with.
>
> I infer that you mean /dev needs to be writable by anyone, not by just
> its owner or owner and group (conventionally root/root.) This goes
> agai
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote:
>
> * John W. Linville <[EMAIL PROTECTED]> wrote:
>
> > > It's not that simple. For example, regression testing will be a
> > > major PITA if one needs to switch back and forth from the new driver
> > > to the old one in the process.
> >
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root.) This goes
against conventional wisdom, which is that /dev
On Sunday 16 December 2007 03:30:16 Larry Finger wrote:
> Michael Buesch wrote:
> > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> >> Well, the only problem with that is I suspect there are some "newer" cards
> >> that
> >> work better with v3 firmware, although they are supposed t
On Fri, 07 Dec 2007 19:49:52 -0800 jeffunit <[EMAIL PROTECTED]> wrote:
> I am running linux kernel 2.6.23.1, which I compiled.
> The base system was mandriva 2008.
>
> I have a dual processor pentium III 933 system.
> It has 3gb of ram, an intel stl-2 motherboard.
> It also has a promise 100 tx2
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
fs/Kconfig | 21 +
fs/Makefile |1 +
2 files changed, 22 insertions(+)
--- linux-2.6.24-rc5.orig/fs/Kconfig
+++ linux-2.6.24-rc5/fs/Kconfig
@@ -1555,6 +1555,27 @@ config UFS_DEBUG
Y here. This will result i
A brief description about SYAORAN:
SYAORAN stands for "Simple Yet All-important Object Realizing Abiding
Nexus". SYAORAN is a filesystem for /dev with Mandatory Access Control.
/dev needs to be writable, but this means that files on /dev might be
tampered with. SYAORAN can restrict combinatio
Hi,
2007/12/16, Russell King - ARM Linux <[EMAIL PROTECTED]>:
> On Tue, Dec 11, 2007 at 06:38:51PM +0300, Dmitry Baryshkov wrote:
> > Sorry, posted wrong version of patch. Here is correct version:
> >
> > Support keyboard on tosa (Sharp Zaurus SL-6000x).
> > Largely based on patches by Dirk Opfer.
On recent kernels, I get the following error when using an initrd:
| initrd overwritten (0x00b78000 < 0x07668000) - disabling it.
My Amiga 4000 has 12 MiB of RAM at physical address 0x0740 (virtual
0x).
The initrd is located at the end of RAM: 0x00b78000 - 0x00c0 (virtual).
The ov
Hello,
> Surprise surprise. The namespace seq patch missed two spots in
> AF_PACKET.
>
> [PACKET]: Fix /proc/net/packet crash due to bogus private pointer
>
> The seq_open_net patch changed the meaning of seq->private.
> Unfortunately it missed two spots in AF_PACKET, which still
> used the old
Hello.
I have proposed this filesystem a few years ago.
Once again, I'm proposing this filesystem toward inclusion into mainline.
I'll update for -mm tree if this filesystem is likely acceptable.
Regards.
(This is a resent message of [00/02] since it seems to be dropped.)
--
To unsubscribe from
Hello
> Will reply soon with correct data.
Ok here it goes:
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c
On Tue, Dec 11, 2007 at 06:38:51PM +0300, Dmitry Baryshkov wrote:
> Sorry, posted wrong version of patch. Here is correct version:
>
> Support keyboard on tosa (Sharp Zaurus SL-6000x).
> Largely based on patches by Dirk Opfer.
Looks fine to me, but Dmitry Torokhov needs to look at it; he maintain
> cat /proc/kpageflags on sparc64 causes the box to lock.
> I can not write on any terminal - but I can issue sysrqs and switch
> between consoles.
>
> cat process hangs in read(3, ...
>
> sysrq-w shows:
>
> syslogd D 0069240c 0 2470 1
> Call Trace:
> [0069
On Sun, 16 Dec 2007, [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9182
--- Comment #39 from [EMAIL PROTECTED] 2007-12-16 01:58 ---
So:
- 2.6.20-rc1: OK
- 2.6.20-rc1-git8 with fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 reverted: OK
- 2.6.20-rc1-git8: v
On Sun, Dec 16, 2007 at 06:50:19PM +0900, Paul Mundt wrote:
> > +static irqreturn_t gdrom_command_interrupt(int irq, void *dev_id)
> > +{
> > + if (dev_id != &gd)
> > + return IRQ_NONE;
>
> You aren't setting this up as a shared IRQ, so this shouldn't be
> necessary.
It's not nessecar
Hello,
cat /proc/kpageflags on sparc64 causes the box to lock.
I can not write on any terminal - but I can issue sysrqs and switch
between consoles.
cat process hangs in read(3, ...
sysrq-w shows:
syslogd D 0069240c 0 2470 1
Call Trace:
[00692224]
[000
On Sun, 16 Dec 2007 10:33:20 +0100 (CET) Krzysztof Oledzki <[EMAIL PROTECTED]>
wrote:
>
>
> On Sat, 15 Dec 2007, Andrew Morton wrote:
>
> > On Sun, 16 Dec 2007 00:08:52 +0100 (CET) Krzysztof Oledzki <[EMAIL
> > PROTECTED]> wrote:
> >
> >>
> >>
> >> On Sat, 15 Dec 2007, [EMAIL PROTECTED] wrote
Ok, I don't know anything about the CD-ROM layer, so I've just commented
on the general and SH-specific stuff. Hopefully someone with a clue
in this area (ie, not me) can offer input on the rest of the bits.
On Sun, Dec 16, 2007 at 12:21:21AM +, Adrian McMenamin wrote:
> +/* GD Rom registers *
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Pavel Machek wrote:
>>>
>>> this is also something for v2.6.24 merging.
>>
>> As much as I like this patch, I do not think it is suitable for
>> .24. Too risky, I'd say.
>>
>
> No kidding! We're talking about removing a hack that has been
> successf
On Sat, 15 Dec 2007, Andrew Morton wrote:
On Sun, 16 Dec 2007 00:08:52 +0100 (CET) Krzysztof Oledzki <[EMAIL PROTECTED]>
wrote:
On Sat, 15 Dec 2007, [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9182
--- Comment #33 from [EMAIL PROTECTED] 2007-12-15 14:19 --
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Paul Rolland wrote:
>> Just an idea : from what I've read, the problem (port 80 hanging) only occurs
>> on 'modern' machines...
>
> It happens on *one single* "modern" machine...
>
> Let's keep that in perspective.
two or three i think (and an unknow
* John W. Linville <[EMAIL PROTECTED]> wrote:
> > It's not that simple. For example, regression testing will be a
> > major PITA if one needs to switch back and forth from the new driver
> > to the old one in the process.
>
> Not really true -- a single system can easily have firmware install
On Sat, 2007-12-15 at 12:52 -0800, a_kumar wrote:
> I've a block device driver which does the following,
Why not send the actual code?
> This code works fine with most of the kernel versions, but fails on some
> like , Linux 2.6.18-8.el5-xen
You've provided no information. What we need:
*).
On Sat, 15 Dec 2007 22:20:24 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> FWIW, I got the following at reboot after some tests were finished:
>
> get_unused_fd: slot 3 not NULL!
> get_unised_fd: slot 4 not NULL!
> general protection fault: [1] PREEMPT SMP
> last sysfs file /sys/class/s
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Subject : 2.6.24-rc3-git2 softlockup detected
> Submitter : Kamalesh Babulal <[EMAIL PROTECTED]>
> Date : 2007-11-28 15:46
> References: http://lkml.org/lkml/2007/11/28/16
> http://bugzilla.kernel.org/
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 15, 2007 at 07:43:28PM +0100, Ingo Molnar wrote:
> >
> > we could perhaps introduce stat_smp_processor_id(), which signals that
> > the CPU id is used for statistical purposes and does not have to be
> > exact? In any case, your patch looks
Herbert Xu wrote:
> On Sat, Dec 15, 2007 at 11:08:58AM +0100, Tobias Diedrich wrote:
> >
> > Hmm, how do I look for that, if netstat doesn't look suspicous?
>
> Thanks. What does /proc/net/sockstat show?
[EMAIL PROTECTED]:~$ cat /proc/net/sockstat
sockets: used 143
TCP: inuse 16 orphan 0 tw 4 al
On Sat, Dec 15, 2007 at 11:56:04PM -0800, Andrew Morton wrote:
> On Sun, 16 Dec 2007 01:37:01 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
> > > On Sun, Dec 16, 2007 at 11:07:07AM +0800, Herbert Xu wrote:
So I posted this patch after 19:00 PST on 15 Dec.
> > Dec 15 13:44:39 syntropy kernel:
201 - 254 of 254 matches
Mail list logo
