inotify and /proc/

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

Re: [TULIP] Need new maintainer

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

[PATCH] Check patch reports multiple var with a function assignment

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

Re: [PATCH] Remove fs.h from mm.h

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

Re: bonnie++ benchmarks for ext2,ext3,ext4,jfs,reiserfs,xfs,zfs on software raid 5

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

[PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

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

[PATCH] flush icache before set_pte take6. [3/4] add montecito brand name

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 =

[PATCH] flush icache before set_pte take6. [2/4] sync icache dcache

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

[PATCH] flush icache before set_pte take6. [1/4] migration fix

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]> --

Re: [PATCH 2/2] Debug handling of early spurious interrupts

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

[PATCH] flush icache before set_pte take6. [0/4]

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

[PATCH 035 of 35] Simplify bio splitting in dm.

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

[PATCH 027 of 35] Remove bi_*_segments and related code.

__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

[PATCH] remove unneded lock_kernel in drivers/md/dm.c and use unlocked_ioctl.

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

[PATCH 033 of 35] Simplify stacking of IO restrictions

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 |

[PATCH 034 of 35] Simplify bio_add_page and raid1/raid10 resync which use it.

__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

[PATCH 030 of 35] Teach raid5 to split incoming bios.

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

[PATCH 031 of 35] Use bio_multi_split to fully split bios for pktcdvd.

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

[PATCH 032 of 35] Remove blk_queue_merge_bvec and bio_split and related code.

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.

[PATCH 026 of 35] Split any large bios that arrive at __make_request.

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

[PATCH 028 of 35] Split arbitrarily large requests to md/raid0 and md/linear

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

[PATCH 029 of 35] Teach md/raid10 to split arbitrarily large bios.

.. 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/

[PATCH 024 of 35] Allow request bio list not to end with NULL

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

[PATCH 025 of 35] Treat rq->hard_nr_sectors as setting an overriding limit in the size of the request

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

[PATCH 021 of 35] Teach umem.c about bi_offset and to limit to bi_size.

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

[PATCH 022 of 35] Teach dm-crypt to honour bi_offset and bi_size

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 +++ .

[PATCH 023 of 35] Teach pktcdvd.c to honour bi_offset and bi_size

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

[PATCH 020 of 35] Add bi_offset and allow a bio to reference only part of a bi_io_vec

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

[PATCH 019 of 35] Convert bio_for_each_segment to fill in a fresh bio_vec

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

[PATCH 018 of 35] Remove bi_idx

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

[PATCH 015 of 35] Move hw_front_size and hw_back_size from bio to request.

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

[PATCH 016 of 35] Centralise setting for REQ_NOMERGE.

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 +++

[PATCH 017 of 35] Fix various abuse of bio fields in umem.c

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

[PATCH 013 of 35] Don't update bi_hw_*_size if we aren't going to merge.

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

[PATCH 014 of 35] Change blk_phys/hw_contig_segment to take requests, not bios.

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.

[PATCH 011 of 35] Stop exporting blk_rq_bio_prep

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-

[PATCH 012 of 35] Share code between init_request_from_bio and blk_rq_bio_prep

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_

[PATCH 009 of 35] Remove overloading of bi_hw_segments in raid5.

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

[PATCH 010 of 35] New function blk_req_append_bio

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

Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)

* 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

[PATCH 008 of 35] Introduce bi_iocnt to count requests sharing the one bio.

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

[PATCH 007 of 35] Drop 'size' argument from bio_endio and bi_end_io.

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

[PATCH 005 of 35] Stop updating bi_idx, bv_len, bv_offset when a request completes

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

[PATCH 006 of 35] Only call bi_end_io once for any bio.

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

[PATCH 003 of 35] Introduce rq_for_each_segment replacing rq_for_each_bio

(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

[PATCH 004 of 35] Merge blk_recount_segments into blk_recalc_rq_segments

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

[PATCH 002 of 35] Replace bio_cur_sectors with blk_rq_cur_sectors.

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

[PATCH 000 of 35] Refactor block layer to improve support for stacked devices.

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

[PATCH 001 of 35] Replace bio_data with blk_rq_data

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

Re: [TULIP] Need new maintainer

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

Re: Repeated XFS corruption -Corruption of in-memory data detected

[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

Re: forcedeth ?

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

Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)

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

Re: [PATCH] expand /proc/interrupts to include missing vectors, v2

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:

RE: Testing of CPRM on SD Card

> -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

Re: forcedeth ?

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

Re: [PATCH] Remove fs.h from mm.h

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

smp incompatible Nvidia mcp61s mainboard chip set

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

Re: [2.6 patch] Remove the arm26 port

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

Re: [2.6.23-rc1 REGRESSION] CPU hotplug totally broken on HPC nx6325 (x86_64)

* 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

Re: 2.6.23-rc1-mm1

>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

Re: [ck] Re: Linus 2.6.23-rc1

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

Re: Update: ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not:

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

Re: [2.6.22] negative time jump

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

Re: [2.6 patch] net/unix/af_unix.c: make code static

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 "

Re: [2.6 patch] make nf_ct_ipv6_skip_exthdr() static

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

Re: [2.6 patch] make pktgen.c:get_ipsec_sa() static and non-inline

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

Re: [PATCH] add check do_direct_IO() return val

> 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

Re: [2.6 patch] usbat_check_status(): fix check-after-use

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

Re: [PATCH] expand /proc/interrupts to include missing vectors, v2

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");

[M68KNOMMU] remove unused config symbol CONFIG_DISKtel

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

Re: [PATCH 0/8] i386: bitops: Cleanup, sanitize, optimize

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

Re: [PATCH] flush icache before set_pte() take 5.

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".

Re: [PATCH v3 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs

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

Re: forcedeth ?

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

Re: [PATCH] SCTP: IPv4 mapped addr not returned in SCTPv6 accept()

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:

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

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

Re: [PATCH v3 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability

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

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

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()

[PATCH] expand /proc/interrupts to include missing vectors, v2

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

Re: [PATCH] add check do_direct_IO() return val

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

Re: [PATCH v3 -mm 9/9] netconsole: Support dynamic reconfiguration using configfs

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

Re: [PATCH v3 -mm 0/9] netconsole: Multiple targets and dynamic reconfigurability

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

Re: [PATCH] add check do_direct_IO() return val

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

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

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

Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic

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

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

* 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

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

* 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

Re: [PATCH] CPU online file permission

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

Re: [PATCH] Framebuffer: Consolidated cleanup of pvr2fb.c for Sega Dreamcast

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.

Re: handle_futex_death() infinite loop on ARM (fwd)

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_

Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm_tis

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

Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)

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

Re: 2.6.23-rc1-git3 init failure

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

Re: [PATCH] add check do_direct_IO() return val

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

Re: [PATCH] Use ERESTARTNOHAND if poll() is interrupted by a signal

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

Re: forcedeth ?

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

Re: Can't unload uhci_hcd module with 2.6.22 -- also oops

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 > >

Re: forcedeth ?

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

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"

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 >

<    1   2   3   4   5   6   >