I was trying to use inotify to watch process changes (especially process
termination) by watching /proc/.
Sadly, although I could see something reading various files, nothing
was issued when the process I was watching exited and the directory
went away.
Is this intentional, or a bug?
-Jose
On Mon, 30 Jul 2007, Valerie Henson wrote:
On Mon, Jul 30, 2007 at 03:31:58PM -0400, Kyle McMartin wrote:
On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote:
The Tulip network driver needs a new maintainer! I no longer have
time to maintain the Tulip network driver and I'm steppin
Running checkpatch.pl products an warning when it should not. I believe
it can be fixed by adding to the regular expression, but feel free to
fix it another way as I may not know all the cases this is trying to catch.
-- check patch output --
WARNING: declaring multiple variables together shou
On Mon, 2007-07-30 at 23:43 +0400, Alexey Dobriyan wrote:
> On Mon, Jul 30, 2007 at 12:42:07PM +0800, Bryan Wu wrote:
> > Can I do something to help this regression testing?
> >
> > Please feel free to ask me.
>
> Sorry, blackfin toolchain doesn't like me, so I can't test this myself.
> Check curr
On Mon, Jul 30, 2007 at 09:39:39PM +0200, Miklos Szeredi wrote:
> > Extrapolating these %cpu number makes ZFS the fastest.
> >
> > Are you sure these numbers are correct?
>
> Note, that %cpu numbers for fuse filesystems are inherently skewed,
> because the CPU usage of the filesystem process itse
Add "L2 cache is separated? check flag" as read_mostly global variable.
This add one memory reference to global variable to page faults of "executable"
map in do_wp_page(page copy case), file-mapped page fault and some system calls
which does memory map changes. But not so bad as calling sync_ica
Add Brand name "Montecito" to cpuinfo.
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
---
arch/ia64/kernel/setup.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.23-rc1.test/arch/ia64/kernel/setup.c
=
flush icache for ia64 take4.
This patch is against 2.6.23-rc1.
Changes V5 -> V6:
- no changes. (added new patches to the patch set)
Changes V4 -> V5:
- removed sync_icache_dcache from do_wp_page() page reuse case.
Changes v3 -> v4:
- avoid implementing flush_(i)cache_pages().
- added syn
In migration, a new page should be cache flushed before set_pte()
in some archs which have virtually-tagged cache..
V5 -> V6:
* no changes (added new patches to the patch set)
V4 -> V5:
* changed flush_icache_page to flush_cache_page.
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
--
On Mon, 2007-07-30 at 11:22 -0700, Andrew Morton wrote:
> On Mon, 30 Jul 2007 18:58:14 +0900
> Fernando Luis V__zquez Cao <[EMAIL PROTECTED]> wrote:
>
> > >
> > > So bad things might happen because of this change. And if they do, they
> > > will take a lng time to be discovered, because non
flush icache before set_pte() for ia64 patch set.
patches are against 2.6.23-rc1.
Changes:
- Added "Is Montecito?" check for optimization.
Thanks,
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Use the new bio_multi_split to simplify dm bio splitting.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/dm.c | 166 ++
1 file changed, 20 insertions(+), 146 deletions(-)
diff .prev/drivers/md/dm.c ./drivers/m
__make_request now handles bios with too many segments, and it tracks
segment counts in 'struct request' so we no longer need to track
the counts in each bio, or to check the counts when adding a page
to a bio.
So bi_phys_segments, bi_hw_segments, blk_recount_segments(),
BIO_SEG_VALID, bio_phys_se
Signed-off-by: Diego Woitasen <[EMAIL PROTECTED]>
---
drivers/md/dm.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 141ff9f..aebb207 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -282,17 +282,16 @@ static int dm_b
Stacking device drives (dm/md) no longer need to worry about
most queue limits as they are handled at a lower level. The
only limit of any interest at the top level now is the hard
sector size.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./block/ll_rw_blk.c |
__bio_add_page no longer needs 'max_sectors' and can now
only fail when the bio is full.
So raid1/raid10 do not need to cope with unpredictable failure of
bio_add_page, and can be simplified. Infact they get simplified so
much that they don't use bio_add_page at all (they we only using
before to
We only need to split bios if we want to read around the cache,
as when we go through the cache, the sharing is already done.
So use bio_multi_split to split up read requests, and get rid of
raid5_mergeable_bvec as it is no longer needed.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffst
pktcdvd now accepts arbitrarily large bios and will split as necessary.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/block/pktcdvd.c | 44
1 file changed, 12 insertions(+), 32 deletions(-)
diff .prev/drivers/block/pk
No driver calls blk_queue_merge_bvec or bio_split any more,
so they can go.
Also, several places test if merge_bvec_fn is set or not. As it is
now never set (it doens't even exist) they can be cleaned up too.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./block/ll_rw_blk.
Now that bi_io_vec and bio can be shared, we can handle arbitrarily
large bios in __make_request by splitting them over multiple
requests.
If we do split a request, we mark both halves as "REQ_NOMERGE".
It is only really necessary to mark the first part as
NO_BACK_MERGE
and the second part as
NO
As bi_io_vec is now never modified, bio_clone does not need to
copy it any more.
Make a new bio_multi_split function which can be used to split a single
bio into mutliple other bios dependant on the one parent.
Use that in raid0 and linear to handle any arbitrary bios,
and remove mergeable_bvec
.. using the new bio_multi_split.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/raid10.c | 70 ++
1 file changed, 14 insertions(+), 56 deletions(-)
diff .prev/drivers/md/raid10.c ./drivers/md/raid10.c
--- .prev/
If we are going to share a bio between requests, then the
last bio in a list may not point to NULL, but may point to
the next bio in a different list.
So instead of testing if ->bi_next is NULL, test if the bio
matches rq->biotail.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat outpu
For a request to be able to refer to part of a bio, we need to be able
to impose a size limit at the request level. So allow hard_nr_sectors
to be less than the size of the bios (and bio_vecs) and interpret it
such that anything in the last bio beyond that limit is ignored.
As some bios can be l
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/block/umem.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff .prev/drivers/block/umem.c ./drivers/block/umem.c
--- .prev/drivers/block/umem.c 2007-07-31 11:21:03.0 +1000
+++ ./dr
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/dm-crypt.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff .prev/drivers/md/dm-crypt.c ./drivers/md/dm-crypt.c
--- .prev/drivers/md/dm-crypt.c 2007-07-31 11:21:03.0 +1000
+++ .
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/block/pktcdvd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff .prev/drivers/block/pktcdvd.c ./drivers/block/pktcdvd.c
--- .prev/drivers/block/pktcdvd.c 2007-07-31 11:21:03.0 +1000
+++ ./dr
To allow bi_io_vec sharing, a bio now can reference just part of the
io_vec. In particular, the first bi_offset bytes are not included,
and exactly bi_size bytes are included, even if the bi_io_vec goes
beyond there.
bi_offset must be less than bv_len of the first bvec.
This patch only handles
i.e. instread of providing a pointer to each bio_vec, it provides
a copy of each bio_vec.
This allows a future patch to cause bio_for_each_segment to
provide bio_vecs that are not in the bi_io_vec list, thus allowing
for offsets and length restrictions.
We consequently remove the only call for b
It is almost always set to zero. The one case where it isn't
is in dm.c when splitting a bio. In this case we can simply offset
bi_io_vec rather than storing the offset in bi_idx.
bio_to_phys, bio_iovec, bio_page, bio_offset, bio_segments all depend
on bi_idx, so they go too.
Also __bio_for_ea
Drivers that define their own make_request_fn have no need of
bi_hw_back_size and bi_hw_front_size, and the code that does
use it is only ever interested in bi_hw_back_size for
rq->bio and bi_hw_front_size for rq->biotail
So move these fields from the bio into the request.
This involves passing
Every error return from ll_{front,back}_merge_fn sets
REQ_NOMERGE. So move this to after the call to these functions.
This is only a small saving here, but will help a future patch.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./block/ll_rw_blk.c | 43 +++
umem.c:
advances bi_idx and bi_sector to track where it is up to.
But it is only ever doing this on one bio, so the updated
fields can easily be kept elsewhere (current_*).
updates bi_size, but never uses the updated values, so
this isn't needed.
reuses bi_phys_segments to count how
ll_merge_requests_fn can update bi_hw_*_size in one case where we end
up not merging. This is wrong.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./block/ll_rw_blk.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff .prev/block/ll_rw_blk.c ./block/ll_rw_blk
These functions are always passed the last bio of one request
and the first of the next. So it can work to just pass the
two requests and let them pick off the bios. This makes life
easier for a future patch.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./block/ll_rw_blk.
blk_rq_bio_prep is exported for use in exactly
one place. That place can benefit from using
the new blk_rq_append_bio instead.
So
- change dm-emc to call blk_rq_append_bio
- stop exporting blk_rq_bio_prep, and
- initialise rq_disk in blk_rq_bio_prep,
as dm-emc needs it.
Signed-off-
These have very similar functions and should share code where
possible.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./block/ll_rw_blk.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff .prev/block/ll_rw_blk.c ./block/ll_rw_blk.c
--- .prev/block/ll_
When a read request that bypassed the cache needs to be retried
(due to device failure) we need to process it one stripe_head at a time,
and record where we were up to.
We were recording this in bi_hw_segments. But as there is only
ever one such request that is being resubmitted, this info can
be
ll_back_merge_fn is currently exported to SCSI where is it used,
together with blk_rq_bio_prep, in exactly the same way these
functions are used in __blk_rq_map_user.
So move the common code into a new function (blk_rq_append_bio), and
don't export ll_back_merge_fn any longer.
Signed-off-by: Nei
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Mon, 30 Jul 2007, Chris Wright wrote:
> > This also fixes paravirt patching which was broken when text_poke()
> > tried to patch the various pv ops in lookup_address.
>
> Hmm. What is "this"? The revert?
Yes, sorry, your revert also fixes paravirt
This count is currently only used by raid5 (which used to use bi_phys_segments),
but it will be used more widely in future.
generic_make_request sets the count to 1, and bio_endio decrements it and
calls bi_end_io only when it hits zero. A make_request_fn can do whatever
it likes if it doesn't c
As bi_end_io is only called once when the reqeust is compelte,
the 'size' argument is now redundant. Remove it.
Now there is no need for bio_endio to subtract the size completed
from bi_size. So don't do that either.
While we are at it, change bi_end_io to return void.
Signed-off-by: Neil Bro
Some requests signal partial completion. We currently record this
by updating bi_idx, bv_len, and bv_offset.
This is bad if the bi_io_vec is to be shared.
So instead keep in "struct request" the amount of the first bio
that has completed. This is "first_offset" (i.e. offset in to
first bio). U
Current bi_end_io can be called multiple times as sub-requests complete.
However no ->bi_end_io function wants to know about that. So
only call when the bio is complete.
Note that bi_sector and bi_size are now not updated when subrequests
complete. This does not appear to be a problem as they a
(almost) every usage of rq_for_each_bio wraps a usage of
bio_for_each_segment, so these can be combined into
rq_for_each_segment.
We get it to fill in a bio_vec structure rather than provide a
pointer, as future changes to make bi_io_vec immutable will require
that.
The one place where rq_for_ea
blk_recalc_rq_segments calls blk_recount_segments on each bio,
then does some extra calculations to handle segments that overlap
two bios.
If we merge the code from blk_recount_segments into
blk_recalc_rq_segments, we can process the whole request one bio_vec
at a time, and not need the messy cro
All calls to bio_cur_sectors are for the first bio in a 'struct request'.
A future patch will make the discovery of this number dependant on
information in the request. So change the function to take a
'struct request *' instread of a 'struct bio *', and make it a real
function as more code will
The following 35(!) patches achieve a refactoring of some parts of the
block layer to provide better support for stacked devices.
The core issue is that of letting bio_add_page know the limitation
that the device imposes so that it doesn't create a bio that is too large.
For a unstacked disk dev
Almost every call to bio_data is for the first bio
in a request. A future patch will add some accounting
information to 'struct request' which will need to be
used to find the start of the request in the bio.
So replace bio_data with blk_rq_data which takes a 'struct request *'
The one exception
On Mon, Jul 30, 2007 at 03:31:58PM -0400, Kyle McMartin wrote:
> On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote:
> > The Tulip network driver needs a new maintainer! I no longer have
> > time to maintain the Tulip network driver and I'm stepping down. Jeff
> > Garzik would be happ
[cc [EMAIL PROTECTED]
On Mon, Jul 30, 2007 at 12:10:52PM -0400, Ryan Bair wrote:
> Kernel: 2.6.18-4-amd64 (Debian 2.6.18.dfsg.1-12etch2) Debian Etch
> System: Dell PowerEdge 1850
> Processor: 3.2 GHz Intel Xeon w/ microcode v1.14a, Hyperthreading disabled.
> RAM: 2x1GB ECC DDR-400
> RAID Controlle
On 7/31/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> On 31.07.2007 00:17, Gabriel C wrote:
> > Sasa Ostrouska wrote:
> >
> >> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
> >> to check that, thx for the tip.
> >
> > Yes udev does this based on the MAC address bu
On Mon, 30 Jul 2007, Chris Wright wrote:
>
> This also fixes paravirt patching which was broken when text_poke()
> tried to patch the various pv ops in lookup_address.
Hmm. What is "this"? The revert?
That said, I do wonder whether virtualization still has problems with
CONFIG_RODATA, though
On Mon, 30 Jul 2007 20:17:18 -0400 Joe Korty <[EMAIL PROTECTED]> wrote:
> + seq_printf(p, "RES: ");
> + seq_printf(p, "CAL: ");
> + seq_printf(p, "TLB: ");
> + seq_printf(p, "TRM: ");
Documentation/filesystems/proc.txt presently describes NMI:, LOC:
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 31, 2007 12:11 AM
> To: Midhun A
> Cc: Sriram, Kannan; linux-kernel@vger.kernel.org; linux-arm-
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Testing of CPRM on SD Card
>
> On Mon, 30 Jul 2007 2
On 31.07.2007 00:17, Gabriel C wrote:
> Sasa Ostrouska wrote:
>
>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>> to check that, thx for the tip.
>
> Yes udev does this based on the MAC address but AFAIK forcedeth is 'special'
> for some reason
> ( which I can really r
From: Alexey Dobriyan <[EMAIL PROTECTED]>
> Apologies. I just finished adding m32r to my cross-build setup, so there
> shouldn't be any more such breakages.
Many thanks for your erabolation of cross-build check.
-- Takata
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
When using a kernel that has smp support enabled the computer will
randomly power down. It does not happen when using a non-smp kernel.
There is also no problem when using M$ with this chip set. There are no
error messages. It just shuts down. Because of this I'm unable to make
full use of my d
On Mon, 30 Jul 2007 13:49:14 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> The arm26 port has been in a state where it was far from even compiling
> for quite some time.
>
> Ian Molton agreed with the removal.
OK, thanks, I queued that up for a 2.6.23 merge.
-
To unsubscribe from this list: se
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
> > On my Turion64-based HPC nx6325 with the 2.6.23-rc1 x86_64 kernel doing
> >
> > # echo 0 > /sys/devices/system/cpu/cpu1/online
> >
> > causes the system to crash in a spectacular fashion (call traces g
>On 7/30/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 30 Jul 2007, Christoph Hellwig wrote:
>
> > On Mon, Jul 30, 2007 at 11:27:20AM -0700, Andrew Morton wrote:
> > > ho hum, crap. Yes, ioctl_by_bdev() doesn't have a file* and so it makes
> > > unlocked_ioctl() rather tricky. We cou
Martin Steigerwald wrote:
The current kernel development process tries to pretend that there is no
human involvement. Which is plain inaccurate: It is *all* human
involvement, without a human not a single bit of kernel code would
change.
IMHO, the above statements are all plain conjectures. H
Quoting Len Brown ([EMAIL PROTECTED]):
> Please attach the output from acpidump to
> http://bugzilla.kernel.org/show_bug.cgi?id=7880
done
also on : http://www.dth.net/kernel/acpidump_output_via_c3_5000
> We'll likely be able to tell from it if that patch
> has any real effect on your system, or
Whoops, forgot to CC lkml.
-- Forwarded message --
From: john stultz <[EMAIL PROTECTED]>
Date: Jul 30, 2007 11:13 AM
Subject: Re: [2.6.22] negative time jump
To: Vasily Averin <[EMAIL PROTECTED]>
On 7/29/07, Vasily Averin <[EMAIL PROTECTED]> wrote:
> I've investigated why my test
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 29 Jul 2007 16:58:52 +0200
> The following code can now become static:
> - struct unix_socket_table
> - unix_table_lock
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Also applied, thanks a lot.
-
To unsubscribe from this list: send the line "
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 29 Jul 2007 16:58:46 +0200
> nf_ct_ipv6_skip_exthdr() can now become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 29 Jul 2007 16:58:40 +0200
> Non-static inline code usually doesn't makes sense.
>
> In this case making is static and non-inline is the correct solution.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
-
To unsubscribe
> Well, I'm having a heck of a time getting this to fail. It looks
> possible, though. Joe, were you guys able to narrow it down to a
> reproducible test case? Do you have any oops output messages from
> the crashes?
Zach, it easy to reproduce through fio with following config file
# cat
Signed-off-by: Matthew Dharm <[EMAIL PROTECTED]>
On Tue, Jul 31, 2007 at 12:28:22AM +0200, Adrian Bunk wrote:
> The Coverity checker spotted that we have already oops'ed if "us"
> was NULL.
>
> Since "us" can't be NULL in the only caller this patch removes the
> NULL check.
>
> Signed-off-by: Ad
Joe Korty wrote:
> +#ifdef CONFIG_SMP
> + seq_printf(p, "RES: ");
> + for_each_online_cpu(j)
> + seq_printf(p, "%10u ",
> + per_cpu(irq_stat,j).irq_resched_counts);
> + seq_printf(p, " Rescheduling interrupts\n");
Remove unused config symbol CONFIG_DISKtel.
Pointed out by Robert P. J. Day <[EMAIL PROTECTED]>.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naur linux-2.6.22/include/asm-m68knommu/system.h
linux-2.6.22-uc1/include/asm-m68knommu/system.h
--- linux-2.6.22/include/asm-m68knommu/syst
Hi Denis,
On Mon, 30 Jul 2007, Denis Vlasenko wrote:
> Hi Satyam,
>
> On Monday 23 July 2007 17:05, Satyam Sharma wrote:
> > There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
> > that was unnecessary and not required for the correctness of those APIs.
> > All that superfl
On Mon, 30 Jul 2007 16:30:50 +0200
Zoltan Menyhart <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
>
> > Considerations:
> > - I can add CONFIG_MONTECITO if necessary. But it will be confusing, I
> > think.
>
> What about this trick below?
>
> identify_cpu() finds out the "c->family".
On Mon, 30 Jul 2007, Andrew Morton wrote:
> On Mon, 30 Jul 2007 08:19:10 +0530
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > +/*
> > + * Wrapper over simple_strtol (base 10) with sanity and range checking.
> > + * We return (signed) long only because we may want to return errors.
> > + * Do
Gabriel C <[EMAIL PROTECTED]> writes:
> Yes udev does this based on the MAC address but AFAIK forcedeth is
> 'special' for some reason
> ( which I can really remember now and gets on each boot a new MAC
> address or alike )
Must be a bug.
--
Krzysztof Halasa
-
To unsubscribe from this list: sen
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Thu, 26 Jul 2007 16:49:40 -0400
> Feel free to clean it up and submit both patches.
Ping? Somebody?
-
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:
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]>
Date: Thu, 26 Jul 2007 13:34:52 -0500 (CDT)
> In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 19:49:09 -0400), Dave
> Johnson <[EMAIL PROTECTED]> says:
>
> > ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast
> > Addresses' (RFC41
On Mon, 30 Jul 2007, Andrew Morton wrote:
> On Mon, 30 Jul 2007 08:17:41 +0530
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > [0/9] netconsole: Multiple targets and dynamic reconfigurability
> >
> > This is v3 of the patchset
>
> That all looks pretty reasonable, thanks.
>
> Are we all com
On 07/31, Oleg Nesterov wrote:
>
> > Manfred Spraul <[EMAIL PROTECTED]> wrote:
> >
> > > poll() returns -EINTR if a signal is pending.
> > > EINTR is a bad choice: it means that poll returns to user space if the
> > > task is stopped by SIGSTOP/SIGCONT or by the freezer.
> > > select() and ppoll()
Add missing IRQs and IRQ descriptions to /proc/interrupts.
/proc/interrupts is most useful when it displays every
IRQ vector in use by the system, not just those somebody
thought would be interesting.
This patch inserts the following vector displays to the
i386 and x86_64 platforms, as appropriat
On Mon, 2007-07-30 at 16:38 -0700, Zach Brown wrote:
> On Jul 30, 2007, at 2:58 PM, Badari Pulavarty wrote:
>
> > On Mon, 2007-07-30 at 14:45 -0700, Zach Brown wrote:
> >>> I am also taking a look at it right now.
> >>
> >> Are we having a race to write a little test app that reproduces the
> >> p
On Mon, 30 Jul 2007 08:19:10 +0530
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> +/*
> + * Wrapper over simple_strtol (base 10) with sanity and range checking.
> + * We return (signed) long only because we may want to return errors.
> + * Do not use this to convert numbers that are allowed to be nega
On Mon, 30 Jul 2007 08:17:41 +0530
Satyam Sharma <[EMAIL PROTECTED]> wrote:
> [0/9] netconsole: Multiple targets and dynamic reconfigurability
>
> This is v3 of the patchset
That all looks pretty reasonable, thanks.
Are we all comfortable with the attributions? As I have it now, everything
wil
On Mon, 2007-07-30 at 16:38 -0700, Zach Brown wrote:
> On Jul 30, 2007, at 2:58 PM, Badari Pulavarty wrote:
>
> > On Mon, 2007-07-30 at 14:45 -0700, Zach Brown wrote:
> >>> I am also taking a look at it right now.
> >>
> >> Are we having a race to write a little test app that reproduces the
> >> p
On 07/30, Andrew Morton wrote:
>
> On Sun, 29 Jul 2007 19:05:05 +0200
> Manfred Spraul <[EMAIL PROTECTED]> wrote:
>
> > Hi Andrew,
> >
> > poll() returns -EINTR if a signal is pending.
> > EINTR is a bad choice: it means that poll returns to user space if the
> > task is stopped by SIGSTOP/SIGCON
David Miller wrote:
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Mon, 30 Jul 2007 12:17:58 -0400
David, thoughts on merging? I'm not We could stick this into your tree
or mine. Whether yours or mine, I would like to keep the driver and
net-core patches together in the same git tree.
No obje
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Sun, 29 Jul 2007 19:05:05 +0200 Manfred Spraul <[EMAIL PROTECTED]> wrote:
> > poll() returns -EINTR if a signal is pending.
> > EINTR is a bad choice: it means that poll returns to user space if the
> > task is stopped by SIGSTOP/SIGCONT or by the fre
* Manfred Spraul ([EMAIL PROTECTED]) wrote:
> poll() returns -EINTR if a signal is pending.
> EINTR is a bad choice: it means that poll returns to user space if the
> task is stopped by SIGSTOP/SIGCONT or by the freezer.
> select() and ppoll() both use ERESTARTNOHAND, this avoids a return to
> user
On Sun, 29 Jul 2007 20:56:46 -0400
Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Is there a reason why the "online" file in the subdirectories for the CPUs
> in /sys/devices/system isn't world-readable?
No sane one which I can think of. It seems that it originally sprang forth
from Rusty's keyboar
On Tue, 2007-07-31 at 04:48 +0900, Paul Mundt wrote:
> On Sun, Jul 29, 2007 at 01:39:51AM +0100, Adrian McMenamin wrote:
> This looks fine to me in any event. I can either wrap this up in my tree
> or Tony can include it with his next set of updates if he has any other
> concerns. Thanks, Adrian.
On Wed, 4 Jul 2007 12:23:18 +0200, Lennert Buytenhek wrote:
>If you're also running into glibc's tst-robust1 test suite test
>locking up your ARM machine, you're probably running into the fact
>that asm-arm/futex.h includes asm-generic/futex.h, and
>asm-generic/futex.h defines futex_atomic_cmpxchg_
On Fri, 27 Jul 2007 16:43:13 MDT, Bjorn Helgaas said:
> I don't know why tpm_tis_init() is messing around trying different
> IRQs between 3 and 16. That looks suspiciously x86-dependent.
>
> Maybe if you don't have PNP (though I doubt TPMs exist on any
> pre-PNPBIOS machines) the "check-IRQ" loo
On Sun, 2007-07-29 at 19:06 +0200, Ingo Molnar wrote:
> * Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > Im still not so keen about this, Ingo never did get CFS to match SD in
> > smoothness for 3d applications, where my test subjects are quake(s),
> > world of warcraft via wine, unreal tourna
Michal Piotrowski wrote:
Hi Sid,
On 29/07/07, Sid Boyce <[EMAIL PROTECTED]> wrote:
> Boot failure on x86_64 (64X2), says it can't find init, specifically
> /init. 2.6.23-rc1-git1 boots and runs successfully. I haven't tried
> -git2. I shall reboot on 2.6.23-rc1-git3 tomorrow and record th
On Jul 30, 2007, at 2:58 PM, Badari Pulavarty wrote:
On Mon, 2007-07-30 at 14:45 -0700, Zach Brown wrote:
I am also taking a look at it right now.
Are we having a race to write a little test app that reproduces the
problem? :)
Nope. Feel free to write the test case.
Well, I'm having a he
On Sun, 29 Jul 2007 19:05:05 +0200
Manfred Spraul <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> poll() returns -EINTR if a signal is pending.
> EINTR is a bad choice: it means that poll returns to user space if the
> task is stopped by SIGSTOP/SIGCONT or by the freezer.
> select() and ppoll() both
On Tue, 2007-07-31 at 01:10 +0200, Sasa Ostrouska wrote:
> On 7/31/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> > > Kay Sievers wrote:
> > > > On 7/31/07, Sasa Ostrouska <[EMAIL PROTECTED]> wrote:
> > > >> On 7/31/07, Gabriel C <[EMAIL PRO
On Mon, 30 Jul 2007 18:09:23 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 30 Jul 2007, Gabriel C wrote:
>
> > A. Kalten wrote:
> > [ added usb peoples to CC ]
> > > Hello,
> > >
> > > To send a fax using an external usb modem, I do the following:
> > >
> > > modprobe uhci-hcd
> >
On 7/31/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-07-31 at 00:19 +0200, Gabriel C wrote:
> > Kay Sievers wrote:
> > > On 7/31/07, Sasa Ostrouska <[EMAIL PROTECTED]> wrote:
> > >> On 7/31/07, Gabriel C <[EMAIL PROTECTED]> wrote:
> > >>> Sasa Ostrouska wrote:
> > On 7/30/07, Av
On Monday 30 July 2007 23:51:42 Steven wrote:
> On Thu, 26 Jul 2007 16:29:55 +0200, Rafael J. Wysocki wrote:
> > OK, so here it goes again with a changelog:
> >
> > ---
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Generally, sysdev_shutdown() should be called after the ACPI preparation
>
101 - 200 of 584 matches
Mail list logo