On Mon, 4 Jun 2007, Davide Libenzi wrote:
> On Mon, 4 Jun 2007, Andrew Morton wrote:
>
> > a) Were IDR trees evaluated and if so, why were they rejected?
> >
> > b) it's a bit disappointing that this new allocator is only usable for
> >one specific application. We have a *lot* of places in
The core change is that the isolate_lru_pages() call is
replaced with struct scan_controll->isolate_pages() call.
Other changes include exporting __isolate_lru_page() for
per-container isolator and handling variable-to-pointer
changes in try_to_free_pages().
This makes possible to use different i
Nick Piggin wrote:
The question is, why is that not enough (I haven't looked at these
patches enough to work out if there is anything more they provide).
I think, it just takes trying things out. From reading the code, I
think this should work well for the filemap_xip code with no struct page.
A
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> Bitmaps are already there, you didnt zap them.
>
> Your proposal is going to double size taken by file table, since you need two
> long words
> per file instead of one pointer.
>
> You add conditional branches on very hot spots.
>
> When you open/close
> Cc: Alan Cox <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Looks good to me - and I can confirm no libata problem reports from us
always setting modes ourselves.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> You add conditional branches on very hot spots.
Keep BS for the ones you argue usually, and that are not able to reply.
You *still* two bitmaps, because allocation spaces are far apart. So the
"if" will still be there.
- Davide
-
To unsubscribe from
The core routines for tracking the page ownership, RSS subsystem
registration in the containers and the definition of the
rss_container struct as container subsystem combined with the
resource counter structure.
To make the whole set look more consistent the calls to the
reclamation code and oo
Hi!
> > CONFIG_BLINK=y
> > OOps. WTF is that?
> >
> > config BLINK
> > tristate "Keyboard blink driver"
> > help
> > Driver that when loaded will blink the keyboard LEDs
> > continuously.
> > This is useful for debugging and for kernels that cannot
> > necessarily
> > ou
When container is completely out of memory some tasks should die.
This is unfair to kill the current task, so a task with the largest
RSS is chosen and killed. The code re-uses current OOM killer
select_bad_process() for task selection.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
---
Implement try_to_free_pages_in_container() to free the
pages in container that has run out of memory.
The scan_control->isolate_pages() function is set to
isolate_pages_in_container() that isolates the container
pages only. The exported __isolate_lru_page() call
makes things look simpler than in t
On Mon, 4 Jun 2007, Pavel Machek wrote:
> I'm not sure, and stuck keys are quite hard to reproduce. It only
> happened twice in two days. But I've never seen stuck key on this
> thinkpad x60 before, so...
Dmitry should be on CC here, re-added.
--
Jiri Kosina
-
To unsubscribe from this list: s
On Mon, 2007-06-04 at 11:12 +0200, Jörn Engel wrote:
> On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
> > On Sunday 03 June 2007, Jörn Engel wrote:
> > > +struct logfs_je_spillout {
> > > + __be64 so_segment[0];
> > > +}__packed;
> >
> > All the on-disk data structures you define
As described, pages are charged to their first touchers.
The first toucher is determined using pages' _mapcount
manipulations in rmap calls.
A page is charged in two stages:
1. preparation, in which the resource availability is checked.
This stage may lead to page reclamation, thus it is perfo
On Monday 04 June 2007 15:12, Jiri Kosina wrote:
> Are you sure that it's this dummy blink driver that makes the kernel
> stuck? I can't see how it could be causing any hogs - see commit f038f9.
>
> Anyway, added Andi to CC.
Hmm, in theory it could be triggering bugs in some buggy keyboard
contro
> Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
> call with a nonblocking flag return EAGAIN if its going to take
> anywhere near 415ms?
Violation of causality. We don't know it will block for 415ms until 415ms
have elapsed.
Alan
-
To unsubscribe from this list: send the l
On Mon, 2007-06-04 at 10:54 +0200, Jörn Engel wrote:
> There is no particular reason. '3' should be a reasonable value for
> most people. If actual users want to change this value, I can make it
> a mount option as well. Right now I'm just lazy and doubt the merits.
I think you probably made th
Naturally mm_struct determines the resource consumer in memory
accounting. So each mm_struct should have a pointer on container
it belongs to. When a new task is created its mm_struct is
assigned to the container this task belongs to.
include/linux/rss_container.h is added in this patch to make
th
On Mon, 4 Jun 2007 05:55:42 -0700 (PDT)
Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Jun 2007, Eric Dumazet wrote:
>
> > Goals :
> > 1) libc wants 'private fds'
> > 2) Latencies of get_unused_fd() for huge processes (more than 100.000 file
> > handles)
> >
> > Point 1) can use a top-do
Each page is supposed to have an owner - the container
that touched the page first. The owner stays alive during
the page lifetime even if the task that touched the page
dies or moves to another container.
This ownership is the forerunner for the "fair" page sharing
accounting, in which page has a
On Mon, 4 Jun 2007, Ingo Molnar wrote:
>
> a simple ssh login triggers a ~130 msecs non-preemptible latency even
> with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!).
Thanks for the report.
>
> the latency is caused by a _very_ long loop in the SELinux code:
>
> sshd-4828 0.N.. 465
Hi!
> > Are you sure that it's this dummy blink driver that makes the kernel
> > stuck? I can't see how it could be causing any hogs - see commit f038f9.
> >
> > Anyway, added Andi to CC.
>
> Hmm, in theory it could be triggering bugs in some buggy keyboard
> controller. But then a
>
> while tr
On 6/3/07, Neil Brown <[EMAIL PROTECTED]> wrote:
Have you tried the "nocto" mount option for your NFS filesystems.
The cache-coherency rules of NFS require the client to check with the
server at each open. If you are the sole client on this filesystem,
then you don't need the same cache-cohere
Oleg Nesterov wrote:
> On 06/02, Mark Hounschell wrote:
>> Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
>> c201dbc0 10012 10012
>> Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
>> Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x8
>> Jun 2 16:36:11 harley
On 6/4/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Hi!
> > Are you sure that it's this dummy blink driver that makes the kernel
> > stuck? I can't see how it could be causing any hogs - see commit f038f9.
> >
> > Anyway, added Andi to CC.
>
> Hmm, in theory it could be triggering bugs in some bu
Hi,
The stock 2.6.22-rc3 (with no alien modules or patchs) on my i386 desktops
fired this message in loop like a mad (thousands of times/second) until
reboot, for no evident reason (I mean, I don't know what I did to get this,
from an end-user perspective : I was just editing text on vim and surfi
On 6/4/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
> call with a nonblocking flag return EAGAIN if its going to take
> anywhere near 415ms?
Violation of causality. We don't know it will block for 415ms until 415ms
have elapsed.
On Mon, 4 June 2007 14:38:23 +0100, David Woodhouse wrote:
> On Mon, 2007-06-04 at 11:12 +0200, Jörn Engel wrote:
> > On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
> > > On Sunday 03 June 2007, Jörn Engel wrote:
> > > > +struct logfs_je_spillout {
> > > > + __be64 so_segment[0];
>
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> O(1) lookup doesnt imply it needs to be super-fast. You make a
> confusion about this.
Davide has written many good speedups for the kernel and he is one of
the best scalability experts the Linux kernel has today. You could learn
from Davide a thing
Hi!
> >> > Anyway, added Andi to CC.
> >>
> >> Hmm, in theory it could be triggering bugs in some buggy keyboard
> >> controller. But then a
> >>
> >> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps
> >-numlock ;
> >> sleep 1 ; done
> >>
> >> should trigger it too.
> >
> >...and
* James Morris <[EMAIL PROTECTED]> wrote:
> > the latency is caused by a _very_ long loop in the SELinux code:
> >
> > sshd-4828 0.N.. 465894us : avtab_search_node
> > (context_struct_compute_av)
>
> What do the 0DNs fields mean and what did you use to create this
> trace?
i used the la
> "Aaron" == Aaron Wiebe <[EMAIL PROTECTED]> writes:
Aaron> On 6/4/07, Alan Cox <[EMAIL PROTECTED]> wrote:
>>
>> > Now, I'm a userspace guy so I can be pretty dense, but shouldn't a
>> > call with a nonblocking flag return EAGAIN if its going to take
>> > anywhere near 415ms?
>>
>> Violation
Replying to David Schwartz here.. (David, good to hear from you again
- haven't seen you around since the irc days :))
David Schwartz wrote:
There is no way you can re-try the request. The open must either succeed or
not return a handle. It is not like a 'read' operation that has an "I didn't
d
On 6/4/07, John Stoffel <[EMAIL PROTECTED]> wrote:
So how many files are in the directory where you're seeing the delays?
And what's the average size of the files in there?
The directories themselves will have a maximum of 160 files, and the
files are maybe a few megs each - the delays are (as
On Mon, 4 Jun 2007 16:12:35 +0200
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > O(1) lookup doesnt imply it needs to be super-fast. You make a
> > confusion about this.
>
> Davide has written many good speedups for the kernel and he is one of
> the
On Mon, 4 Jun 2007 06:35:16 -0700 (PDT)
Davide Libenzi <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Jun 2007, Eric Dumazet wrote:
>
> > You add conditional branches on very hot spots.
>
> Keep BS for the ones you argue usually, and that are not able to reply.
> You *still* two bitmaps, because allocat
Thomas Voegtle wrote:
Thx for your answer. Unfortunately, it didn't help us yet in finding a fix
for the problem.
The first IRQs are received after the call to pci_enable_device, but
before the IRQ handler itself is registered (register_irq). The IRQs seem
to be triggered by the write operati
On Monday 04 June 2007 15:12, Pavel Machek wrote:
> How will kernel work with very long paths? I'd suspect some problems,
> if path is 1MB long and I attempt to print it in /proc
> somewhere.
Pathnames are only used for informational purposes in the kernel, except in
AppArmor of course. /proc onl
Olivier Galibert wrote:
On Tue, May 29, 2007 at 10:03:32PM -0600, Robert Hancock wrote:
-Validate that the area is reserved even if we read it from the
chipset directly and not from the MCFG table. This catches the case
where the BIOS didn't set the location properly in the chipset and
has mappe
Sorry for the unthreaded responses, I wasn't cc'd here, so I'm
replying to these based on mailing list archives
Al Viro wrote:
BTW, why close these suckers all the time? It's not that kernel would
be unable to hold thousands of open descriptors for your process...
Hash descriptors by pathna
On 2007.06.04 15:55:14 +0200, Benjamin Pineau wrote:
> Hi,
> The stock 2.6.22-rc3 (with no alien modules or patchs) on my i386 desktops
> fired this message in loop like a mad (thousands of times/second) until
> reboot, for no evident reason (I mean, I don't know what I did to get this,
> >from an
Hi,
I just put the latest drivers in git:
git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux-2.6.git
currently ixp4xx-21 branch only (= based on 2.6.21).
Qmgr, NPE, Ethernet, HSS. This is my "export" repository, it doesn't
contain the history, though I'll try not to rebase it (or otherwi
On 2007.06.04 16:39:25 +0200, Björn Steinbrink wrote:
> On 2007.06.04 15:55:14 +0200, Benjamin Pineau wrote:
> > lspci -vv, lspci -vn, /proc/config.gz, /proc/timer_list, lsmod,
> > /proc/interrupts, /proc/vmstat, ps auxf, and dmesg (with and
> > without the bug's logs) outputs at
> > http://oshima
> > > I agree the risk is low, but if something _does_ blow up, it will do so
> > > subtly.
>
> Arguable the proposed badptr behavior is correct. It's basically "how many
> angels can dance on the head of a pin"? All the returned pointers are
> at least 0 bytes away from the previous one.
C++ ve
On Tue, 29 May 2007, Stephane Eranian wrote:
> --- linux-2.6.22.base/perfmon/perfmon_syscalls.c 1969-12-31
> 16:00:00.0 -0800
> +++ linux-2.6.22/perfmon/perfmon_syscalls.c 2007-05-29 03:24:14.0
> -0700
> @@ -0,0 +1,991 @@
> +/*
> + * perfmon_syscalls.c: perfmon2 system cal
On Mon, June 4, 2007 14:38, Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Indan Zupancic wrote:
>
>> > I also get some stuck keys I was not getting before. I hope my
>> > userland did not go crazy...
>> I get that too, and wasn't sure about it either. It happens irregularly,
>> so it's hard to debug, bu
On Tue, 29 May 2007, Stephane Eranian wrote:
> This patch contains the modified powerpc files.
>
>
> The modified files are as follows:
>
> arch/powerpc/Kconfig:
> - add link to perfmon menuconfig options
>
> arch/powerpc/Makefile:
> - add perfmon subdir
>
> arch/powerpc/kernel/en
On Tue, 29 May 2007, Stephane Eranian wrote:
> This patch contains the remaining infrastructure changes required
> for perfmon2 for all architectures. It is expected that this patch
> will be obsolete by 2.6.23.
>
> all arch:
> - remove unused TIF_NOTIFY_RESUME (already in -mm)
>
> mips:
>
Hello All
I am forwarding one improved patch related with Fork
Bombing Attack. This patch prints a message (only once) which alerts
administrator/root user about fork bombing attack. I created this
patch to implement my idea of informing administrator about fork
bombing attack on his ma
On Mon, 2007-06-04 at 08:28 +0100, Christoph Hellwig wrote:
> On Sun, Jun 03, 2007 at 12:55:04PM +0200, Geert Uytterhoeven wrote:
> > From: Michael Schmitz <[EMAIL PROTECTED]>
> >
> > Atari SCSI driver fixes: remove update_timeout kludge
>
> Looks good. James, can you send this on for 2.6.22 so t
On Mon, 4 Jun 2007, Eric Dumazet wrote:
> On Mon, 4 Jun 2007 06:35:16 -0700 (PDT)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 4 Jun 2007, Eric Dumazet wrote:
> >
> > > You add conditional branches on very hot spots.
> >
> > Keep BS for the ones you argue usually, and that are not
On Tue, 29 May 2007, Stephane Eranian wrote:
> --- linux-2.6.22.base/perfmon/perfmon_ctxsw.c 1969-12-31 16:00:00.0
> -0800
> +++ linux-2.6.22/perfmon/perfmon_ctxsw.c 2007-05-29 03:24:14.0
> -0700
> @@ -0,0 +1,341 @@
> +/*
> + * perfmon_cxtsw.c: perfmon2 context switch code
>
On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
>I am forwarding one improved patch related with Fork Bombing
> Attack. This patch prints a message (only once) which alerts
> administrator/root user about fork bombing attack. I created this patch
> to implement my idea of informing admi
Hello all,
I am using kernel 2.6.20-16 (Ubuntu Feisty). Occasionally I am getting
USB host controller halts. If I manually remove and reinsert the
uhci_hcd module, everything is back to normal. I recompiled the kernel
with the CONFIG_USB_DEBUG option on and waited until a halt occurred.
The d
On 2007.06.04 16:13:45 +0200, Pavel Machek wrote:
> Hi!
>
> > >> > Anyway, added Andi to CC.
> > >>
> > >> Hmm, in theory it could be triggering bugs in some buggy keyboard
> > >> controller. But then a
> > >>
> > >> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps
> > >-numlock ;
On Mon, May 07, 2007 at 01:45:11PM -0400, Lennart Sorensen wrote:
> Hmm, I thought I saw it on two systems already, but I should go try that
> again.
Hmm, still haven't figured this out. I just saw this one this morning:
BUG: soft lockup detected on CPU#0!
[] dump_stack+0x24/0x30
[] softlockup
On Fri, 1 Jun 2007, Andrew Morton wrote:
> They are different instances which happen to have the same length (zero).
On 6/2/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
I guess one could use the slab allocators as a type of reservation
ticket generator with zero sized objects. Hmmm But
On Mon, June 4, 2007 15:12, Jiri Kosina wrote:
> Are you sure that it's this dummy blink driver that makes the kernel
> stuck? I can't see how it could be causing any hogs - see commit f038f9.
To make it clear, I'm not using the blink driver and get the stuck
key problem too. (And also a warpy PS/
Hi!
> > > >[EMAIL PROTECTED]:~$ while true; do setleds +num; setleds -num; done
> > > >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> > > >
> > > >[EMAIL PROTECTED]:~$
> > > >
> > > >...but I'm not quite sure it is a buggy keyboard. It happens _way_ too
> > > >often. Launch t
On 06/04/2007 11:42 AM, Rene Herman wrote:
[ ... ]
Unfortunately, I can make the box oops by just doing enough of those dd
runs in a row (this one with bs=2k count=128, oopsed the seventh time or
something):
===
BUG: unable to handle kernel paging request at virtual address 8c1d2071
printin
On Mon, Jun 04, 2007, Pavel Machek wrote:
>
> > >> Hmm, in theory it could be triggering bugs in some buggy keyboard
> > >> controller. But then a
> > >>
> > >> while true ; do setleds +caps +numlock ; sleep 1 ; setleds -caps
> > >> -numlock ; sleep 1 ; done
> > >>
> > >> should trigger it too.
>
On 06/04/2007 05:07 PM, Rene Herman wrote:
Call Trace:
[] __mitsumi_get_frame+0xc/0x16 [mitsumi]
[] mitsumi_get_frame+0x120/0x134 [mitsumi]
[] lock_timer_base+0x15/0x2f
[] cfq_set_request+0x0/0x144
Perhaps interesting (and perhaps not) -- I've been unable to reproduce
the OOPS after reboo
On Tue, 29 May 2007, Stephane Eranian wrote:
> diff --exclude=.git -urp linux-2.6.22.base/include/asm-i386/unistd.h
> linux-2.6.22/include/asm-i386/unistd.h
> --- linux-2.6.22.base/include/asm-i386/unistd.h 2007-05-29
> 03:17:41.0 -0700
> +++ linux-2.6.22/include/asm-i386/unistd.h
Hi!
> > Are you sure that it's this dummy blink driver that makes the kernel
> > stuck? I can't see how it could be causing any hogs - see commit f038f9.
>
> To make it clear, I'm not using the blink driver and get the stuck
> key problem too. (And also a warpy PS/2 mouse.)
>
> Wildly guessing:
On Tue, 29 May 2007, Stephane Eranian wrote:
> --- linux-2.6.22.base/perfmon/perfmon_res.c 1969-12-31 16:00:00.0
> -0800
> +++ linux-2.6.22/perfmon/perfmon_res.c2007-05-29 03:24:14.0
> -0700
> @@ -0,0 +1,344 @@
> +/*
> + * perfmon_res.c: perfmon2 resource allocations
>
On Tue, 29 May 2007, Stephane Eranian wrote:
> Only in linux-2.6.22/Documentation: perfmon2.txt
You need to send -N to diff(1) so this and perfmon.h, perfmon_dfl_smpl.h,
perfmon_fmt.h, and perfmon_pmu.h will be included in the patch. A
patchset should compile and work correctly at any time whe
On 6/4/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Hmm, this needs to be ran from console (not X). Can someone with
thinkpad try this?
Are you saying it works OK when run in X?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Björn Steinbrink wrote:
> On 2007.06.04 16:39:25 +0200, Björn Steinbrink wrote:
>> On 2007.06.04 15:55:14 +0200, Benjamin Pineau wrote:
>>> lspci -vv, lspci -vn, /proc/config.gz, /proc/timer_list, lsmod,
>>> /proc/interrupts, /proc/vmstat, ps auxf, and dmesg (with and
>>> without the bug's logs) o
Hi
I have system running the 2.6.20 kernel, and I am trying to use an eSATA
disk with it. The hardware in question is a 'NexStar-3' eSATA
enclosure, and inside it is a Seagate Barracuda 7200.10 750Gb SATA drive.
I am hooking this up to an ASUS M2N-MX motherboard using the SATA to
eSATA brac
On Monday 04 June 2007 10:58:41 Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
> >I am forwarding one improved patch related with Fork Bombing
> > Attack. This patch prints a message (only once) which alerts
> > administrator/root user about fork bombing attack. I crea
This patch fixes the problem seen when a container goes over its limit, the
reclaim is unsuccessful and the application is terminated. The problem
is that all pages are by default added to the active list of the RSS
controller. When __isolate_lru_page() is called, it checks to see if
the list that
This patch modifies the reclaim behaviour such that before calling the
container out of memory routine, it checks if as a result of the reclaim
(even though pages might not be fully reclaimed), the resident set size
of the container decreased before declaring the container as out of memory
Signe
The following series contains several patches which I'm hoping could see
some testing in -mm. They're all been seen before at some point. The LZO
ones are important due to the dependent patches, the swap write failure
ones have just fallen off the radar.
LZO
===
We've seen a lot of activity in at
Add LZO1X compression/decompression support to the kernel.
This is based on the standard userspace lzo library, particularly
minilzo with the headers much trimmed down and simplified for kernel
use. Its structured so that it diffs with the userspace version for ease
of future updating. All the bad
On Monday, June 4, 2007 5:12:50 Olivier Galibert wrote:
> On Tue, May 29, 2007 at 10:03:32PM -0600, Robert Hancock wrote:
> > -Validate that the area is reserved even if we read it from the
> > chipset directly and not from the MCFG table. This catches the case
> > where the BIOS didn't set the loc
Pass an optional struct page * to swap_free(), fixing up all users.
Have swap_free check the page for errors and if found, mark the swap
page as bad.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
include/linux/swap.h |4 ++--
kernel/power/swsusp.c |4 ++--
mm/memory.c
Add try_to_unuse_page_entry() which can be used to unuse page entries.
This needs try_to_unuse_anon() which is also added, similar to
try_to_unmap_anon().
Originally based on a patch by Nick Piggin from LKML with changes of my
own after hints from Hugh Dickins.
Signed-off-by: Richard Purdie <[EM
Check for pages with errors within shrink_page_list() and if found, try
to unuse them which will trigger the functions to mark the page bad. The
page will then be allocated a new swap page.
If a swap page write error occurs, don't disable page reclaim.
Based on a patch by Nick Piggin and some of
On Sunday, June 3, 2007 2:15:06 Matt Keenan wrote:
> Justin Piszcz wrote:
> > On Sat, 2 Jun 2007, Andi Kleen wrote:
> >>> I feel, having a silent/transparent workaround is not a good idea.
> >>> With that
> >>
> >> If enough RAM is chopped off users will notice. They tend to complain
> >> when they
Hi everyone.
I am having some difficulty trying to get my 4Gb of ram recognized by
the system. I have tried googling around to get some information on how
to do this configuration, but I have come up dry. I suspect that the
reason that there is not much info on how to set things up is becaus
On Monday 04 June 2007 04:57:21 am Antonio Mignolli wrote:
> The problem reported below has not been solved,
> I tried with the last stable kernel 2.6.21.3.
>
> But it seems not to be an ACPI issue,
> I removed ACPI support from the kernel,
> and still have the problem.
> What else could be?
The
On Mon, 2007-06-04 at 10:20 -0400, Aaron Wiebe wrote:
> I understand, but this is exactly the situation that I'm complaining
> about. There is no functionality to provide a nonblocking open - no
> ability to come back around and retry a given open call.
So exactly how would you expect a nonblocki
On 6/4/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
On Sunday, June 3, 2007 2:15:06 Matt Keenan wrote:
> Justin Piszcz wrote:
> > On Sat, 2 Jun 2007, Andi Kleen wrote:
> >>> I feel, having a silent/transparent workaround is not a good idea.
> >>> With that
> >>
> >> If enough RAM is chopped off us
On Mon, 4 Jun 2007, Ray Lee wrote:
On 6/4/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
On Sunday, June 3, 2007 2:15:06 Matt Keenan wrote:
> Justin Piszcz wrote:
> > On Sat, 2 Jun 2007, Andi Kleen wrote:
> >>> I feel, having a silent/transparent workaround is not a good idea.
> >>> With that
>
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
- catch use of volatile
- allow deprecated functions to be listed in feature-removal-schedule
On Monday, June 4, 2007 8:48:37 Ray Lee wrote:
> On 6/4/07, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Sunday, June 3, 2007 2:15:06 Matt Keenan wrote:
> > > Justin Piszcz wrote:
> > > > On Sat, 2 Jun 2007, Andi Kleen wrote:
> > > >>> I feel, having a silent/transparent workaround is not a good
[Jan Kara - Fri, Jun 01, 2007 at 11:10:36PM +0200]
| On Wed 30-05-07 16:46:28, Eric Sandeen wrote:
| > Jan Kara wrote:
| > > Hello,
| > >
| > > On Thu 24-05-07 19:05:54, Jan Kara wrote:
| > >> Hello,
| > >>
| > >> attached is a patch that fixes possible leakage of free blocks / use of
| > >>
On 6/4/07, Trond Myklebust <[EMAIL PROTECTED]> wrote:
So exactly how would you expect a nonblocking open to work? Should it be
starting I/O? What if that involves blocking? How would you know when to
try again?
Well, theres a bunch of options - some have been suggested in the
thread already.
On 6/4/07, Justin Piszcz <[EMAIL PROTECTED]> wrote:
On Mon, 4 Jun 2007, Ray Lee wrote:
> Ick. Systems that used to boot fine would then panic on a kernel
> upgrade. That's rather rude for a condition that's merely an
> optimization (using all memory), rather than one of correctness. A
> panic see
On Mon, 04 Jun 2007 17:04:39 -0400 Jesse Huang wrote:
> From: Jesse Huang <[EMAIL PROTECTED]>
>
> Change Logs:
> Search PHY address form 0, only for device ID 0x0200 (IP100A). Other device
> are from PHY address 1.
>
> Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
> ---
>
> drivers/net/sunda
On Jun 3 2007 22:47, Sam Ravnborg wrote:
>
>Make the "cleanfile" and "cleanpatch" script warn about long lines,
>by default lines whose visual width exceeds 79 characters.
Nice, nice. But, am I asking too much if tabs and kernel codestyle
could be used? (/me hides..., but see scripts/checkpatch.p
On Monday 04 June 2007 11:36:18 Richard Purdie wrote:
> The following series contains several patches which I'm hoping could see
> some testing in -mm. They're all been seen before at some point. The LZO
> ones are important due to the dependent patches, the swap write failure
> ones have just fall
On Mon, 4 Jun 2007, Pekka Enberg wrote:
> On Fri, 1 Jun 2007, Andrew Morton wrote:
> > > They are different instances which happen to have the same length (zero).
>
> On 6/2/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > I guess one could use the slab allocators as a type of reservation
> >
> From: Adrian Bunk [mailto:[EMAIL PROTECTED]
> >...
> > Changes since 2.6.22-rc2-mm1:
> >...
> > git-md-accel.patch
> >...
> > git trees
> >...
>
>
> The ASYNC_* options are for internal helper code and should therefore
> not be user visible.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
On 2007.06.04 17:10:25 +0200, Pavel Machek wrote:
> Hi!
>
> > > > >[EMAIL PROTECTED]:~$ while true; do setleds +num; setleds -num; done
> > > > >Hm,m so thiis iis a teest of fkeyboarad behaviour under lloadd.
> > > > >
> > > > >[EMAIL PROTECTED]:~$
> > > > >
> > > > >...but I'm not quite sure i
On 6/4/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
We are doing that right now. The problem is that people keep storing stuff
in memory allocated with kmalloc(0).
Ok, makes sense. I guess I might as well throw my suggestion in the
mix. Lets create a new kmalloc cache for zero-length object
On Mon, 04 Jun 2007 08:39:48 +0200
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-06-03 at 18:26 +0200, Maximilian Engelhardt wrote:
> > > Is there any other strange behavior of the high res enabled kernel than
> > > the b44 problem ?
> >
> > I didn't notice anything in the past (as I
Actually, lets see if I can summarize this more generically... I
realize I'm suggesting something that probably would be a massive
undertaking, but ..
Regular files are the only interface that requires an application to
wait. With any other case, the nonblocking interfaces are fairly
complete an
On Mon, 4 Jun 2007, Pekka Enberg wrote:
>
> Ok, makes sense. I guess I might as well throw my suggestion in the
> mix. Lets create a new kmalloc cache for zero-length objects where
> object size is zero but there are regular red-zones on both sides.
Well, the red-zones won't catch readers, and
In a few files a function such as usb_submit_urb is taking GFP_KERNEL
as an argument whereas this function call is inside a
spin_lock_irqsave region of code. Documentation says that it must be
GFP_ATOMIC instead.
Me and my colleagues have made a tool targeting program
transformations in device dr
On Jun 4 2007 10:46, Andy Whitcroft wrote:
>
> - catch use of volatile
Speaking of volatile, "register" is probably just as unwanted.
Then, "extern inline" is one thing to catch (does not happen
that often, but it does not cost too much either).
> - warn about #ifdef's in c files
Really? Ther
101 - 200 of 504 matches
Mail list logo
