Re: blink driver power saving
On Wednesday 04 July 2007 18:11, Pavel Machek wrote: > Hi! > > > > > > > Perhaps one of you geniuses who all hate it can find a better way to > > > > > > solve the "video output dead after kexec; but need visual feedback > > > > > > to the user > > > > > > while crash dumping" problem. I'm waiting for your patches. > > > > > > > > > > > > > > > > I don't don't like it ;) Unfortunately too many people end up enabling > > > > > > > > Yes that's pretty weird. I admit I hadn't expected > > > > that problem. blink is equivalent to "annoy me" and it > > > > is a mystery why so many people should willingly ask their computer to > > > > annoy them. > > > > > > tristate "Keyboard blink driver" > > > > > > ...drivers are not expected to act on their own. I was expecting to > > > get nice /sys/class/led* interface to my keyboard leds. > > > > > > BTW ... I still believe we should have /sys/class/led* interface to > > > those leds. I'd like to make them blink with hdd activity on some > > > machines... of course, that needs non-buggy KBC. > > > > I'll take patches. Ofcourse we'll have to keep the current EV_LED interface > > for compatibility. > > Here's a working version. For some reason, it only works with capslock > led. (But so does your code, is that thinkpad problem?) > My code does blink NumLock on my box (Dell) so I wonder why it does not on your box... Anyway, as far as the patch goes - I don't think we want to do it this way for a couple of reasons: 1. It does not reflect the true device hierarchy - LEDs are not children of input devices, they are children of whatever device that owns input device. So in case of AT keyboard LEDs should grow from corresponding serio port, not input device and so atkbd should register all of its leds. 2. LEDs will stop working if input device is grabbed via EVIOCSGRAB. I think that grab should not cross subsystem boundaries. -- Dmitry - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
On Wednesday 04 July 2007 17:47, Pavel Machek wrote: > Hi! > > > >I was thinking about something like the atached (untested and sorry > > >for using attachment). It shoudl blink just one led (numLock) on any > > >keyboard that has such LED (and allows to control it). > > > > > > > Argh, bad one. This one shoudl be better. > > Does it blink for you? It does not seem to do anything here :-(. Yes it does. Just tested it and it blinks NumLock led just fine. -- Dmitry - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull][resend] Input updates for 2.6.22-rc7
[Resending with proper kernel version in subject... I guess original claiming to be for 2.6.22-rc4 might have something to do with it being dropped...] Hi Linus, Please consider pulling from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for input subsystem. You will get update to AT keyboard driver that throttles LED switching so that 'setleds' does not lock up keyboards. Also fix for an oops happening if user presses Ctrl-Alt-Del in the middle of keyboard being probed (serio_cleanup should take mutex). Note that the bulk of changes to input.h are just comments for various KEY_XXX input codes and not functional changes. Changelog: -- Dmitry Torokhov (4): Input: i8042 - add HP Pavilion ZT1000 to the MUX blacklist Input: atkbd - throttle LED switching Input: serio - take drv_mutex in serio_cleanup() Input: document some of keycodes Henrique de Moraes Holschuh (1): Input: add a new EV_SW SW_RADIO event, for radio switches on laptops Qi Yong (1): Input: atkbd - use printk_ratelimit for spurious ACK messages Diffstat: - drivers/input/keyboard/atkbd.c | 47 +++ drivers/input/serio/i8042-x86ia64io.h | 11 +++ drivers/input/serio/serio.c | 2 + include/linux/input.h | 143 +--- 4 files changed, 119 insertions(+), 84 deletions(-) -- Dmitry - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CRAMFS support for 4KB page NAND FLASH
Trying to boot off CRAMFS on a 4KB page NAND FLASH (new device), I ran into the "wrong magic" issue. MTD's nand_read (drivers/mtd/nand/nand_base.c) is returning the right data. cramfs_fill_supper calls cramfs_read (fs/cramfs/inode.c) which reads 4 pages and the 1st page of data gets corrupted. If I set BLKS_PER_BUF_SHIFT in this file to 0 instead of 2, so that only 1 page is read, the data is uncorrupted and the magic value matches but it crashes later (comments say that this values should be 2 or higher, so this is not surprising). So are 4KB-page devices supported by CRAMFS? I'm using linux 2.6.20.1 for ARM. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
KAMEZAWA Hiroyuki wrote: On Thu, 05 Jul 2007 13:19:41 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: From what I can work out, it is something like "at this point the page should be uptodate, so at least the icache won't contain *inconsistent* data, just old data which userspace should take care of flushing if it modifies". Is that always true? I think it's true. But, in this case, i-cache doesn't contain *incositent* data. There are inconsistency between L2-Dcache and L3-mixed-cache. At L2-icache-miss, a cpu fetches data from L3 cache. This case seems defficult to be generalized... If there is something in the icache line that isn't the last data to be stored at that address, isn't that inconsistent? Hmm..do we have a chance to add do_flush_cache_if_not_filled_by_dma(page) before SetPageUptodate(page) ? Well you shouldn't strictly need to, because only uptodate pages should ever be mapped with set_pte, and if you do the flush_icache before the set_pte, then you effectively get the same result. And if that's the result you want, then I don't think the flush_icache before set_pte is a *terrible* way to get it. -- SUSE Labs, Novell Inc. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
x86_64 memory hotplug simulation support?
Hi all. I'm wondering whether anyone has patches lying around that might be useful for simulating memory hotplug on x86_64. Goggling has revealed some old x86 patches, but that's all. Regards, Nigel pgpm5Nsks2740.pgp Description: PGP signature
Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
On Thu, 05 Jul 2007 13:19:41 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > >> From what I can work out, it is something like "at this point the page > >>should be uptodate, so at least the icache won't contain *inconsistent* > >>data, just old data which userspace should take care of flushing if it > >>modifies". Is that always true? > > > > > > I think it's true. But, in this case, i-cache doesn't contain *incositent* > > data. > > There are inconsistency between L2-Dcache and L3-mixed-cache. At > > L2-icache-miss, > > a cpu fetches data from L3 cache. > > This case seems defficult to be generalized... > > If there is something in the icache line that isn't the last data to > be stored at that address, isn't that inconsistent? > Hmm..do we have a chance to add do_flush_cache_if_not_filled_by_dma(page) before SetPageUptodate(page) ? -Kame - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dio: remove bogus refcounting BUG_ON
On Wed, Jul 04, 2007 at 07:25:10PM -0700, Badari Pulavarty wrote:
> On Tue, 2007-07-03 at 15:28 -0700, Zach Brown wrote:
> > Linus, Andrew, please apply the bug fix patch at the end of this reply
> > for .22.
> >
> > > >>One of our perf. team ran into this while doing some runs.
> > > >>I didn't see anything obvious - it looks like we converted
> > > >>async IO to synchronous one. I didn't spend much time digging
> > > >>around.
> >
> > OK, I think this BUG_ON() is just broken. I wasn't able to find any
> > obvious bugs from reading the code which would cause the BUG_ON() to
> > fire. If it's reproducible I'd love to hear what the recipe is.
> >
> > I did notice that this BUG_ON() is evaluating dio after having dropped
> > it's ref :/. So it's not completely absurd to fear that it's a race
> > with the dio's memory being reused, but that'd be a pretty tight race.
> >
> > Let's remove this stupid BUG_ON and see if that test box still has
> > trouble. It might just hit the valid BUG_ON a few lines down, but this
> > unsafe BUG_ON needs to go.
>
> I went through the code multiple times, I can't find how we can trigger
> the BUG_ON(). But unfortunately, our perf. team is able reproduce the
> problem. Debug indicated that, the ret2 == 1 :(
>
> Not sure how that can happen. Ideas ?
Does it trigger even if you avoid referencing dio in the BUG_ON(), i.e.
with something like ...
--- direct-io.c 2007-07-02 01:24:24.0 +0530
+++ direct-io-debug.c 2007-07-05 09:18:56.0 +0530
@@ -1104,9 +1104,10 @@ direct_io_worker(int rw, struct kiocb *i
* decide to wake the submission path atomically.
*/
spin_lock_irqsave(>bio_lock, flags);
+ is_async = dio->is_async;
ret2 = --dio->refcount;
spin_unlock_irqrestore(>bio_lock, flags);
- BUG_ON(!dio->is_async && ret2 != 0);
+ BUG_ON(!is_async && ret2 != 0);
if (ret2 == 0) {
ret = dio_complete(dio, offset, ret);
kfree(dio);
>
> Thanks,
> Badari
>
> >
> > ---
> >
> > dio: remove bogus refcounting BUG_ON
> >
> > Badari Pulavarty reported a case of this BUG_ON is triggering during
> > testing. It's completely bogus and should be removed.
> >
> > It's trying to notice if we left references to the dio hanging around in
> > the sync case. They should have been dropped as IO completed while this
> > path was in dio_await_completion(). This condition will also be
> > checked, via some twisty logic, by the BUG_ON(ret != -EIOCBQUEUED) a few
> > lines lower. So to start this BUG_ON() is redundant.
> >
> > More fatally, it's dereferencing dio-> after having dropped its
> > reference. It's only safe to dereference the dio after releasing the
> > lock if the final reference was just dropped. Another CPU might free
> > the dio in bio completion and reuse the memory after this path drops the
> > dio lock but before the BUG_ON() is evaluated.
> >
> > This patch passed aio+dio regression unit tests and aio-stress on ext3.
> >
> > Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
> > Cc: Badari Pulavarty <[EMAIL PROTECTED]>
> >
> > diff -r 509ce354ae1b fs/direct-io.c
> > --- a/fs/direct-io.cSun Jul 01 22:00:49 2007 +
> > +++ b/fs/direct-io.cTue Jul 03 14:56:41 2007 -0700
> > @@ -1106,7 +1106,7 @@ direct_io_worker(int rw, struct kiocb *i
> > spin_lock_irqsave(>bio_lock, flags);
> > ret2 = --dio->refcount;
> > spin_unlock_irqrestore(>bio_lock, flags);
> > - BUG_ON(!dio->is_async && ret2 != 0);
> > +
> > if (ret2 == 0) {
> > ret = dio_complete(dio, offset, ret);
> > kfree(dio);
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
KAMEZAWA Hiroyuki wrote: On Thu, 05 Jul 2007 12:04:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: In my understanding : PG_arch_1 is used for showing "there is no inconsistent data on any level of cache". PG_uptodate is used for showing "this page includes the newest data and contents are valid." ...maybe not used for the same purpose. I think that's right, but why is set_pte-time the critical point for the flush? It is actually possible to write into an executable page via the dcache *after* it has ptes pointing to it. yes. I think there are 2 cases. - copy-on-write case. OS handles this. - page is writable and app just rewrites it .. the app should handle this. Well it may not be "the" app, but any app on the system might write to a page shared by any other app. OK we could just add the vague qualifier about "don't do stupid stuff", but that should be only AFTER it is determined that handling the corner cases is too hard. From what I can work out, it is something like "at this point the page should be uptodate, so at least the icache won't contain *inconsistent* data, just old data which userspace should take care of flushing if it modifies". Is that always true? I think it's true. But, in this case, i-cache doesn't contain *incositent* data. There are inconsistency between L2-Dcache and L3-mixed-cache. At L2-icache-miss, a cpu fetches data from L3 cache. This case seems defficult to be generalized... If there is something in the icache line that isn't the last data to be stored at that address, isn't that inconsistent? Could the page get modified by means other than a direct write(2)? And even in the case of a write(2) writer, how do they know if another process is mapping that particular page for exec at that time? Should they always flush? Flushing would require they have a virtual address on the page to begin with anyway, doesn't it? So they'd have to mmap it... phew. I guess it is mostly safe because it is probably very uncommon to do such a thing, and chances are no non-write(2) write activity happens to a page after it is brought uptodate. But I don't know if that has been audited. I would really like to see the kernel always manage all aspects of its pagecache though. I realise performance considerations may make this not always possible... but it might be possible to do efficiently using mapcount these days? generic_file_write() does flush_dcahe_page() but no flush_icache_page()... Then..maybe this will be necessary... == flush_dcache_page(page); if (page_mapcount(page) > 0 && page_is_mapped_as_text(page)) flush_icache_page(page); == But I don't know whether write(2) to mapped text file is expected to work well. The point of the flush_dcache is that you have just written to dcache via the kernel virtual address and need to handle any aliases. So if you did want to handle this with ia64, you would do it all in flush_dcache_page. flush_icache_page AFAIKS allows you to attempt some funny tricks to avoid flushing @ flush_dcache_page-time. It is better than the lazy_mmu_update thingy (because it is actually done in the right place -- ie. *before* the set_pte), however it is still pretty tricky. -- SUSE Labs, Novell Inc. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ov511 module does not build
On Wed, Jul 04, 2007 at 12:23:57AM +0100, Sid Boyce wrote: > With the same setup in .config for linux-2.6.22-rc2-git7, it builds, after > that and right up to linux-2.6.22-rc7-git1 it doesn't. > /usr/src/linux-2.6.22-rc2-git7/drivers/media/video/ov511.ko > # CONFIG_VIDEO_V4L1 is not set That's the problem. > CONFIG_VIDEO_V4L1_COMPAT=y > In any of the 2.6.22-rc kernels, there is no option to select OV511. > tindog:/usr/src/linux-2.6.22-rc2-git7 # grep -i ov511 .config > tindog:/usr/src/linux-2.6.22-rc2-git7 # > > tindog:/usr/src/linux-2.6.22-rc7-git1 # diff > ../linux-2.6.22-rc2-git7/drivers/media/video/Kconfig > drivers/media/video/Kconfig > 14c14 > < if VIDEO_CAPTURE_DRIVERS > --- > > if VIDEO_CAPTURE_DRIVERS && VIDEO_DEV > 694c694 > < if V4L_USB_DRIVERS > --- > > if V4L_USB_DRIVERS && USB > tindog:/usr/src/linux-2.6.22-rc7-git1 # grep V4L .config > # CONFIG_VIDEO_V4L1 is not set > CONFIG_VIDEO_V4L1_COMPAT=y > CONFIG_VIDEO_V4L2=y > CONFIG_V4L_USB_DRIVERS=y > > tindog:/usr/src/linux-2.6.22-rc2-git7 # grep V4L .config > # CONFIG_VIDEO_V4L1 is not set If it built with this version and this .config, something went wrong. Are you sure this is the correct .config that built the ov511 module? > CONFIG_VIDEO_V4L1_COMPAT=y > CONFIG_VIDEO_V4L2=y > # CONFIG_V4L_USB_DRIVERS is not set > > Still does not build for 2.6.22-rc7-git2 with .config set with > > # CONFIG_V4L_USB_DRIVERS is not set > > Regards > Sid. > -- > Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot > Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support > Specialist, Cricket Coach > Microsoft Windows Free Zone - Linux used for all Computing Tasks > > > - > 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://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
On Thu, 05 Jul 2007 12:04:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > > In my understanding : > > PG_arch_1 is used for showing "there is no inconsistent data on any level of > > cache". PG_uptodate is used for showing "this page includes the newest data > > and contents are valid." > > ...maybe not used for the same purpose. > > I think that's right, but why is set_pte-time the critical point for the > flush? It is actually possible to write into an executable page via the > dcache *after* it has ptes pointing to it. yes. I think there are 2 cases. - copy-on-write case. OS handles this. - page is writable and app just rewrites it .. the app should handle this. > > From what I can work out, it is something like "at this point the page > should be uptodate, so at least the icache won't contain *inconsistent* > data, just old data which userspace should take care of flushing if it > modifies". Is that always true? I think it's true. But, in this case, i-cache doesn't contain *incositent* data. There are inconsistency between L2-Dcache and L3-mixed-cache. At L2-icache-miss, a cpu fetches data from L3 cache. This case seems defficult to be generalized... > Could the page get modified by means > other than a direct write(2)? And even in the case of a write(2) writer, > how do they know if another process is mapping that particular page for > exec at that time? Should they always flush? Flushing would require they > have a virtual address on the page to begin with anyway, doesn't it? So > they'd have to mmap it... phew. > > I guess it is mostly safe because it is probably very uncommon to do > such a thing, and chances are no non-write(2) write activity happens to > a page after it is brought uptodate. But I don't know if that has been > audited. I would really like to see the kernel always manage all aspects > of its pagecache though. I realise performance considerations may make > this not always possible... but it might be possible to do efficiently > using mapcount these days? generic_file_write() does flush_dcahe_page() but no flush_icache_page()... Then..maybe this will be necessary... == flush_dcache_page(page); if (page_mapcount(page) > 0 && page_is_mapped_as_text(page)) flush_icache_page(page); == But I don't know whether write(2) to mapped text file is expected to work well. > > BTW, a page filled by DMA should have PG_arch_1 :( > > The consequences of not are superfluous flushes? > Yes, DMA flushes all levels of cache. 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 at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dio: remove bogus refcounting BUG_ON
On Tue, 2007-07-03 at 15:28 -0700, Zach Brown wrote:
> Linus, Andrew, please apply the bug fix patch at the end of this reply
> for .22.
>
> > >>One of our perf. team ran into this while doing some runs.
> > >>I didn't see anything obvious - it looks like we converted
> > >>async IO to synchronous one. I didn't spend much time digging
> > >>around.
>
> OK, I think this BUG_ON() is just broken. I wasn't able to find any
> obvious bugs from reading the code which would cause the BUG_ON() to
> fire. If it's reproducible I'd love to hear what the recipe is.
>
> I did notice that this BUG_ON() is evaluating dio after having dropped
> it's ref :/. So it's not completely absurd to fear that it's a race
> with the dio's memory being reused, but that'd be a pretty tight race.
>
> Let's remove this stupid BUG_ON and see if that test box still has
> trouble. It might just hit the valid BUG_ON a few lines down, but this
> unsafe BUG_ON needs to go.
I went through the code multiple times, I can't find how we can trigger
the BUG_ON(). But unfortunately, our perf. team is able reproduce the
problem. Debug indicated that, the ret2 == 1 :(
Not sure how that can happen. Ideas ?
Thanks,
Badari
>
> ---
>
> dio: remove bogus refcounting BUG_ON
>
> Badari Pulavarty reported a case of this BUG_ON is triggering during
> testing. It's completely bogus and should be removed.
>
> It's trying to notice if we left references to the dio hanging around in
> the sync case. They should have been dropped as IO completed while this
> path was in dio_await_completion(). This condition will also be
> checked, via some twisty logic, by the BUG_ON(ret != -EIOCBQUEUED) a few
> lines lower. So to start this BUG_ON() is redundant.
>
> More fatally, it's dereferencing dio-> after having dropped its
> reference. It's only safe to dereference the dio after releasing the
> lock if the final reference was just dropped. Another CPU might free
> the dio in bio completion and reuse the memory after this path drops the
> dio lock but before the BUG_ON() is evaluated.
>
> This patch passed aio+dio regression unit tests and aio-stress on ext3.
>
> Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
> Cc: Badari Pulavarty <[EMAIL PROTECTED]>
>
> diff -r 509ce354ae1b fs/direct-io.c
> --- a/fs/direct-io.c Sun Jul 01 22:00:49 2007 +
> +++ b/fs/direct-io.c Tue Jul 03 14:56:41 2007 -0700
> @@ -1106,7 +1106,7 @@ direct_io_worker(int rw, struct kiocb *i
> spin_lock_irqsave(>bio_lock, flags);
> ret2 = --dio->refcount;
> spin_unlock_irqrestore(>bio_lock, flags);
> - BUG_ON(!dio->is_async && ret2 != 0);
> +
> if (ret2 == 0) {
> ret = dio_complete(dio, offset, ret);
> kfree(dio);
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ata1: soft resetting port
Soeren Sonnenburg wrote: >>> pci_express :00:1c.2:pcie03: resuming >>> sr 0:0:0:0: resuming >>> sd 2:0:1:0: resuming >>> sd 2:0:1:0: [sda] Starting disk >>> ata1.00: configured for UDMA/33 >>> ata3.01: revalidation failed (errno=-2) >>> ata3: failed to recover some devices, retrying in 5 secs >>> ata3.01: configured for UDMA/133 >> Hmmm... That's NODEV_HINT being triggered after resume. Probably the >> device isn't ready to respond yet at that point. How reproducible is >> the problem? > > quite reproducible: > > $ dmesg | grep 'revalidation failed' | wc -l > 4 Hmmm... Thanks. I think the best we can do is 1. don't wait for disk revalidation during resume 2. retry faster. Just in case, please post the result of "hdparm -I /dev/sdX" where sdX is the device at ata3.01. -- tejun - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUGFIX][PATCH] DO flush icache before set_pte() on ia64.
KAMEZAWA Hiroyuki wrote: On Wed, 04 Jul 2007 16:31:06 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: The only thing I noticed when I looked at the code is that some places may not have flushed icache when they should have? Did you get them all? I think that I added flush_icache_page() to the place where any flush_(i)cache_xxx is not called and lazy_mmu_prot_update was used instead of them. But I want good review, of course. Minor nitpick: you have one place where you test VM_EXEC before flushing, but the flush routine itself contains the same test I think? Ah, yes...in do_anonymous_page(). my mistake. Regarding the ia64 code -- I'm not an expert so I can't say whether it is the right thing to do or not. However I still can't work out what it's rationale for the PG_arch_1 bit is, exactly. Does it assume that flush_dcache_page sites would only ever be encountered by pages that are not faulted in? A faulted in page kind of is "special" because it is guaranteed uptodate, but is the ia64 arch code relying on that? Should it? (I'm sorry if I misses point.) ia64's D-cache is coherent but I-cache and D-cache is not coherent and any invalidation against d-cache will invalidate I-cache. In my understanding : PG_arch_1 is used for showing "there is no inconsistent data on any level of cache". PG_uptodate is used for showing "this page includes the newest data and contents are valid." ...maybe not used for the same purpose. I think that's right, but why is set_pte-time the critical point for the flush? It is actually possible to write into an executable page via the dcache *after* it has ptes pointing to it. From what I can work out, it is something like "at this point the page should be uptodate, so at least the icache won't contain *inconsistent* data, just old data which userspace should take care of flushing if it modifies". Is that always true? Could the page get modified by means other than a direct write(2)? And even in the case of a write(2) writer, how do they know if another process is mapping that particular page for exec at that time? Should they always flush? Flushing would require they have a virtual address on the page to begin with anyway, doesn't it? So they'd have to mmap it... phew. I guess it is mostly safe because it is probably very uncommon to do such a thing, and chances are no non-write(2) write activity happens to a page after it is brought uptodate. But I don't know if that has been audited. I would really like to see the kernel always manage all aspects of its pagecache though. I realise performance considerations may make this not always possible... but it might be possible to do efficiently using mapcount these days? Anyway, ignore my tangent if you like :) Your patch doesn't make any of this worse, so I'm getting off topic. So I think your patch is nice, but would need ia64 people to actually ack it. BTW, a page filled by DMA should have PG_arch_1 :( The consequences of not are superfluous flushes? -- SUSE Labs, Novell Inc. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > This updated version of the Linux Kernel Markers mostly adds a unique 16 bits > per marker ID and a per-probe marker group. [...] Could you motivate this part better? It is not covered in the documentation patch. It seems to be a way of having a marker handling (callback) module give alternate names/ids to markers. If so, why, considering that there is already a private void* callback parameter available to pass data back to itself through? Also, what if different marker handling modules want to set different id/group numbers on the same set of markers? - FChE - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.22-rc7: known regressions
On Tue, 2007-07-03 at 18:45 +0200, Michal Piotrowski wrote: > Hi all, > > Here is a list of some known regressions in 2.6.22-rc7. Oh, and here's another one for you. My Bluetooth mouse just stopped working and hidd is deadlocked... hidd D 1FE27798 5940 1695 1 (NOTLB) Call Trace: [ef3ddb70] [0004] 0x4 (unreliable) [ef3ddc30] [c0008e7c] __switch_to+0x50/0x68 [ef3ddc50] [c02d5998] schedule+0x3cc/0x480 [ef3ddc80] [c0137a20] rwsem_down_failed_common+0x1c4/0x1f4 [ef3ddcb0] [c02d7454] rwsem_down_write_failed+0x28/0x40 [ef3ddce0] [c004ff60] down_write+0x50/0x64 [ef3ddd00] [f27f2068] hidp_add_connection+0x168/0x75c [hidp] [ef3ddd40] [f27f2e44] hidp_sock_ioctl+0x140/0x414 [hidp] [ef3ddeb0] [c024da6c] sock_ioctl+0x248/0x284 [ef3dded0] [c00ab02c] do_ioctl+0x38/0x84 [ef3ddee0] [c00ab448] vfs_ioctl+0x3d0/0x404 [ef3ddf10] [c00ab4e4] sys_ioctl+0x68/0x98 -- dwmw2 - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fujtisu application panel driver
On Mon, Jul 02, 2007 at 11:17:24 -0700, Stephen Hemminger wrote:
> +static int __init apanel_init(void)
> +{
> + void __iomem *bios;
> + u8 devno;
> + int found = 0;
> +
> + if (!dmi_check_system(apanel_dmi_table)) {
> + printk(KERN_WARNING "apanel: DMI information does not match\n");
> + if (!force)
> + return -ENODEV;
> + }
> + BUG_ON(!keymap);
If force=1 and there's no DMI match, we're guaranteed to pop this BUG_ON.
> +
> + device_chip[devno] = (enum apanel_chip) chip;
> + ++found;
> + }
> + }
> + iounmap(bios);
This isn't the address we got from ioremap (although it happens to
work, since iounmap internally masks it against PAGE_MASK).
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.22 REGRESSION] Fix slab redzone alignment
Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 fixed a couple of bugs
by switching the redzone to 64 bits. Unfortunately, it neglected to
ensure that the _second_ redzone, after the slab object, is aligned
correctly. This caused illegal instruction faults on sparc32, which for
some reason not entirely clear to me are not trapped and fixed up.
Two things need to be done to fix this:
- increase the object size, rounding up to alignof(long long) so
that the second redzone can be aligned correctly.
- If SLAB_STORE_USER is set but alignof(long long)==8, allow a
full 64 bits of space for the user word at the end of the buffer,
even though we may not _use_ the whole 64 bits.
This patch should be a no-op on any 64-bit architecture or any 32-bit
architecture where alignof(long long) == 4. Of the others, it's tested
on ppc32 by myself and a very similar patch was tested on sparc32 by
Mark Fortescue, who reported the new problem.
Also, fix the conditions for FORCED_DEBUG, which hadn't been adjusted to
the new sizes. Again noticed by Mark.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/mm/slab.c b/mm/slab.c
index a9c4472..b344e67 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#defineREDZONE_ALIGN max(BYTES_PER_WORD,
__alignof__(unsigned long long))
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ REDZONE_ALIGN);
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
+ 2 * sizeof(unsigned long long)))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2219,12 +2221,20 @@ kmem_cache_create (const char *name, size_t size,
size_t align,
}
/*
-* Redzoning and user store require word alignment. Note this will be
-* overridden by architecture or caller mandated alignment if either
-* is greater than BYTES_PER_WORD.
+* Redzoning and user store require word alignment or possibly larger.
+* Note this will be overridden by architecture or caller mandated
+* alignment if either is greater than BYTES_PER_WORD.
*/
- if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER)
- ralign = __alignof__(unsigned long long);
+ if (flags & SLAB_STORE_USER)
+ ralign = BYTES_PER_WORD;
+
+ if (flags & SLAB_RED_ZONE) {
+ ralign = REDZONE_ALIGN;
+ /* If redzoning, ensure that the second redzone is suitably
+* aligned, by adjusting the object size accordingly. */
+ size += REDZONE_ALIGN - 1;
+ size &= ~(REDZONE_ALIGN - 1);
+ }
/* 2) arch mandated alignment */
if (ralign < ARCH_SLAB_MINALIGN) {
@@ -2261,9 +2271,13 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone needs to be
+* aligned to 64 bits, we must allow that much space.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE)
+ size += REDZONE_ALIGN;
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The big suspend mess
On Thu, Jul 05, 2007 at 02:27:47AM +0200, Pavel Machek wrote: > > > IMHO the suspend code is currently way too much of a moving target which > > results in this mess. > > > > The correct order seems to be: > > 0. Get someone to sign up as a maintainer for suspend, so we have > someone to blame for the mess? :-) The "SOFTWARE SUSPEND" entry in MAINTAINERS already contains a victim... ;-) My impression is that suspend is an area of the kernel that does not lack maintainers - you and Rafael are doing a good job, and there's e.g. also the maintained code formerly known as suspend2. But some basic questions like e.g. - What should be done in the kernel and what in userspace? - How should this be implemented? - What must subsystems and drivers do? - What must subsystems and drivers not do? seem to be in a constant flux because the big picture everyone agrees upon seems to be missing. > > 1. agree on what the suspend code as a whole should look like > > 2. implement this > > 3. fix ALL drivers to work at least as good as they do today > > 4. get it tested in -mm > > 5. fix all bugs people run into > > 6. submit it for inclusion in Linus' tree > > 7. quickly work on the most likely big amount of bug reports > > > > Step 1 is the most important one - evolving code is often something > > good, but in this case with different people trying to evolve the > > suspend code in different directions it simply results in a big mess. > > Pavel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ov511 module does not build
With the same setup in .config for linux-2.6.22-rc2-git7, it builds, after that and right up to linux-2.6.22-rc7-git1 it doesn't. /usr/src/linux-2.6.22-rc2-git7/drivers/media/video/ov511.ko # CONFIG_VIDEO_V4L1 is not set CONFIG_VIDEO_V4L1_COMPAT=y In any of the 2.6.22-rc kernels, there is no option to select OV511. tindog:/usr/src/linux-2.6.22-rc2-git7 # grep -i ov511 .config tindog:/usr/src/linux-2.6.22-rc2-git7 # tindog:/usr/src/linux-2.6.22-rc7-git1 # diff ../linux-2.6.22-rc2-git7/drivers/media/video/Kconfig drivers/media/video/Kconfig 14c14 < if VIDEO_CAPTURE_DRIVERS --- > if VIDEO_CAPTURE_DRIVERS && VIDEO_DEV 694c694 < if V4L_USB_DRIVERS --- > if V4L_USB_DRIVERS && USB tindog:/usr/src/linux-2.6.22-rc7-git1 # grep V4L .config # CONFIG_VIDEO_V4L1 is not set CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_VIDEO_V4L2=y CONFIG_V4L_USB_DRIVERS=y tindog:/usr/src/linux-2.6.22-rc2-git7 # grep V4L .config # CONFIG_VIDEO_V4L1 is not set CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_VIDEO_V4L2=y # CONFIG_V4L_USB_DRIVERS is not set Still does not build for 2.6.22-rc7-git2 with .config set with # CONFIG_V4L_USB_DRIVERS is not set Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The big suspend mess
Pavel Machek writes: > 0. Get someone to sign up as a maintainer for suspend, so we have > someone to blame for the mess? :-) I thought that was Rafael? Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Pavel Machek writes: > How well does it work on SMP PPC? Just fine, on those machines where we know how to reinitialize the video card. We currently require userspace to offline all except the boot cpu before suspending, but that could be moved into the kernel. I have no particular attachment to that way of doing it; it was just a "don't do things in the kernel that can be reasonably be done in userspace" kind of thing. Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes: > That's not what I'm saying. What I'm saying is that it would be a big > mistake to force all drivers which implement runtime PM to do it using > a separate code path from system PM. OK; I can accept that provided there is a way to change the "what to do with an I/O request" policy from auto-resume to something else while we're suspending the system (and presumably restore the old policy on system resume if the device was runtime-suspended at the point where the system was suspended). > > The main attraction of the late-suspend call is that it really does, > > reliably, guarantee that the driver's I/O request methods won't get > > called between the late-suspend call and the early-resume call. > > For some drivers (like USB), carrying out an actual suspend requires a > delay. Right now we implement those delays using wait_event(), > wait_for_completion(), and so on. Would you have us check at runtime > whether or not a system suspend is underway and in each case use a > busy-loop instead if it is? No; the late suspend call isn't appropriate for all drivers. It is a simple and safe way to do the suspend for some drivers, mostly the simpler ones. Things that are complex enough to have a subsystem (e.g. USB) would want to use the early suspend call. > What happens if, in order to carry out the late-suspend, a driver needs > to acquire a mutex which happens to be held by some other task? That > other task won't be able to run and release the mutex, so you will > deadlock. Then late-suspend is not appropriate for that driver, and it needs to use the early-suspend call, and do something such as setting a flag that the I/O request function tests. Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes: > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd > wanting to resume devices during a system suspend transition? This is > exactly what happens when those threads aren't frozen. So, I wonder why I don't see that error on my powerbook? Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Miklos Szeredi writes: > OK, let me summarize the situation as I see it now: there are two > camps, the pro-freezers and the anti-freezers. > > Pro-freezers say: > > - don't remove the freezer, otherwise we'll have to deal with > numerous problems in drivers > > Anti-freezers say: > > - let's remove the freezer, which causes numerous problems > > Alan summerized the pro-freezer arguments well I think. What are the > anti-freezer arguments then? 1. The freezer cannot be guaranteed deadlock-free without constructing a dependency graph between tasks (both user and kernel), which is virtually impossible since the dependencies are not externally observable. 2. As a consequence of (1), we try to make a crude approximation of the graph by saying "only kernel threads that want to be frozen will be frozen" or some other similar statement. 3. However, (2) means that we can no longer guarantee that drivers will not get any I/O requests after their suspend method has been called, and therefore the freezer fails in its main objective. 4. We have an existence proof that reliable suspend can be achieved without the freezer. To summarize, the argument is that the freezer is deadlock-prone and ineffective. Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > They will not trigger 100% of the time, but sporadically and generally at > random. > > At least the freezer problems are reproducible. ;-) Our experience with powermacs has been that it isn't actually all that hard to get it right for the drivers you care about. Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes:
> > > Yes, the code could be changed to keep track of the reason for a device
> > > suspend. But that just raises the old problem of what to do when
> > > there's an I/O request for a suspended device during STR.
> >
> > Is this actually a real problem? I would think the policy would be
> > "block" for block devices (pun not intended :), "drop" for network
> > devices, etc.
>
> It is indeed a real problem, or at least, it can be.
How so? Can you give me an example?
> > How did the device get suspended if it didn't have a driver? If it
> > did have a driver, why didn't the bind attempt fail?
>
> Bus subsystems can suspend devices with no drivers.
Interesting. I assume this is for buses for which there is a
bus-specific but device-independent suspend procedure defined.
It would seem sensible to me that the PM core should get the bus to
resume such a device before calling a driver probe routine. The
resume should be blocked or deferred while a system suspend is
underway. In fact I think that all driver bind/unbind and probe
operations should be deferred while the system is suspending (i.e. put
on a list to be done after the system resumes).
> It would help. It would help even more if the sysfs core also blocked
> all I/O while suspend is under way. (Although this might be tricky,
> considering that the suspend is initiated by a sysfs write...)
I didn't think sysfs got involved at all in normal read and write
requests, so I don't know how it would block them...
> The fact remains that lots of drivers would still need to be changed.
> In the read and write methods someone would have to add code amounting
> to this:
>
> if (suspend_is_under_way()) {
> mutex_unlock(...);
> block_until_resume();
> goto restart;
> }
>
> Freezing userspace is a small amount of code by comparison.
Normally devices have some sort of queue of pending operations. So
all that is required on suspend is to stop processing the queue and
wait for any currently-underway operations to complete. The blocking
then happens naturally using the normal I/O wait mechanisms.
Paul.
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xen: can't support numa yet
Xen currently relies on contigious memory (ie, no numa, discontig or sparse memory). Specifically it uses mem_map, which is only available if CONFIG_NEED_MULTIPLE_NODES is not defined. Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: Adrian Bunk <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> --- arch/i386/xen/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) === --- a/arch/i386/xen/Kconfig +++ b/arch/i386/xen/Kconfig @@ -4,7 +4,7 @@ config XEN bool "Enable support for Xen hypervisor" - depends on PARAVIRT && X86_CMPXCHG && X86_TSC + depends on PARAVIRT && X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES help This is the Linux Xen port. Enabling this will allow the kernel to boot in a paravirtualized environment under the - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The big suspend mess
> IMHO the suspend code is currently way too much of a moving target which > results in this mess. > > The correct order seems to be: 0. Get someone to sign up as a maintainer for suspend, so we have someone to blame for the mess? :-) > 1. agree on what the suspend code as a whole should look like > 2. implement this > 3. fix ALL drivers to work at least as good as they do today > 4. get it tested in -mm > 5. fix all bugs people run into > 6. submit it for inclusion in Linus' tree > 7. quickly work on the most likely big amount of bug reports > > Step 1 is the most important one - evolving code is often something > good, but in this case with different people trying to evolve the > suspend code in different directions it simply results in a big mess. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Rafael J. Wysocki writes: > This is incompatible with the code in kernel/power/main.c, since we only > disable the nonboot CPUs after devices have been suspended. Do you think that > your framework can be modified to work without disabling the nonboot CPUs > by the user space? Sure. It was a "if it can be done in userspace, do it in userspace" kind of decision, but I'm not wedded to it. I actually do want to converge to using the generic suspend-to-ram code on powerbooks. I just want to avoid causing regressions for powerbook users, including myself. :) Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Alan Stern writes: > Let's agree the kernel threads and the freezer are a separate issue. No, I don't think they are a separate issue, because I think the distinction the freezer makes between kernel threads and user threads is a false and misleading distinction. > In the most recent kernels, the freezer does not suspend kernel threads > by default. And therefore doesn't guarantee that drivers won't get I/O requests after being suspended, as far as I can see... > I agree the kernel threads which try to do I/O during a suspend will > need extra attention. However if these threads are necessary for the > suspend procedure, then blocking them (which is how people on this > thread have been saying driver should treat I/O requests during a > suspend) will cause additional problems. There's no way around it; > these threads _will_ require more work. There is a way around it; do the request blocking in the drivers, where it belongs. > > > The reasons why the PPC people dislike the whole idea aren't clear to > > > me. > > > > Our experience is that it isn't necessary. It's extra code that in > > practice causes deadlocks and added maintenance burden for no > > discernable benefit. > > I have discussed the benefits elsewhere. As for the deadlocks -- do > you still observe them if you use the version of the freezer which > doesn't freeze kernel threads? In general the only way to guarantee there are no deadlocks is to construct the graph of dependencies between tasks. Those dependencies are not in practice observable from outside the tasks, so it is virtually impossible to construct the graph. The "don't freeze kernel threads" thing is an attempt to make a crude approximation to the dependency graph (by saying kernel threads only depend on other kernel threads), but the approximation breaks down when you have FUSE or user-level device drivers. > Userspace cannot do I/O directly on its own, apart from some > exceptional situations where a privileged task directly twiddles some > I/O ports or the equivalent. Userspace can be involved in servicing I/O requests; not just FUSE, but also user-level nfsd and user-level PPP demonstrate that. > There remains the problem of user tasks whose assistance is required to > carry out some I/O (as with FUSE). If the I/O can be deferred until > after the resume, then there's no problem. If the I/O can be carried > out before the suspend, then it should be. And finally, if the I/O > must be done during the suspend, you're in real trouble -- how do you > do I/O to a suspended device? So why doesn't that argument apply to kernel threads? :) > > I remain convinced that the right approach is to fix the drivers to do > > one of two things; either do something in the suspend call to block > > further requests to the device, or use a late-suspend call to put > > their device into a low-power state. Of course, correctly-written > > frameworks can do a lot to help the chipset drivers here. > > The first alternative is a possibility. My argument all along has been > that it is difficult and error-prone, and it adds more overhead to > system operation (even when not suspending!) than simply freezing > userspace. It does actually provably solve the problem though, which is more than the freezer does. Paul. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.22-rc7: known regressions
On Tue, 2007-07-03 at 18:45 +0200, Michal Piotrowski wrote: > Subject: random invalid instruction occourances on sparc32 (sun4c) > References : http://lkml.org/lkml/2007/6/17/111 > Submitter : Mark Fortescue <[EMAIL PROTECTED]> > Status : problem is being debugged Hm, when testing the fix for that on ppc32, I stupidly built with Slub instead, and got this... radeonfb: Monitor 1 type LCD found radeonfb: EDID probed radeonfb: Monitor 2 type no found radeonfb: Using Firmware dividers 0x00040080 from PPLL 0 radeonfb: Dynamic Clock Power Management enabled *** SLUB kmalloc-32768: Poison check [EMAIL PROTECTED] slab 0xc04de400 [Not tainted] offset=0 flags=0x40c3 inuse=0 freelist=0xc1e2 Object 0xc1e2: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20020: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20030: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20040: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20050: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20060: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc1e20070: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Redzone 0xc1e28000: bb bb bb bb FreePointer 0xc1e28004 -> 0x Last alloc: malloc+0x14/0x24 jiffies_ago=1382 cpu=0 pid=1 Last free : free+0x10/0x20 jiffies_ago=837 cpu=0 pid=1 Filler 0xc1e28028: 5a 5a 5a 5a 5a 5a 5a 5a Call Trace: [effc7b80] [c000893c] show_stack+0x50/0x184 (unreliable) [effc7ba0] [c009705c] object_err+0x178/0x18c [effc7bc0] [c0097380] check_object+0x180/0x2ec [effc7be0] [c0098320] __slab_alloc+0x5c8/0x5f4 [effc7c10] [c0098aa4] __kmalloc+0x64/0x9c [effc7c30] [c015f5dc] fbcon_startup+0x154/0x2c0 [effc7c60] [c01bb8ec] register_con_driver+0x94/0x164 [effc7c90] [c01bedc8] take_over_console+0x24/0x58 [effc7cb0] [c015b41c] fbcon_takeover+0x8c/0xec [effc7cc0] [c015d31c] fbcon_event_notify+0x1e0/0x6c8 [effc7d90] [c02d9490] notifier_call_chain+0x3c/0x94 [effc7db0] [c0045468] __blocking_notifier_call_chain+0x50/0x74 [effc7dd0] [c014f514] fb_notifier_call_chain+0x24/0x34 [effc7de0] [c0150590] register_framebuffer+0x190/0x1a8 [effc7e40] [c0185450] radeonfb_pci_register+0xe54/0xf50 [effc7e70] [c0145b04] pci_device_probe+0x6c/0xa0 [effc7e90] [c01d4108] driver_probe_device+0xfc/0x1a0 [effc7eb0] [c01d436c] __driver_attach+0xac/0x110 [effc7ed0] [c01d32f0] bus_for_each_dev+0x50/0x94 [effc7f00] [c01d3efc] driver_attach+0x24/0x34 [effc7f10] [c01d3710] bus_add_driver+0x78/0x1a0 [effc7f30] [c01d468c] driver_register+0x88/0x9c [effc7f40] [c0145900] __pci_register_driver+0x6c/0xb8 [effc7f60] [c03e8e4c] radeonfb_init+0x20c/0x220 [effc7f80] [c03c82e4] kernel_init+0xc8/0x284 [effc7ff0] [c0013e28] kernel_thread+0x44/0x60 @@@ SLUB kmalloc-32768: Restoring Poison (0x6b) from 0xc1e2-0xc1e27ffe @@@ SLUB kmalloc-32768: Restoring Poison (0xa5) from 0xc1e27fff-0xc1e27fff @@@ SLUB: kmalloc-32768 slab 0xc04de400. Marking all objects used. Console: switching to colour frame buffer device 180x56 -- dwmw2 - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][Trivial] fix tiny spelling error in comment in cfi_cmdset_0001.c
Trivial fix of a spelling error in a comment in cfi_cmdset_0001.c s/ships/chips/ Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/mtd/chips/cfi_cmdset_0001.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c index 2f19fa7..c266ebc 100644 --- a/drivers/mtd/chips/cfi_cmdset_0001.c +++ b/drivers/mtd/chips/cfi_cmdset_0001.c @@ -526,7 +526,7 @@ static int cfi_intelext_partition_fixup(struct mtd_info *mtd, struct cfi_pri_intelext *extp = cfi->cmdset_priv; /* -* Probing of multi-partition flash ships. +* Probing of multi-partition flash chips. * * To support multiple partitions when available, we simply arrange * for each of them to have their own flchip structure even if they - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway
Hi! > > > I don't claim to know anything about how STR or hibernate works, but > > > neither seem to have any problem with I/O on the fuse device "racing" > > > with them. > > > > The problem is not with fuse. The problem is generic in nature. > > > > If you remove the freezer, user space remains active until the last CPU > > goes into suspend. It can do syscalls. Or do you know a clean way to exempt > > only the tasks fuse might use? > > You are talking about hibernate, right? Suspending (to ram) is > instantaneous, in that _after_ suspend no CPU is active obviously. No, suspend to ram is not instantaneous. We may have 16 cpus, and we may have 250 disks that need to be spun down. That takes time, and is really not atomic operation. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
Hi! > So I think Matthew is totally right. In fact, the presence of the > freezer is the main reason why Paulus so far NACKed Johannes attempts at > merging the PPC PM code with the generic code in kernel/power.c > > We've been doing fine without it so far and intend to continue to do > so. How well does it work on SMP PPC? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"libata ignore_hpa=1" doesn't wok on SATA ?
Hi, . I would like to see the whole disk area and erase the hpa area in my desktop. At first I tried "setmax.c" program but it didn't work on SATA at least. So I upgraeded it to FC7 and added "libata ignore_hpa=1" option on boot command and /etc/modprobe.conf. This option was accepted but still the kernel couldn't see the whole disk area even after reboot. I am using FC7, kernel-2.6.21 and 250 SATA disk. Could you please give me some more tips ? . Warm regards, Nobel 180도 달라진 야후! 메일 - 여러 개의 메시지를 동시에 확인? 새로운 야후! 메일의 탭으로 가능해집니다. http://kr.content.mail.yahoo.com/cgland - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm Patch] INFINIBAND: check the return value of kmalloc
On 04/07/07, WANG Cong <[EMAIL PROTECTED]> wrote:
Don't forget to check the return value of kmalloc().
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc6-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.c
===
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c 2007-06-29
13:18:20.0 +0800
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c 2007-07-04
23:17:02.0 +0800
@@ -1166,6 +1166,10 @@
dev->ibdev.iwcm =
(struct iw_cm_verbs *) kmalloc(sizeof(struct iw_cm_verbs),
While you are here anyway, why not get rid of that pointless kmalloc()
return value cast at the same time?
GFP_KERNEL);
+ if (!dev->ibdev.iwcm) {
+ ret = -1;
+ goto bail1;
+ }
dev->ibdev.iwcm->connect = iwch_connect;
dev->ibdev.iwcm->accept = iwch_accept_cr;
dev->ibdev.iwcm->reject = iwch_reject_cr;
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Some love to default profiler
On 04/07/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
1) Drop __KERNEL__ out of profile.h. It contains only internal kernel stuff and
not in exported headers list
Even if it's not in the list of exported headers, does it really hurt
to retain that extra safeguard?
2) Put profile.c under CONFIG_PROFILING. You enabled profiling in config, you
will get it.
Makes logical sense. If the user didn't enable CONFIG_PROFILING why
should she get any profiling related overhead of any kind if we can
avoid it?
Removes conditional branch from schedule(). Code savings on my
usual config:
textdata bss dec hex filename
2921871 179895 180224 3281990 321446 vmlinux before
2920141 179847 180224 3280212 320d54 vmlinux after
--
-1730 -48 -1778
Nice savings there. Not that 1.7K is huge, but it's kernel memory is
precious :-)
3) Make timer_hook static (hi, Adrian!)
Makes perfect sense to me.
4) Convert do {} while (0) into static inline functions
Seems reasonable.
5) minor misc stuff
One tiny comment below.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/profile.h | 78 +---
kernel/Makefile |3 +
kernel/profile.c|2 -
3 files changed, 44 insertions(+), 39 deletions(-)
[snip]
+#define prof_on 0
+static inline void profile_init(void)
+{
+}
Just to be pedantic; don't we want a blank line between functions
here, even if they are empty?
+static inline void profile_tick(int type)
+{
+}
+static inline void profile_hits(int type, void *ip, unsigned int nr_hits)
+{
+}
+static inline void profile_hit(int type, void *ip)
+{
+}
+static inline void profile_munmap(unsigned long addr)
+{
+}
+static inline void profile_task_exit(struct task_struct *tsk)
+{
+}
+static inline int profile_handoff_task(struct task_struct *tsk)
+{
+ return 0;
+}
[snip]
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue 2007-07-03 21:32:20, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi: > > > And a further question. The freezer is not atomic. What do you do > > > if a task not yet frozen calls sys_sync(), but fuse is already frozen? > > > > What do you do if a task not yet frozen writes to a pipe, on the other > > end of which is a task already frozen? There's some difference between uninterruptible and interruptible sleep I'd say. > > It doesn't matter. The only thing that should matter during suspend > > (not hibernate) is saving the state of devices to ram, and putting the > > devices to sleep. > > Well, but you did remove sys_sync() from the freezer, which is > and must be called in the hibernate path. Not "must". In fact, hibernation should be safe without sys_sync(). It is just user un-friendly. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness
On Wed, 4 Jul 2007, Andy Isaacson wrote: > On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote: > > You could easily replace the cookie with a pointer to a free > > page pool. > > It just occurred to me that something like this is *required* to get the > performance benefit from MAP_NOZERO on a busy system. With Davide's > current proposal, if there are N jobs with different "nozero cookies" > busy allocating and deallocating pages on a single-NUMA-node system, > then there's only a 1/N chance that the page returned by __alloc_pages > will have the correct cookie, so (N-1)/N percent of the time MAP_NOZERO > will have no positive effect -- 90% of the time for the case of N=10. That can indeed happen. If you have a system busy with pressure coming from many different users, the recycle efficency goes down proportionally with it. As I said before, I prefer a smaller and less intrusive code that gives good recycle efficency for the mejority of systems, WRT the idea of dedicated pools. But maybe I'm wrong, and Rik or you can show up with a patch implementing pools that does not hurt code, structure sizes and performances. > In a mostly unrelated complaint, I note that having a function named > "alloc_zeroed_page_vma" which returns a potentially nonzero page is, um, > unintuitive. It needs a name which does not claim it returns zeroed > pages. I'm no good at names, but perhaps "alloc_available_page_vma"? Yeah, the name "zeroed" is not perfect, but neither it is "available". The name should give the idea that the page is either from the same ID/cookie or it is zeroed. That naming should be applied back to alloc_zeroed_user_highpage(), __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE, ... - Davide - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue 2007-07-03 19:20:59, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Rafael J. Wysocki: > > On Tuesday, 3 July 2007 15:08, Rafael J. Wysocki wrote: > > > On Tuesday, 3 July 2007 07:51, Benjamin Herrenschmidt wrote: > > > > On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > > > > > Suspend to RAM on a machine with / on a fuse filesystem turns out to > > > > > be > > > > > a screaming nightmare - either the suspend fails because syslog (for > > > > > instance) can't be frozen, or the machine deadlocks for some other > > > > > reason I haven't tracked down. We could "fix" fuse, or alternatively > > > > > we > > > > > could do what we do for suspend to RAM on other platforms (PPC and > > > > > APM) > > > > > and just not use the freezer. > > > > > > > > The main reason for deadlocks is because we do a sys_sync() after the > > > > freeze, which we shouldn't do. > > > > > > So why don't we remove the sys_sync() from freeze_processes() instead? > > > > The patch follows (untested). > > > > Greetings, > > Rafael > > > > > > --- > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > We shouldn't sync filesystems from within the freezer, because it's not > > needed > > for suspend to RAM and leads to problems with FUSE. > > This seems fishy. Swsusp needs enough clean memory to make enough > room for the image. If you sync before you freeze, the running tasks can > redirty memory. > What makes you sure that you don't die as shrink_all_memory() writes out > pages? Shrink_all_memory should just free enough memory, what's the problem? Yes, we can have dirty memory, shrink_all_memory() can write that out just fine. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
Hi! > Suspend to RAM on a machine with / on a fuse filesystem turns out to be > a screaming nightmare - either the suspend fails because syslog (for > instance) can't be frozen, or the machine deadlocks for some other > reason I haven't tracked down. We could "fix" fuse, or alternatively we > could do what we do for suspend to RAM on other platforms (PPC and APM) > and just not use the freezer. > > Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]> Sorry, no. * this needs audit of all drivers. Or we can just merge it and then fix all the problems it causes. If you are willing to become suspend maintainer and handle all that mess, perhaps we can do this. * it does not solve FUSE vs. hibernation * it does not solve FUSE vs. suspend-to-both * userspace will now see CPUs going up and down at minimum Now, we want to do something like this long-term, but I do not think we can just remove the freezer like this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix trivial typos in anon_inodes.c comments
From: J. Bruce Fields <[EMAIL PROTECTED]>
Trivial typo and grammar fixes.
Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]>
---
fs/anon_inodes.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 40fe3a3..a260198 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -53,7 +53,7 @@ static struct dentry_operations
anon_inodefs_dentry_operations = {
};
/**
- * anon_inode_getfd - creates a new file instance by hooking it up to and
+ * anon_inode_getfd - creates a new file instance by hooking it up to an
*anonymous inode, and a dentry that describe the "class"
*of the file
*
@@ -66,7 +66,7 @@ static struct dentry_operations
anon_inodefs_dentry_operations = {
*
* Creates a new file by hooking it on a single inode. This is useful for files
* that do not need to have a full-fledged inode in order to operate correctly.
- * All the files created with anon_inode_getfd() will share a single inode, by
+ * All the files created with anon_inode_getfd() will share a single inode,
* hence saving memory and avoiding code duplication for the file/inode/dentry
* setup.
*/
@@ -141,9 +141,9 @@ err_put_filp:
}
/*
- * A single inode exist for all anon_inode files. Contrary to pipes,
- * anon_inode inodes has no per-instance data associated, so we can avoid
- * the allocation of multiple of them.
+ * A single inode exists for all anon_inode files. Contrary to pipes,
+ * anon_inode inodes have no associated per-instance data, so we need
+ * only allocate one of them.
*/
static struct inode *anon_inode_mkinode(void)
{
--
1.5.2.rc3
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
> > > > > Beep_flags should be removed too if you're sticking with /proc. > > > > > > > > Fixed. > > > > > > Ta. But you didn't answer the question - why /proc and not sysfs? > > > > Do you seriously advocate setting two bits of one variable from /proc, > > and one more bit from /sys? > > That's partly why I had a separate variable - retaining proc only because > it's > existing functionality, using sysfs for the new code. Remember, too, that /proc is not deprecated _that_ much, and notice that this is sysctl, not regular procfs code. Yes, I see why you did it that way, but I also think you overdisgned it a bit. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
Hi!
> > I copied code from Dmitry :-); guess I copied too much. Here's updated
> > version:
>
> Umm, it's updated exactly how?
Sorry. I updated it in my tree but produced wrong patch. Here's
updated updated version: (trimmed cc list).
> > +struct blinker {
> > + struct delayed_work work;
> ...
> > + schedule_delayed_work(>work, 0);
> ...
> > + INIT_DELAYED_WORK(>work, blink_task_handler);
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 87d2046..716620c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -95,6 +95,13 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_INPUT
+ tristate "LED Support for input layer keyboards"
+ depends on LEDS_CLASS
+ help
+ This option enables support for LEDs on keyboards handled by
+ input layer.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..ea58020 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -16,8 +16,10 @@ obj-$(CONFIG_LEDS_NET48XX) += leds-net4
obj-$(CONFIG_LEDS_WRAP)+= leds-wrap.o
obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
+obj-$(CONFIG_LEDS_INPUT) += leds-input.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+
diff --git a/drivers/leds/leds-input.c b/drivers/leds/leds-input.c
new file mode 100644
index 000..2805de8
--- /dev/null
+++ b/drivers/leds/leds-input.c
@@ -0,0 +1,151 @@
+/*
+ * LED <-> input subsystem glue
+ *
+ * Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
+ * Copyright 2007 Dmitry Torokhov
+ * Copyright 2005-2006 Openedhand Ltd.
+ *
+ * Author: Pavel Machek <[EMAIL PROTECTED]>
+ * Based on code by: Richard Purdie <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+struct blinker {
+ struct work_struct work;
+ struct input_handle handle;
+ int state;
+
+ struct led_classdev dev;
+};
+
+struct blinker *blinker;
+
+static void inputled_set(struct led_classdev *led_cdev, enum led_brightness
value)
+{
+ struct blinker *blinker = container_of(led_cdev, struct blinker, dev);
+ blinker->state = value;
+ schedule_work(>work);
+}
+
+static void blink_task_handler(struct work_struct *work)
+{
+ struct blinker *blinker = container_of(work, struct blinker, work);
+ input_inject_event(>handle, EV_LED, LED_CAPSL,
!!blinker->state);
+}
+
+static void blink_event(struct input_handle *handle, unsigned int type,
+ unsigned int code, int down)
+{
+ /*
+* This is a very rare handler that does not process any input
+* events; just injects them.
+*/
+}
+
+static int blink_connect(struct input_handler *handler, struct input_dev *dev,
+ const struct input_device_id *id)
+{
+ struct input_handle *handle;
+ struct led_classdev *led_dev;
+ static int counter;
+ int error;
+
+ blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
+ if (!blinker) {
+ return -ENOMEM;
+ }
+
+ INIT_WORK(>work, blink_task_handler);
+
+ led_dev = >dev;
+ led_dev->name = kmalloc(10, GFP_KERNEL);
+ sprintf(led_dev->name, "input%d", counter++);
+ led_dev->brightness_set = inputled_set;
+
+ handle = >handle;
+ handle->dev = dev;
+ handle->handler = handler;
+ handle->name = "blink";
+ handle->private = blinker;
+
+ error = input_register_handle(handle);
+ if (error)
+ goto err_free_handle;
+
+ error = input_open_device(handle);
+ if (error)
+ goto err_unregister_handle;
+
+ error = led_classdev_register(NULL, led_dev);
+ if (error < 0)
+ goto err_input_close_device;
+
+ return 0;
+
+ err_input_close_device:
+ input_close_device(handle);
+ err_unregister_handle:
+ input_unregister_handle(handle);
+ err_free_handle:
+ kfree(handle);
+ return error;
+}
+
+static void blink_disconnect(struct input_handle *handle)
+{
+ struct blinker *blinker = handle->private;
+
+ led_classdev_unregister(>dev);
+ input_close_device(handle);
+ input_unregister_handle(handle);
+ kfree(blinker);
+}
+
+static const struct input_device_id blink_ids[] = {
+ {
+ .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_LEDBIT,
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi.
On Thursday 05 July 2007 09:01:09 Pavel Machek wrote:
> Hi!
>
> > > > > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> > > > >
> > > > > __setup("acpi_sleep=", acpi_sleep_setup);
> > > > >
> > > > > +/* Ouch, we want to delete this. We already have better version in
> > > > userspace, in
> > > > > + s2ram from suspend.sf.net project */
> > > >
> > > > Do we? This version has advantages in not requiring any userspace app
and
> > in
> > > > being able to work even if you can't yet get as far as having
> > >
> > > Take a look at the file. It has whitelist with just one entry, too
> > > bad.
> >
> > The contents of the whitelist are irrelevant. My laptop needs this
> > functionality, but I haven't bothered to send you a whitelist entry, in
part
> > because I don't use s2ram.
> >
> > Regardless of that, if you had read the whole comment (you've deleted half
of
> > it), you would have noticed that I ended up changing my mind and instead
> > saying "Why not just delete the __setup now, or at least put it in the
> > deprecated file?"
>
> That should be certainly done in separate patch, right? It is on my
> todolist somewhere now.
Yeah, agree.
> > > > > @@ -124,7 +124,7 @@ real_save_cr3:.long 0
> > > > > real_save_cr4: .long 0
> > > > > real_magic: .long 0
> > > > > video_mode: .long 0
> > > > > -video_flags: .long 0
> > > > > +realmode_flags: .long 0
> > > > > beep_flags: .long 0
> > > > > real_efer_save_restore: .long 0
> > > > > real_save_efer_edx: .long 0
> > > >
> > > > Beep_flags should be removed too if you're sticking with /proc.
> > >
> > > Fixed.
> >
> > Ta. But you didn't answer the question - why /proc and not sysfs?
>
> Do you seriously advocate setting two bits of one variable from /proc,
> and one more bit from /sys?
That's partly why I had a separate variable - retaining proc only because it's
existing functionality, using sysfs for the new code. Remember, too, that
they're really distinct functionality. The only thing they share is that
they're both used in real mode.
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
pgpHMqUeXvRvr.pgp
Description: PGP signature
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi!
> > > > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> > > >
> > > > __setup("acpi_sleep=", acpi_sleep_setup);
> > > >
> > > > +/* Ouch, we want to delete this. We already have better version in
> > > userspace, in
> > > > + s2ram from suspend.sf.net project */
> > >
> > > Do we? This version has advantages in not requiring any userspace app and
> in
> > > being able to work even if you can't yet get as far as having
> >
> > Take a look at the file. It has whitelist with just one entry, too
> > bad.
>
> The contents of the whitelist are irrelevant. My laptop needs this
> functionality, but I haven't bothered to send you a whitelist entry, in part
> because I don't use s2ram.
>
> Regardless of that, if you had read the whole comment (you've deleted half of
> it), you would have noticed that I ended up changing my mind and instead
> saying "Why not just delete the __setup now, or at least put it in the
> deprecated file?"
That should be certainly done in separate patch, right? It is on my
todolist somewhere now.
> > > > @@ -124,7 +124,7 @@ real_save_cr3: .long 0
> > > > real_save_cr4: .long 0
> > > > real_magic:.long 0
> > > > video_mode:.long 0
> > > > -video_flags: .long 0
> > > > +realmode_flags:.long 0
> > > > beep_flags:.long 0
> > > > real_efer_save_restore:.long 0
> > > > real_save_efer_edx:.long 0
> > >
> > > Beep_flags should be removed too if you're sticking with /proc.
> >
> > Fixed.
>
> Ta. But you didn't answer the question - why /proc and not sysfs?
Do you seriously advocate setting two bits of one variable from /proc,
and one more bit from /sys?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: implement-file-posix-capabilities.patch
--- Andrew Morgan <[EMAIL PROTECTED]> wrote: > no one has yet actually > given an example of where fE being richer than a simple binary helps > anything. Until I see an example, I'm going to hold the position that > this is needless "complexity". The only counter to this argument is that you now have a different structure on files than on processes. Not a major issue, but one structure to describe capability sets is less complex than two. That way you can have one function to print a capset, regardless of its coming off a file or a process. Just a thought. Casey Schaufler [EMAIL PROTECTED] - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
Hi!
> > Actually here's one that does not immediately oops when I plug USB
> > keyboard in.
>
> Why do you use a delayed workqueue and then always use it without a delay?
> That seems silly.
I copied code from Dmitry :-); guess I copied too much. Here's updated
version:
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 87d2046..716620c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -95,6 +95,13 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_INPUT
+ tristate "LED Support for input layer keyboards"
+ depends on LEDS_CLASS
+ help
+ This option enables support for LEDs on keyboards handled by
+ input layer.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..ea58020 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -16,8 +16,10 @@ obj-$(CONFIG_LEDS_NET48XX) += leds-net4
obj-$(CONFIG_LEDS_WRAP)+= leds-wrap.o
obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
+obj-$(CONFIG_LEDS_INPUT) += leds-input.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+
diff --git a/drivers/leds/leds-input.c b/drivers/leds/leds-input.c
new file mode 100644
index 000..8caca35
--- /dev/null
+++ b/drivers/leds/leds-input.c
@@ -0,0 +1,153 @@
+/*
+ * LED <-> input subsystem glue
+ *
+ * Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
+ * Copyright 2007 Dmitry Torokhov
+ * Copyright 2005-2006 Openedhand Ltd.
+ *
+ * Author: Pavel Machek <[EMAIL PROTECTED]>
+ * Based on code by: Richard Purdie <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+struct blinker {
+ struct delayed_work work;
+ struct input_handle handle;
+ int state;
+
+ struct led_classdev dev;
+};
+
+struct blinker *blinker;
+
+static void inputled_set(struct led_classdev *led_cdev, enum led_brightness
value)
+{
+ struct blinker *blinker = container_of(led_cdev, struct blinker, dev);
+ blinker->state = value;
+ schedule_delayed_work(>work, 0);
+}
+
+static void blink_task_handler(struct work_struct *work)
+{
+ struct blinker *blinker = container_of(work, struct blinker, work.work);
+ printk("Setting led to %d\n", blinker->state);
+ input_inject_event(>handle, EV_LED, LED_CAPSL,
!!blinker->state);
+}
+
+static void blink_event(struct input_handle *handle, unsigned int type,
+ unsigned int code, int down)
+{
+ /*
+* This is a very rare handler that does not process any input
+* events; just injects them.
+*/
+}
+
+static int blink_connect(struct input_handler *handler, struct input_dev *dev,
+ const struct input_device_id *id)
+{
+ struct input_handle *handle;
+ struct led_classdev *led_dev;
+ static int counter;
+ int error;
+
+ blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
+ if (!blinker) {
+ return -ENOMEM;
+ }
+
+ INIT_DELAYED_WORK(>work, blink_task_handler);
+
+ led_dev = >dev;
+ led_dev->name = kmalloc(10, GFP_KERNEL);
+ sprintf(led_dev->name, "input%d", counter++);
+ led_dev->brightness_set = inputled_set;
+
+ handle = >handle;
+ handle->dev = dev;
+ handle->handler = handler;
+ handle->name = "blink";
+ handle->private = blinker;
+
+ error = input_register_handle(handle);
+ if (error)
+ goto err_free_handle;
+
+ error = input_open_device(handle);
+ if (error)
+ goto err_unregister_handle;
+
+ error = led_classdev_register(NULL, led_dev);
+ if (error < 0)
+ goto err_input_close_device;
+
+ return 0;
+
+ err_input_close_device:
+ input_close_device(handle);
+ err_unregister_handle:
+ input_unregister_handle(handle);
+ err_free_handle:
+ kfree(handle);
+ return error;
+}
+
+static void blink_disconnect(struct input_handle *handle)
+{
+ struct blinker *blinker = handle->private;
+
+ led_classdev_unregister(>dev);
+ cancel_rearming_delayed_work(>work);
+ input_close_device(handle);
+ input_unregister_handle(handle);
+ kfree(blinker);
+}
+
+static const struct input_device_id blink_ids[] = {
+ {
+ .flags =
[PATCH][isapnp] Remove pointless check of 'type' against 0 in isapnp_read_tag()
On Wednesday 04 July 2007 03:04:13 Jesper Juhl wrote: > On 03/07/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Sun, 1 Jul 2007 01:38:31 +0200 > > > > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > The Coverity checker spotted (as bug #809) that we dereference 'type' > > > long before we actually test it against NULL in > > > drivers/pnp/isapnp/core.c::isapnp_read_tag() - both branches of the > > > 'if (tag & 0x80)' dereference type, and since this 'if' is before the > > > test against NULL and the return of -1, this will blow up is ever type > > > is NULL. This is easy to fix by simply moving the NULL test to the > > > beginning of the function. > > [snip] > > > dood, look at the callers. NULL is not possible here. > > You are right, there's absolutely no way that we could get a NULL > pointer there - that was sloppy of me :-( > > I guess we should just get rid of the check completely. I'll cook up > a patch for that tomorrow. Ok, here's a patch to just remove the check. In drivers/pnp/isapnp/core.c::isapnp_read_tag() there is a test of 'type' being == 0 a bit down in the function. That test doesn't make any sense. If 'type' could indeed be NULL, then the test happens way too late as we'd already have tried to dereference the pointer earlier and looking at the callers it also turns out that there is no way type can ever actually be NULL. So the test is completely pointless and should just be removed. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/pnp/isapnp/core.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c index a0b1587..914d00c 100644 --- a/drivers/pnp/isapnp/core.c +++ b/drivers/pnp/isapnp/core.c @@ -370,8 +370,6 @@ static int __init isapnp_read_tag(unsigned char *type, unsigned short *size) #if 0 printk(KERN_DEBUG "tag = 0x%x, type = 0x%x, size = %i\n", tag, *type, *size); #endif - if (type == 0) /* wrong type */ - return -1; if (*type == 0xff && *size == 0x) /* probably invalid data */ return -1; return 0; - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi.
On Thursday 05 July 2007 08:48:59 Pavel Machek wrote:
> Hi!
>
> > Documentation is also an issue. Your patch should update the
kernel_parameters
> > file so users can know how to get the beeping to happen. It would be nice
if
> > it mentioned the proc entry too.
>
> Fixed the docs.
Ta.
> > > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> > >
> > > __setup("acpi_sleep=", acpi_sleep_setup);
> > >
> > > +/* Ouch, we want to delete this. We already have better version in
> > userspace, in
> > > + s2ram from suspend.sf.net project */
> >
> > Do we? This version has advantages in not requiring any userspace app and
in
> > being able to work even if you can't yet get as far as having
>
> Take a look at the file. It has whitelist with just one entry, too
> bad.
The contents of the whitelist are irrelevant. My laptop needs this
functionality, but I haven't bothered to send you a whitelist entry, in part
because I don't use s2ram.
Regardless of that, if you had read the whole comment (you've deleted half of
it), you would have noticed that I ended up changing my mind and instead
saying "Why not just delete the __setup now, or at least put it in the
deprecated file?"
> > > @@ -124,7 +124,7 @@ real_save_cr3:.long 0
> > > real_save_cr4: .long 0
> > > real_magic: .long 0
> > > video_mode: .long 0
> > > -video_flags: .long 0
> > > +realmode_flags: .long 0
> > > beep_flags: .long 0
> > > real_efer_save_restore: .long 0
> > > real_save_efer_edx: .long 0
> >
> > Beep_flags should be removed too if you're sticking with /proc.
>
> Fixed.
Ta. But you didn't answer the question - why /proc and not sysfs?
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
pgpMtfWDsge3O.pgp
Description: PGP signature
Re: [RFC][PATCH -mm] PM: Do not sync from within the freezer during suspend to RAM
Hi. On Thursday 05 July 2007 08:49:42 Pavel Machek wrote: > On Thu 2007-07-05 08:48:15, Nigel Cunningham wrote: > > Hi. > > > > On Thursday 05 July 2007 00:58:58 Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > The syncing of filesystems from within the freezer in not needed for suspend > > to > > > RAM. Change freeze_processes() so that it doesn't execute sys_sync() and > > > introduce the "syncing" version of it to be called from the hibernation code > > > paths. > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > --- > > > include/linux/freezer.h | 14 -- > > > kernel/power/disk.c |2 +- > > > kernel/power/main.c |6 ++ > > > kernel/power/process.c |8 +--- > > > kernel/power/user.c |2 +- > > > 5 files changed, 25 insertions(+), 7 deletions(-) > > > > Looks ok, except that I wonder if you want the following fragment. It looks to > > me (looking at rc6) like with this code, you'll currently call sys_sync twice > > when suspending to ram. Maybe I'm misreading it. Also, shouldn't it be done > > after taking the mutex? > > sys_sync() should be okay to call, mutex or not. Yeah. That wasn't my point, sorry. Calling sys_sync is pointless if you're going to fail to take the mutex. It makes more sense to know you've got it before you start doing things related to actually suspending. Regards, Nigel -- See http://www.tuxonice.net for Howtos, FAQs, mailing lists, wiki and bugzilla info. pgpEWOwj1PgR1.pgp Description: PGP signature
Re: [RFC][PATCH -mm] PM: Do not sync from within the freezer during suspend to RAM
On Thu 2007-07-05 08:48:15, Nigel Cunningham wrote: > Hi. > > On Thursday 05 July 2007 00:58:58 Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > The syncing of filesystems from within the freezer in not needed for > > suspend > to > > RAM. Change freeze_processes() so that it doesn't execute sys_sync() and > > introduce the "syncing" version of it to be called from the hibernation code > > paths. > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > --- > > include/linux/freezer.h | 14 -- > > kernel/power/disk.c |2 +- > > kernel/power/main.c |6 ++ > > kernel/power/process.c |8 +--- > > kernel/power/user.c |2 +- > > 5 files changed, 25 insertions(+), 7 deletions(-) > > Looks ok, except that I wonder if you want the following fragment. It looks > to > me (looking at rc6) like with this code, you'll currently call sys_sync twice > when suspending to ram. Maybe I'm misreading it. Also, shouldn't it be done > after taking the mutex? sys_sync() should be okay to call, mutex or not. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm] PM: Do not sync from within the freezer during suspend to RAM
Hi.
On Thursday 05 July 2007 00:58:58 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> The syncing of filesystems from within the freezer in not needed for suspend
to
> RAM. Change freeze_processes() so that it doesn't execute sys_sync() and
> introduce the "syncing" version of it to be called from the hibernation code
> paths.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> include/linux/freezer.h | 14 --
> kernel/power/disk.c |2 +-
> kernel/power/main.c |6 ++
> kernel/power/process.c |8 +---
> kernel/power/user.c |2 +-
> 5 files changed, 25 insertions(+), 7 deletions(-)
Looks ok, except that I wonder if you want the following fragment. It looks to
me (looking at rc6) like with this code, you'll currently call sys_sync twice
when suspending to ram. Maybe I'm misreading it. Also, shouldn't it be done
after taking the mutex?
Regards,
Nigel
> @@ -231,6 +232,11 @@ static int enter_state(suspend_state_t s
>
> if (!valid_state(state))
> return -ENODEV;
> +
> + printk("Syncing filesystems ... ");
> + sys_sync();
> + printk("done.\n");
> +
> if (!mutex_trylock(_mutex))
> return -EBUSY;
>
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
pgppKVHAOQ9Os.pgp
Description: PGP signature
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi!
> Documentation is also an issue. Your patch should update the
> kernel_parameters
> file so users can know how to get the beeping to happen. It would be nice if
> it mentioned the proc entry too.
Fixed the docs.
> > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> >
> > __setup("acpi_sleep=", acpi_sleep_setup);
> >
> > +/* Ouch, we want to delete this. We already have better version in
> userspace, in
> > + s2ram from suspend.sf.net project */
>
> Do we? This version has advantages in not requiring any userspace app and in
> being able to work even if you can't yet get as far as having
Take a look at the file. It has whitelist with just one entry, too
bad.
> > @@ -124,7 +124,7 @@ real_save_cr3: .long 0
> > real_save_cr4: .long 0
> > real_magic:.long 0
> > video_mode:.long 0
> > -video_flags: .long 0
> > +realmode_flags:.long 0
> > beep_flags:.long 0
> > real_efer_save_restore:.long 0
> > real_save_efer_edx:.long 0
>
> Beep_flags should be removed too if you're sticking with /proc.
Fixed.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
On Thu, 5 Jul 2007, Pavel Machek wrote: > > Actually here's one that does not immediately oops when I plug USB > keyboard in. Why do you use a delayed workqueue and then always use it without a delay? That seems silly. Linus - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi!
> > Here's the version that uses just one variable, relative to Nigel's
> > patch. Hmm, and it also closes nasty trap for the user in
> > acpi_sleep_setup; order of parameters actually mattered there,
> > acpi_sleep=s3_bios,s3_mode doing something different from
> > acpi_sleep=s3_mode,s3_bios . It actually works here.
> >
> > Will you fold it into patch28, or should I create a changelog?
>
> Hmm, I think we should keep the record straight. Please add a changelog
> if that's not a problem.
(I also added documentation and removed the superfluous beep_flags).
---
Move "debug during resume from s2ram" into the variable we already use
for real-mode flags to simplify code. It also closes nasty trap for
the user in acpi_sleep_setup; order of parameters actually mattered there,
acpi_sleep=s3_bios,s3_mode doing something different from
acpi_sleep=s3_mode,s3_bios.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
index 4ee8357..5b67866 100644
--- a/arch/i386/kernel/acpi/sleep.c
+++ b/arch/i386/kernel/acpi/sleep.c
@@ -14,7 +14,7 @@ #include
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
-unsigned long acpi_video_flags;
+unsigned long acpi_realmode_flags;
extern char wakeup_start, wakeup_end;
extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
@@ -68,9 +68,11 @@ static int __init acpi_sleep_setup(char
{
while ((str != NULL) && (*str != '\0')) {
if (strncmp(str, "s3_bios", 7) == 0)
- acpi_video_flags = 1;
+ acpi_realmode_flags |= 1;
if (strncmp(str, "s3_mode", 7) == 0)
- acpi_video_flags |= 2;
+ acpi_realmode_flags |= 2;
+ if (strncmp(str, "s3_beep", 7) == 0)
+ acpi_realmode_flags |= 4;
str = strchr(str, ',');
if (str != NULL)
str += strspn(str, ", \t");
@@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
__setup("acpi_sleep=", acpi_sleep_setup);
+/* Ouch, we want to delete this. We already have better version in userspace,
in
+ s2ram from suspend.sf.net project */
static __init int reset_videomode_after_s3(struct dmi_system_id *d)
{
- acpi_video_flags |= 2;
+ acpi_realmode_flags |= 2;
return 0;
}
diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
index 68e58f1..443fe85 100644
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -50,7 +50,7 @@ # BEEP
movw%ax, %ds# Make ds:0
point to wakeup_start
movw%ax, %ss
- testl $1, beep_flags - wakeup_code
+ testl $4, realmode_flags - wakeup_code
jz 1f
BEEP
1:
@@ -64,7 +64,7 @@ # BEEP
cmpl$0x12345678, %eax
jne bogus_real_magic
- testl $1, video_flags - wakeup_code
+ testl $1, realmode_flags - wakeup_code
jz 1f
lcall $0xc000,$3
movw%cs, %ax
@@ -72,7 +72,7 @@ # BEEP
movw%ax, %ss
1:
- testl $2, video_flags - wakeup_code
+ testl $2, realmode_flags - wakeup_code
jz 1f
mov video_mode - wakeup_code, %ax
callmode_set
@@ -111,11 +111,11 @@ # BEEP
cmpl$0x12345678, %eax
jne bogus_real_magic
- testl $2, beep_flags - wakeup_code
+ testl $8, realmode_flags - wakeup_code
jz 1f
BEEP
1:
- ljmpl $__KERNEL_CS,$wakeup_pmode_return
+ ljmpl $__KERNEL_CS, $wakeup_pmode_return
real_save_gdt: .word 0
.long 0
@@ -124,7 +124,7 @@ real_save_cr3: .long 0
real_save_cr4: .long 0
real_magic:.long 0
video_mode:.long 0
-video_flags: .long 0
+realmode_flags:.long 0
beep_flags:.long 0
real_efer_save_restore:.long 0
real_save_efer_edx:.long 0
@@ -288,10 +288,8 @@ ENTRY(acpi_copy_wakeup_routine)
movlsaved_videomode, %edx
movl%edx, video_mode - wakeup_start (%eax)
- movlacpi_video_flags, %edx
- movl%edx, video_flags - wakeup_start (%eax)
- movls2ram_beep, %edx
- movl%edx, beep_flags - wakeup_start (%eax)
+ movlacpi_realmode_flags, %edx
+ movl%edx, realmode_flags - wakeup_start (%eax)
movl$0x12345678, real_magic - wakeup_start (%eax)
movl$0x12345678, saved_magic
popl%ebx
diff --git a/arch/x86_64/kernel/acpi/sleep.c b/arch/x86_64/kernel/acpi/sleep.c
index 195b703..4277f2b 100644
--- a/arch/x86_64/kernel/acpi/sleep.c
+++ b/arch/x86_64/kernel/acpi/sleep.c
@@ -55,7 +55,7 @@ #ifdef CONFIG_ACPI_SLEEP
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
-unsigned long acpi_video_flags;
+unsigned long
Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND
Hi! > > > > diff --git a/drivers/char/lp.c b/drivers/char/lp.c > > > > index 62051f8..8267ff8 100644 > > > > --- a/drivers/char/lp.c > > > > +++ b/drivers/char/lp.c > > > > @@ -144,7 +144,7 @@ static unsigned int lp_count = 0; > > > > static struct class *lp_class; > > > > > > > > #ifdef CONFIG_LP_CONSOLE > > > > -static struct parport *console_registered; // initially NULL > > > > +static struct parport *console_registered; > > > > #endif /* CONFIG_LP_CONSOLE */ > > > > > > Could you please avoid fixing things like this, white space etc. in this > > > patch? > > > It would be easier to read ... > > > > Yep, sorry, it should be separate patch. I hope the idea is still > > simple enough. > > Yes, but I'm not sure if netconsole is the only one that we will want to have Well, netconsole is the only one we know of. > disabled. Moreover, what if someone wants to use the netconsole regardless > of the fact that it can crash the box? He'll have to edit the sources at that point. I'd prefer not to have too many "please crash the box" options. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi.
On Thursday 05 July 2007 07:29:07 Pavel Machek wrote:
> Here's the version that uses just one variable, relative to Nigel's
> patch. Hmm, and it also closes nasty trap for the user in
> acpi_sleep_setup; order of parameters actually mattered there,
> acpi_sleep=s3_bios,s3_mode doing something different from
> acpi_sleep=s3_mode,s3_bios . It actually works here.
Good catch.
> Will you fold it into patch28, or should I create a changelog?
> Testing welcome :-).
I really dislike the overloading of acpi video flags in this way. You yourself
have said in the past that new functionality should use /sys instead
of /proc, and here you are overloading an existing variable for the sake of
expediency. Please, stick with a new /sys/power entry.
Documentation is also an issue. Your patch should update the kernel_parameters
file so users can know how to get the beeping to happen. It would be nice if
it mentioned the proc entry too.
[...]
> @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
>
> __setup("acpi_sleep=", acpi_sleep_setup);
>
> +/* Ouch, we want to delete this. We already have better version in
userspace, in
> + s2ram from suspend.sf.net project */
Do we? This version has advantages in not requiring any userspace app and in
being able to work even if you can't yet get as far as having userspace
working. [Reads more] Oh, do you mean a better way of setting this parameter
(ie requiring the userspace app and then having it echo $VALUE
> /proc/sys/kernel/acpi_video_flags? Considering we're not going to suspend
to ram during init scripts, we have a way of setting/resetting it post-boot
with or without s2m and the flag doesn't therefore need to be command line
option, I can go with that. Does it need a patch to mark it as deprecated?
[...]
> @@ -124,7 +124,7 @@ real_save_cr3:.long 0
> real_save_cr4: .long 0
> real_magic: .long 0
> video_mode: .long 0
> -video_flags: .long 0
> +realmode_flags: .long 0
> beep_flags: .long 0
> real_efer_save_restore: .long 0
> real_save_efer_edx: .long 0
Beep_flags should be removed too if you're sticking with /proc.
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
pgp4fmq32SK4d.pgp
Description: PGP signature
Re: blink driver power saving
Hi!
> > tristate "Keyboard blink driver"
> >
> > ...drivers are not expected to act on their own. I was expecting to
> > get nice /sys/class/led* interface to my keyboard leds.
> >
> > BTW ... I still believe we should have /sys/class/led* interface to
> > those leds. I'd like to make them blink with hdd activity on some
> > machines... of course, that needs non-buggy KBC.
>
> I'll take patches. Ofcourse we'll have to keep the current EV_LED interface
> for compatibility.
Actually here's one that does not immediately oops when I plug USB
keyboard in.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 87d2046..716620c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -95,6 +95,13 @@ config LEDS_COBALT
help
This option enables support for the front LED on Cobalt Server
+config LEDS_INPUT
+ tristate "LED Support for input layer keyboards"
+ depends on LEDS_CLASS
+ help
+ This option enables support for LEDs on keyboards handled by
+ input layer.
+
comment "LED Triggers"
config LEDS_TRIGGERS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..ea58020 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -16,8 +16,10 @@ obj-$(CONFIG_LEDS_NET48XX) += leds-net4
obj-$(CONFIG_LEDS_WRAP)+= leds-wrap.o
obj-$(CONFIG_LEDS_H1940) += leds-h1940.o
obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
+obj-$(CONFIG_LEDS_INPUT) += leds-input.o
# LED Triggers
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+
diff --git a/drivers/leds/leds-input.c b/drivers/leds/leds-input.c
new file mode 100644
index 000..8caca35
--- /dev/null
+++ b/drivers/leds/leds-input.c
@@ -0,0 +1,153 @@
+/*
+ * LED <-> input subsystem glue
+ *
+ * Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
+ * Copyright 2007 Dmitry Torokhov
+ * Copyright 2005-2006 Openedhand Ltd.
+ *
+ * Author: Pavel Machek <[EMAIL PROTECTED]>
+ * Based on code by: Richard Purdie <[EMAIL PROTECTED]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+struct blinker {
+ struct delayed_work work;
+ struct input_handle handle;
+ int state;
+
+ struct led_classdev dev;
+};
+
+struct blinker *blinker;
+
+static void inputled_set(struct led_classdev *led_cdev, enum led_brightness
value)
+{
+ struct blinker *blinker = container_of(led_cdev, struct blinker, dev);
+ blinker->state = value;
+ schedule_delayed_work(>work, 0);
+}
+
+static void blink_task_handler(struct work_struct *work)
+{
+ struct blinker *blinker = container_of(work, struct blinker, work.work);
+ printk("Setting led to %d\n", blinker->state);
+ input_inject_event(>handle, EV_LED, LED_CAPSL,
!!blinker->state);
+}
+
+static void blink_event(struct input_handle *handle, unsigned int type,
+ unsigned int code, int down)
+{
+ /*
+* This is a very rare handler that does not process any input
+* events; just injects them.
+*/
+}
+
+static int blink_connect(struct input_handler *handler, struct input_dev *dev,
+ const struct input_device_id *id)
+{
+ struct input_handle *handle;
+ struct led_classdev *led_dev;
+ static int counter;
+ int error;
+
+ blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
+ if (!blinker) {
+ return -ENOMEM;
+ }
+
+ INIT_DELAYED_WORK(>work, blink_task_handler);
+
+ led_dev = >dev;
+ led_dev->name = kmalloc(10, GFP_KERNEL);
+ sprintf(led_dev->name, "input%d", counter++);
+ led_dev->brightness_set = inputled_set;
+
+ handle = >handle;
+ handle->dev = dev;
+ handle->handler = handler;
+ handle->name = "blink";
+ handle->private = blinker;
+
+ error = input_register_handle(handle);
+ if (error)
+ goto err_free_handle;
+
+ error = input_open_device(handle);
+ if (error)
+ goto err_unregister_handle;
+
+ error = led_classdev_register(NULL, led_dev);
+ if (error < 0)
+ goto err_input_close_device;
+
+ return 0;
+
+ err_input_close_device:
+ input_close_device(handle);
+ err_unregister_handle:
+ input_unregister_handle(handle);
+ err_free_handle:
+ kfree(handle);
+ return error;
+}
+
+static void blink_disconnect(struct input_handle *handle)
+{
+ struct blinker *blinker = handle->private;
+
+
[-mm PATCH 6/7] Memory controller add per container LRU and reclaim
Add the meta_page to the per container LRU. The reclaim algorithm has been
modified to make the isolate_lru_pages() as a pluggable component. The
scan_control data structure now accepts the container on behalf of which
reclaims are carried out. try_to_free_pages() has been extended to become
container aware.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
include/linux/memcontrol.h | 11 +++
include/linux/res_counter.h | 23 +++
include/linux/swap.h|3 +
mm/memcontrol.c | 88 +-
mm/swap.c |2
mm/vmscan.c | 129 +++-
6 files changed, 230 insertions(+), 26 deletions(-)
diff -puN include/linux/memcontrol.h~mem-control-lru-and-reclaim
include/linux/memcontrol.h
--- linux-2.6.22-rc6/include/linux/memcontrol.h~mem-control-lru-and-reclaim
2007-07-04 15:05:31.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/memcontrol.h 2007-07-04
15:05:31.0 -0700
@@ -26,6 +26,13 @@ extern void page_assign_meta_page(struct
extern struct meta_page *page_get_meta_page(struct page *page);
extern int mem_container_charge(struct page *page, struct mm_struct *mm);
extern void mem_container_uncharge(struct meta_page *mp);
+extern void mem_container_move_lists(struct meta_page *mp, bool active);
+extern unsigned long mem_container_isolate_pages(unsigned long nr_to_scan,
+ struct list_head *dst,
+ unsigned long *scanned, int order,
+ int mode, struct zone *z,
+ struct mem_container *mem_cont,
+ int active);
#else /* CONFIG_CONTAINER_MEM_CONT */
static inline void mm_init_container(struct mm_struct *mm,
@@ -56,6 +63,10 @@ static inline void mem_container_uncharg
{
}
+static inline void mem_container_move_lists(struct meta_page *mp, bool active)
+{
+}
+
#endif /* CONFIG_CONTAINER_MEM_CONT */
#endif /* _LINUX_MEMCONTROL_H */
diff -puN include/linux/swap.h~mem-control-lru-and-reclaim include/linux/swap.h
--- linux-2.6.22-rc6/include/linux/swap.h~mem-control-lru-and-reclaim
2007-07-04 15:05:31.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/swap.h2007-07-04
15:05:31.0 -0700
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -191,6 +192,8 @@ extern void swap_setup(void);
/* linux/mm/vmscan.c */
extern unsigned long try_to_free_pages(struct zone **zones, int order,
gfp_t gfp_mask);
+extern unsigned long try_to_free_mem_container_pages(struct mem_container
*mem);
+extern int __isolate_lru_page(struct page *page, int mode);
extern unsigned long shrink_all_memory(unsigned long nr_pages);
extern int vm_swappiness;
extern int remove_mapping(struct address_space *mapping, struct page *page);
diff -puN mm/memcontrol.c~mem-control-lru-and-reclaim mm/memcontrol.c
--- linux-2.6.22-rc6/mm/memcontrol.c~mem-control-lru-and-reclaim
2007-07-04 15:05:31.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memcontrol.c 2007-07-04 15:05:31.0
-0700
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
struct container_subsys mem_container_subsys;
@@ -103,6 +105,71 @@ void __always_inline unlock_meta_page(st
bit_spin_unlock(PG_metapage, >flags);
}
+unsigned long mem_container_isolate_pages(unsigned long nr_to_scan,
+ struct list_head *dst,
+ unsigned long *scanned, int order,
+ int mode, struct zone *z,
+ struct mem_container *mem_cont,
+ int active)
+{
+ unsigned long nr_taken = 0;
+ struct page *page;
+ unsigned long scan;
+ LIST_HEAD(mp_list);
+ struct list_head *src;
+ struct meta_page *mp;
+
+ if (active)
+ src = _cont->active_list;
+ else
+ src = _cont->inactive_list;
+
+ for (scan = 0; scan < nr_to_scan && !list_empty(src); scan++) {
+ mp = list_entry(src->prev, struct meta_page, list);
+ page = mp->page;
+
+ if (PageActive(page) && !active) {
+ mem_container_move_lists(mp, true);
+ scan--;
+ continue;
+ }
+ if (!PageActive(page) && active) {
+ mem_container_move_lists(mp, false);
+ scan--;
+ continue;
+ }
+
+ /*
+* Reclaim, per zone
+* TODO: make the active/inactive lists per zone
+*/
+ if (page_zone(page) != z)
+ continue;
+
+
[-mm PATCH 7/7] Memory controller OOM handling
Out of memory handling for containers over their limit. A task from the
container over limit is chosen using the existing OOM logic and killed.
TODO:
1. As discussed in the OLS BOF session, consider implementing a user
space policy for OOM handling.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
include/linux/memcontrol.h |1 +
mm/memcontrol.c|1 +
mm/oom_kill.c | 42 ++
3 files changed, 40 insertions(+), 4 deletions(-)
diff -puN include/linux/memcontrol.h~mem-control-out-of-memory
include/linux/memcontrol.h
--- linux-2.6.22-rc6/include/linux/memcontrol.h~mem-control-out-of-memory
2007-07-04 15:05:34.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/memcontrol.h 2007-07-04
15:05:34.0 -0700
@@ -33,6 +33,7 @@ extern unsigned long mem_container_isola
int mode, struct zone *z,
struct mem_container *mem_cont,
int active);
+extern void mem_cont_out_of_memory(struct mem_container *mem);
#else /* CONFIG_CONTAINER_MEM_CONT */
static inline void mm_init_container(struct mm_struct *mm,
diff -puN mm/memcontrol.c~mem-control-out-of-memory mm/memcontrol.c
--- linux-2.6.22-rc6/mm/memcontrol.c~mem-control-out-of-memory 2007-07-04
15:05:34.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memcontrol.c 2007-07-04 15:05:34.0
-0700
@@ -240,6 +240,7 @@ int mem_container_charge(struct page *pa
if (res_counter_check_under_limit(>res))
continue;
+ mem_cont_out_of_memory(mem);
goto free_mp;
}
diff -puN mm/oom_kill.c~mem-control-out-of-memory mm/oom_kill.c
--- linux-2.6.22-rc6/mm/oom_kill.c~mem-control-out-of-memory2007-07-04
15:05:34.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/oom_kill.c 2007-07-04 15:05:34.0
-0700
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
int sysctl_panic_on_oom;
/* #define DEBUG */
@@ -47,7 +48,8 @@ int sysctl_panic_on_oom;
*of least surprise ... (be careful when you change it)
*/
-unsigned long badness(struct task_struct *p, unsigned long uptime)
+unsigned long badness(struct task_struct *p, unsigned long uptime,
+ struct mem_container *mem)
{
unsigned long points, cpu_time, run_time, s;
struct mm_struct *mm;
@@ -60,6 +62,13 @@ unsigned long badness(struct task_struct
return 0;
}
+#ifdef CONFIG_CONTAINER_MEM_CONT
+ if (mem != NULL && mm->mem_container != mem) {
+ task_unlock(p);
+ return 0;
+ }
+#endif
+
/*
* The memory size of the process is the basis for the badness.
*/
@@ -204,7 +213,8 @@ static inline int constrained_alloc(stru
*
* (not docbooked, we don't want this one cluttering up the manual)
*/
-static struct task_struct *select_bad_process(unsigned long *ppoints)
+static struct task_struct *select_bad_process(unsigned long *ppoints,
+ struct mem_container *mem)
{
struct task_struct *g, *p;
struct task_struct *chosen = NULL;
@@ -258,7 +268,7 @@ static struct task_struct *select_bad_pr
if (p->oomkilladj == OOM_DISABLE)
continue;
- points = badness(p, uptime.tv_sec);
+ points = badness(p, uptime.tv_sec, mem);
if (points > *ppoints || !chosen) {
chosen = p;
*ppoints = points;
@@ -372,6 +382,30 @@ static int oom_kill_process(struct task_
return oom_kill_task(p);
}
+#ifdef CONFIG_CONTAINER_MEM_CONT
+void mem_cont_out_of_memory(struct mem_container *mem)
+{
+ unsigned long points = 0;
+ struct task_struct *p;
+
+ container_lock();
+ rcu_read_lock();
+retry:
+ p = select_bad_process(, mem);
+ if (PTR_ERR(p) == -1UL)
+ goto out;
+
+ if (!p)
+ p = current;
+
+ if (oom_kill_process(p, points, "Memory container out of memory"))
+ goto retry;
+out:
+ rcu_read_unlock();
+ container_unlock();
+}
+#endif
+
static BLOCKING_NOTIFIER_HEAD(oom_notify_list);
int register_oom_notifier(struct notifier_block *nb)
@@ -444,7 +478,7 @@ retry:
* Rambo mode: Shoot down a process and hope it solves whatever
* issues we may have.
*/
- p = select_bad_process();
+ p = select_bad_process(, NULL);
if (PTR_ERR(p) == -1UL)
goto out;
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[-mm PATCH 5/7] Memory controller task migration
Allow tasks to migrate from one container to the other. We migrate
mm_struct's mem_container only when the thread group id migrates.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
mm/memcontrol.c | 35 +++
1 file changed, 35 insertions(+)
diff -puN mm/memcontrol.c~mem-control-task-migration mm/memcontrol.c
--- linux-2.6.22-rc6/mm/memcontrol.c~mem-control-task-migration 2007-07-04
15:05:29.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memcontrol.c 2007-07-04 15:05:29.0
-0700
@@ -302,11 +302,46 @@ err:
return rc;
}
+static void mem_container_move_task(struct container_subsys *ss,
+ struct container *cont,
+ struct container *old_cont,
+ struct task_struct *p)
+{
+ struct mm_struct *mm;
+ struct mem_container *mem, *old_mem;
+
+ mm = get_task_mm(p);
+ if (mm == NULL)
+ return;
+
+ mem = mem_container_from_cont(cont);
+ old_mem = mem_container_from_cont(old_cont);
+
+ if (mem == old_mem)
+ goto out;
+
+ /*
+* Only thread group leaders are allowed to migrate, the mm_struct is
+* in effect owned by the leader
+*/
+ if (p->tgid != p->pid)
+ goto out;
+
+ css_get(>css);
+ rcu_assign_pointer(mm->mem_container, mem);
+ css_put(_mem->css);
+
+out:
+ mmput(mm);
+ return;
+}
+
struct container_subsys mem_container_subsys = {
.name = "mem_container",
.subsys_id = mem_container_subsys_id,
.create = mem_container_create,
.destroy = mem_container_destroy,
.populate = mem_container_populate,
+ .attach = mem_container_move_task,
.early_init = 1,
};
_
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm PATCH 3/7] Memory controller accounting setup
Basic setup routines, the mm_struct has a pointer to the container that
it belongs to and the the page has a meta_page associated with it.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
include/linux/memcontrol.h | 32 ++
include/linux/mm_types.h |4 +++
include/linux/sched.h |4 +++
kernel/fork.c | 10 ++---
mm/memcontrol.c| 47 ++---
5 files changed, 91 insertions(+), 6 deletions(-)
diff -puN include/linux/memcontrol.h~mem-control-accounting-setup
include/linux/memcontrol.h
--- linux-2.6.22-rc6/include/linux/memcontrol.h~mem-control-accounting-setup
2007-07-04 15:05:24.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/memcontrol.h 2007-07-04
15:05:24.0 -0700
@@ -15,5 +15,37 @@
#ifndef _LINUX_MEMCONTROL_H
#define _LINUX_MEMCONTROL_H
+struct mem_container;
+struct meta_page;
+
+#ifdef CONFIG_CONTAINER_MEM_CONT
+
+extern void mm_init_container(struct mm_struct *mm, struct task_struct *p);
+extern void mm_free_container(struct mm_struct *mm);
+extern void page_assign_meta_page(struct page *page, struct meta_page *mp);
+extern struct meta_page *page_get_meta_page(struct page *page);
+
+#else /* CONFIG_CONTAINER_MEM_CONT */
+static inline void mm_init_container(struct mm_struct *mm,
+ struct task_struct *p)
+{
+}
+
+static inline void mm_free_container(struct mm_struct *mm)
+{
+}
+
+static inline void page_assign_meta_page(struct page *page,
+ struct meta_page *mp)
+{
+}
+
+static inline struct meta_page *page_get_meta_page(struct page *page)
+{
+ return NULL;
+}
+
+#endif /* CONFIG_CONTAINER_MEM_CONT */
+
#endif /* _LINUX_MEMCONTROL_H */
diff -puN include/linux/mm_types.h~mem-control-accounting-setup
include/linux/mm_types.h
--- linux-2.6.22-rc6/include/linux/mm_types.h~mem-control-accounting-setup
2007-07-04 15:05:24.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/mm_types.h2007-07-04
15:05:24.0 -0700
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
struct address_space;
@@ -83,6 +84,9 @@ struct page {
unsigned int gfp_mask;
unsigned long trace[8];
#endif
+#ifdef CONFIG_CONTAINER_MEM_CONT
+ struct meta_page *meta_page;
+#endif
};
#endif /* _LINUX_MM_TYPES_H */
diff -puN include/linux/sched.h~mem-control-accounting-setup
include/linux/sched.h
--- linux-2.6.22-rc6/include/linux/sched.h~mem-control-accounting-setup
2007-07-04 15:05:24.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/sched.h 2007-07-04
15:05:24.0 -0700
@@ -87,6 +87,7 @@ struct sched_param {
#include
#include
#include
+#include
#include
@@ -416,6 +417,9 @@ struct mm_struct {
/* aio bits */
rwlock_tioctx_list_lock;
struct kioctx *ioctx_list;
+#ifdef CONFIG_CONTAINER_MEM_CONT
+ struct mem_container *mem_container;
+#endif
};
struct sighand_struct {
diff -puN kernel/fork.c~mem-control-accounting-setup kernel/fork.c
--- linux-2.6.22-rc6/kernel/fork.c~mem-control-accounting-setup 2007-07-04
15:05:24.0 -0700
+++ linux-2.6.22-rc6-balbir/kernel/fork.c 2007-07-04 15:05:24.0
-0700
@@ -330,7 +330,7 @@ static inline void mm_free_pgd(struct mm
#include
-static struct mm_struct * mm_init(struct mm_struct * mm)
+static struct mm_struct * mm_init(struct mm_struct * mm, struct task_struct *p)
{
atomic_set(>mm_users, 1);
atomic_set(>mm_count, 1);
@@ -347,11 +347,14 @@ static struct mm_struct * mm_init(struct
mm->ioctx_list = NULL;
mm->free_area_cache = TASK_UNMAPPED_BASE;
mm->cached_hole_size = ~0UL;
+ mm_init_container(mm, p);
if (likely(!mm_alloc_pgd(mm))) {
mm->def_flags = 0;
return mm;
}
+
+ mm_free_container(mm);
free_mm(mm);
return NULL;
}
@@ -366,7 +369,7 @@ struct mm_struct * mm_alloc(void)
mm = allocate_mm();
if (mm) {
memset(mm, 0, sizeof(*mm));
- mm = mm_init(mm);
+ mm = mm_init(mm, current);
}
return mm;
}
@@ -380,6 +383,7 @@ void fastcall __mmdrop(struct mm_struct
{
BUG_ON(mm == _mm);
mm_free_pgd(mm);
+ mm_free_container(mm);
destroy_context(mm);
free_mm(mm);
}
@@ -500,7 +504,7 @@ static struct mm_struct *dup_mm(struct t
mm->token_priority = 0;
mm->last_interval = 0;
- if (!mm_init(mm))
+ if (!mm_init(mm, tsk))
goto fail_nomem;
if (init_new_context(tsk, mm))
diff -puN mm/memcontrol.c~mem-control-accounting-setup mm/memcontrol.c
--- linux-2.6.22-rc6/mm/memcontrol.c~mem-control-accounting-setup
2007-07-04 15:05:24.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memcontrol.c 2007-07-04 15:05:24.0
-0700
[-mm PATCH 4/7] Memory controller memory accounting
Add the accounting hooks. The accounting is carried out for RSS and Page
Cache (unmapped) pages. There is now a common limit and accounting for both.
The RSS accounting is accounted at page_add_*_rmap() and page_remove_rmap()
time. Page cache is accounted at add_to_page_cache(),
__delete_from_page_cache(). Swap cache is also accounted for.
Each page's meta_page is protected with a bit in page flags, this makes
handling of race conditions involving simultaneous mappings of a page easier.
A reference count is kept in the meta_page to deal with cases where a page
might be unmapped from the RSS of all tasks, but still lives in the page
cache.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
fs/exec.c |1
include/linux/memcontrol.h | 11 +++
include/linux/page-flags.h |3 +
mm/filemap.c |8 ++
mm/memcontrol.c| 132 -
mm/memory.c| 22 +++
mm/migrate.c |6 ++
mm/page_alloc.c|3 +
mm/rmap.c |2
mm/swap_state.c|8 ++
mm/swapfile.c | 40 +++--
11 files changed, 218 insertions(+), 18 deletions(-)
diff -puN fs/exec.c~mem-control-accounting fs/exec.c
--- linux-2.6.22-rc6/fs/exec.c~mem-control-accounting 2007-07-04
15:05:27.0 -0700
+++ linux-2.6.22-rc6-balbir/fs/exec.c 2007-07-04 15:05:27.0 -0700
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
diff -puN include/linux/memcontrol.h~mem-control-accounting
include/linux/memcontrol.h
--- linux-2.6.22-rc6/include/linux/memcontrol.h~mem-control-accounting
2007-07-04 15:05:27.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/memcontrol.h 2007-07-04
15:05:27.0 -0700
@@ -24,6 +24,8 @@ extern void mm_init_container(struct mm_
extern void mm_free_container(struct mm_struct *mm);
extern void page_assign_meta_page(struct page *page, struct meta_page *mp);
extern struct meta_page *page_get_meta_page(struct page *page);
+extern int mem_container_charge(struct page *page, struct mm_struct *mm);
+extern void mem_container_uncharge(struct meta_page *mp);
#else /* CONFIG_CONTAINER_MEM_CONT */
static inline void mm_init_container(struct mm_struct *mm,
@@ -45,6 +47,15 @@ static inline struct meta_page *page_get
return NULL;
}
+static inline int mem_container_charge(struct page *page, struct mm_struct *mm)
+{
+ return 0;
+}
+
+static inline void mem_container_uncharge(struct meta_page *mp)
+{
+}
+
#endif /* CONFIG_CONTAINER_MEM_CONT */
#endif /* _LINUX_MEMCONTROL_H */
diff -puN include/linux/page-flags.h~mem-control-accounting
include/linux/page-flags.h
--- linux-2.6.22-rc6/include/linux/page-flags.h~mem-control-accounting
2007-07-04 15:05:27.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/page-flags.h 2007-07-04
15:05:27.0 -0700
@@ -98,6 +98,9 @@
#define PG_checked PG_owner_priv_1 /* Used by some filesystems */
#define PG_pinned PG_owner_priv_1 /* Xen pinned pagetable */
+#define PG_metapage21 /* Used for checking if a meta_page */
+ /* is associated with a page*/
+
#if (BITS_PER_LONG > 32)
/*
* 64-bit-only flags build down from bit 31
diff -puN mm/filemap.c~mem-control-accounting mm/filemap.c
--- linux-2.6.22-rc6/mm/filemap.c~mem-control-accounting2007-07-04
15:05:27.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/filemap.c2007-07-04 15:05:27.0
-0700
@@ -31,6 +31,7 @@
#include
#include
#include /* for BUG_ON(!in_atomic()) only */
+#include
#include "internal.h"
/*
@@ -116,6 +117,7 @@ void __remove_from_page_cache(struct pag
{
struct address_space *mapping = page->mapping;
+ mem_container_uncharge(page_get_meta_page(page));
radix_tree_delete(>page_tree, page->index);
page->mapping = NULL;
mapping->nrpages--;
@@ -442,6 +444,11 @@ int add_to_page_cache(struct page *page,
int error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
if (error == 0) {
+
+ error = mem_container_charge(page, current->mm);
+ if (error)
+ goto out;
+
write_lock_irq(>tree_lock);
error = radix_tree_insert(>page_tree, offset, page);
if (!error) {
@@ -455,6 +462,7 @@ int add_to_page_cache(struct page *page,
write_unlock_irq(>tree_lock);
radix_tree_preload_end();
}
+out:
return error;
}
EXPORT_SYMBOL(add_to_page_cache);
diff -puN mm/memcontrol.c~mem-control-accounting mm/memcontrol.c
--- linux-2.6.22-rc6/mm/memcontrol.c~mem-control-accounting 2007-07-04
15:05:27.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memcontrol.c 2007-07-04 15:05:27.0
-0700
@@ -16,6 +16,9 @@
#include
#include
#include
+#include
+#include
[-mm PATCH 2/7] Memory controller containers setup
Setup the memory container and add basic hooks and controls to integrate
and work with the container.
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
include/linux/container_subsys.h |6 +
include/linux/memcontrol.h | 19 +
init/Kconfig |8 ++
mm/Makefile |1
mm/memcontrol.c | 141 +++
5 files changed, 175 insertions(+)
diff -puN include/linux/container_subsys.h~mem-control-setup
include/linux/container_subsys.h
--- linux-2.6.22-rc6/include/linux/container_subsys.h~mem-control-setup
2007-07-04 15:05:22.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/container_subsys.h2007-07-04
15:05:22.0 -0700
@@ -30,3 +30,9 @@ SUBSYS(ns)
#endif
/* */
+
+#ifdef CONFIG_CONTAINER_MEM_CONT
+SUBSYS(mem_container)
+#endif
+
+/* */
diff -puN init/Kconfig~mem-control-setup init/Kconfig
--- linux-2.6.22-rc6/init/Kconfig~mem-control-setup 2007-07-04
15:05:22.0 -0700
+++ linux-2.6.22-rc6-balbir/init/Kconfig2007-07-04 15:05:22.0
-0700
@@ -360,6 +360,14 @@ config CONTAINER_NS
for instance virtual servers and checkpoint/restart
jobs.
+config CONTAINER_MEM_CONT
+ bool "Memory controller for containers"
+ select CONTAINERS
+ select RESOURCE_COUNTERS
+ help
+ Provides a memory controller that manages both page cache and
+ RSS memory.
+
config PROC_PID_CPUSET
bool "Include legacy /proc//cpuset file"
depends on CPUSETS
diff -puN mm/Makefile~mem-control-setup mm/Makefile
--- linux-2.6.22-rc6/mm/Makefile~mem-control-setup 2007-07-04
15:05:22.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/Makefile 2007-07-04 15:05:22.0 -0700
@@ -30,4 +30,5 @@ obj-$(CONFIG_FS_XIP) += filemap_xip.o
obj-$(CONFIG_MIGRATION) += migrate.o
obj-$(CONFIG_SMP) += allocpercpu.o
obj-$(CONFIG_QUICKLIST) += quicklist.o
+obj-$(CONFIG_CONTAINER_MEM_CONT) += memcontrol.o
diff -puN /dev/null mm/memcontrol.c
--- /dev/null 2007-06-01 08:12:04.0 -0700
+++ linux-2.6.22-rc6-balbir/mm/memcontrol.c 2007-07-04 15:05:22.0
-0700
@@ -0,0 +1,141 @@
+/* memcontrol.c - Memory Controller
+ *
+ * Copyright IBM Corporation, 2007
+ * Author Balbir Singh <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include
+#include
+#include
+
+struct container_subsys mem_container_subsys;
+
+/*
+ * The memory controller data structure. The memory controller controls both
+ * page cache and RSS per container. We would eventually like to provide
+ * statistics based on the statistics developed by Rik Van Riel for clock-pro,
+ * to help the administrator determine what knobs to tune.
+ *
+ * TODO: Add a water mark for the memory controller. Reclaim will begin when
+ * we hit the water mark.
+ */
+struct mem_container {
+ struct container_subsys_state css;
+ /*
+* the counter to account for memory usage
+*/
+ struct res_counter res;
+};
+
+/*
+ * A meta page is associated with every page descriptor. The meta page
+ * helps us identify information about the container
+ */
+struct meta_page {
+ struct list_head list; /* per container LRU list */
+ struct page *page;
+ struct mem_container *mem_container;
+};
+
+
+static inline struct mem_container *mem_container_from_cont(struct container
+ *cnt)
+{
+ return container_of(container_subsys_state(cnt,
+ mem_container_subsys_id), struct mem_container,
+ css);
+}
+
+static ssize_t mem_container_read(struct container *cont, struct cftype *cft,
+ struct file *file, char __user *userbuf, size_t nbytes,
+ loff_t *ppos)
+{
+ return res_counter_read(_container_from_cont(cont)->res,
+ cft->private, userbuf, nbytes, ppos);
+}
+
+static ssize_t mem_container_write(struct container *cont, struct cftype *cft,
+ struct file *file, const char __user *userbuf,
+ size_t nbytes, loff_t *ppos)
+{
+ return res_counter_write(_container_from_cont(cont)->res,
+ cft->private, userbuf, nbytes, ppos);
+}
+
+static struct cftype mem_container_usage = {
+ .name = "mem_usage",
+ .private = RES_USAGE,
+ .read = mem_container_read,
+};
+
+static struct cftype mem_container_limit = {
+ .name = "mem_limit",
+ .private =
[-mm PATCH 0/7] Memory controller introduction
Resending with the patch numbering fixed and linux-mm copied This patchset implements another version of the memory controller. These patches have been through a big churn, the first set of patches were posted last year and earlier this year at http://lkml.org/lkml/2007/2/19/10 Ever since, the RSS controller has been through four revisions, the latest one being http://lwn.net/Articles/236817/ This patchset draws from the patches listed above and from some of the contents of the patches posted by Vaidyanathan for page cache control. http://lkml.org/lkml/2007/6/20/92 Pavel, Vaidy could you look at the patches and add your signed off by where relevant? At OLS, the resource management BOF, it was discussed that we need to manage RSS and unmapped page cache together. This patchset is a step towards that TODO's 1. Add memory controller water mark support. Reclaim on high water mark 2. Add support for shrinking on limit change 3. Add per zone per container LRU lists 4. Make page_referenced() container aware 5. Figure out a better CLUI for the controller In case you have been using/testing the RSS controller, you'll find that this controller works slower than the RSS controller. The reason being that both swap cache and page cache is accounted for, so pages do go out to swap upon reclaim (they cannot live in the swap cache). I've test compiled the framework without the controller enabled, tested the code on UML and minimally on a power box. Any test output, feedback, comments, suggestions are welcome! series res_counters_infra.patch mem-control-setup.patch mem-control-accounting-setup.patch mem-control-accounting.patch mem-control-task-migration.patch mem-control-lru-and-reclaim.patch mem-control-out-of-memory.patch -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm PATCH 1/7] Memory controller resource counters
Introduce generic structures and routines for resource accounting.
Each resource accounting container is supposed to aggregate it,
container_subsystem_state and its resource-specific members within.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
---
include/linux/res_counter.h | 102 +
init/Kconfig|4 +
kernel/Makefile |1
kernel/res_counter.c| 121
4 files changed, 228 insertions(+)
diff -puN /dev/null include/linux/res_counter.h
--- /dev/null 2007-06-01 08:12:04.0 -0700
+++ linux-2.6.22-rc6-balbir/include/linux/res_counter.h 2007-07-04
15:05:19.0 -0700
@@ -0,0 +1,102 @@
+#ifndef __RES_COUNTER_H__
+#define __RES_COUNTER_H__
+
+/*
+ * resource counters
+ * contain common data types and routines for resource accounting
+ *
+ * Copyright 2007 OpenVZ SWsoft Inc
+ *
+ * Author: Pavel Emelianov <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+
+/*
+ * the core object. the container that wishes to account for some
+ * resource may include this counter into its structures and use
+ * the helpers described beyond
+ */
+
+struct res_counter {
+ /*
+* the current resource consumption level
+*/
+ unsigned long usage;
+ /*
+* the limit that usage cannot exceed
+*/
+ unsigned long limit;
+ /*
+* the number of insuccessful attempts to consume the resource
+*/
+ unsigned long failcnt;
+ /*
+* the lock to protect all of the above.
+* the routines below consider this to be IRQ-safe
+*/
+ spinlock_t lock;
+};
+
+/*
+ * helpers to interact with userspace
+ * res_counter_read/_write - put/get the specified fields from the
+ * res_counter struct to/from the user
+ *
+ * @cnt: the counter in question
+ * @member: the field to work with (see RES_xxx below)
+ * @buf: the buffer to opeate on,...
+ * @nbytes: its size...
+ * @pos: and the offset.
+ */
+
+ssize_t res_counter_read(struct res_counter *cnt, int member,
+ const char __user *buf, size_t nbytes, loff_t *pos);
+ssize_t res_counter_write(struct res_counter *cnt, int member,
+ const char __user *buf, size_t nbytes, loff_t *pos);
+
+/*
+ * the field descriptors. one for each member of res_counter
+ */
+
+enum {
+ RES_USAGE,
+ RES_LIMIT,
+ RES_FAILCNT,
+};
+
+/*
+ * helpers for accounting
+ */
+
+void res_counter_init(struct res_counter *cnt);
+
+/*
+ * charge - try to consume more resource.
+ *
+ * @cnt: the counter
+ * @val: the amount of the resource. each controller defines its own
+ * units, e.g. numbers, bytes, Kbytes, etc
+ *
+ * returns 0 on success and <0 if the cnt->usage will exceed the cnt->limit
+ * _locked call expects the cnt->lock to be taken
+ */
+
+int res_counter_charge_locked(struct res_counter *cnt, unsigned long val);
+int res_counter_charge(struct res_counter *cnt, unsigned long val);
+
+/*
+ * uncharge - tell that some portion of the resource is released
+ *
+ * @cnt: the counter
+ * @val: the amount of the resource
+ *
+ * these calls check for usage underflow and show a warning on the console
+ * _locked call expects the cnt->lock to be taken
+ */
+
+void res_counter_uncharge_locked(struct res_counter *cnt, unsigned long val);
+void res_counter_uncharge(struct res_counter *cnt, unsigned long val);
+
+#endif
diff -puN init/Kconfig~res_counters_infra init/Kconfig
--- linux-2.6.22-rc6/init/Kconfig~res_counters_infra2007-07-04
15:05:19.0 -0700
+++ linux-2.6.22-rc6-balbir/init/Kconfig2007-07-04 15:05:19.0
-0700
@@ -320,6 +320,10 @@ config CPUSETS
Say N if unsure.
+config RESOURCE_COUNTERS
+ bool
+ select CONTAINERS
+
config SYSFS_DEPRECATED
bool "Create deprecated sysfs files"
default y
diff -puN kernel/Makefile~res_counters_infra kernel/Makefile
--- linux-2.6.22-rc6/kernel/Makefile~res_counters_infra 2007-07-04
15:05:19.0 -0700
+++ linux-2.6.22-rc6-balbir/kernel/Makefile 2007-07-04 15:05:19.0
-0700
@@ -58,6 +58,7 @@ obj-$(CONFIG_RELAY) += relay.o
obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
+obj-$(CONFIG_RESOURCE_COUNTERS) += res_counter.o
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is
diff -puN /dev/null kernel/res_counter.c
--- /dev/null 2007-06-01 08:12:04.0 -0700
+++ linux-2.6.22-rc6-balbir/kernel/res_counter.c2007-07-04
15:05:19.0 -0700
@@ -0,0 +1,121 @@
+/*
+ * resource containers
+ *
+ * Copyright 2007 OpenVZ SWsoft Inc
+ *
+ * Author: Pavel Emelianov <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void res_counter_init(struct
The big suspend mess
On Wed, Jul 04, 2007 at 01:29:49PM +1000, Paul Mackerras wrote: > Rafael J. Wysocki writes: > > > Still, do you really think that we're ready to drop it _right_ _now_ (I'm > > referring to suspend only) and if so than on what basis (except that you > > don't like it, which falls short of being a techical argument)? > > The basis is that it (the freezer) causes more deadlocks and other > problems than it avoids, so it's a net win to remove it. You forget one important point: Regressions are much worse than normal bugs. It's not about the question whether the driver was "correct" or "buggy" - for a user the important question is whether it worked in practice, and if yes, whether it continues to work. And my impression is that every time someone touches some part of the suspend code some drivers break. During 2.6.21-rc, it wasn't unusual for users to run with one kernel into up to three distinct suspend regressions on one machine. And no, it wasn't always the same set of distinct regressions. IMHO the suspend code is currently way too much of a moving target which results in this mess. The correct order seems to be: 1. agree on what the suspend code as a whole should look like 2. implement this 3. fix ALL drivers to work at least as good as they do today 4. get it tested in -mm 5. fix all bugs people run into 6. submit it for inclusion in Linus' tree 7. quickly work on the most likely big amount of bug reports Step 1 is the most important one - evolving code is often something good, but in this case with different people trying to evolve the suspend code in different directions it simply results in a big mess. > Paul. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
Hi!
> > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > solve the "video output dead after kexec; but need visual feedback to
> > > > > the user
> > > > > while crash dumping" problem. I'm waiting for your patches.
> > > > >
> > > >
> > > > I don't don't like it ;) Unfortunately too many people end up enabling
> > >
> > > Yes that's pretty weird. I admit I hadn't expected
> > > that problem. blink is equivalent to "annoy me" and it
> > > is a mystery why so many people should willingly ask their computer to
> > > annoy them.
> >
> > tristate "Keyboard blink driver"
> >
> > ...drivers are not expected to act on their own. I was expecting to
> > get nice /sys/class/led* interface to my keyboard leds.
> >
> > BTW ... I still believe we should have /sys/class/led* interface to
> > those leds. I'd like to make them blink with hdd activity on some
> > machines... of course, that needs non-buggy KBC.
>
> I'll take patches. Ofcourse we'll have to keep the current EV_LED interface
> for compatibility.
Here's a working version. For some reason, it only works with capslock
led. (But so does your code, is that thinkpad problem?)
Andi, by making default trigger "heartbeat", you can get very nice
visual feedback :-).
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
/*
* LED <-> input subsystem glue
*
* Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
* Copyright 2007 Dmitry Torokhov
* Copyright 2005-2006 Openedhand Ltd.
*
* Author: Pavel Machek <[EMAIL PROTECTED]>
* Based on code by: Richard Purdie <[EMAIL PROTECTED]>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct blinker {
struct delayed_work work;
struct input_handle handle;
int state;
};
struct blinker *blinker;
static void inputled_set(struct led_classdev *led_cdev, enum led_brightness
value)
{
blinker->state = value;
schedule_delayed_work(>work, 0);
}
static struct led_classdev input_led = {
.name = "input",
.default_trigger= "none",
.brightness_set = inputled_set,
};
static void blink_task_handler(struct work_struct *work)
{
struct blinker *blinker = container_of(work, struct blinker, work.work);
input_inject_event(>handle, EV_LED, LED_CAPSL,
!!blinker->state);
}
static void blink_event(struct input_handle *handle, unsigned int type,
unsigned int code, int down)
{
/*
* This is a very rare handler that does not process any input
* events; just injects them.
*/
}
static int blink_connect(struct input_handler *handler, struct input_dev *dev,
const struct input_device_id *id)
{
struct input_handle *handle;
int error;
blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
if (!blinker)
return -ENOMEM;
INIT_DELAYED_WORK(>work, blink_task_handler);
handle = >handle;
handle->dev = dev;
handle->handler = handler;
handle->name = "blink";
handle->private = blinker;
error = input_register_handle(handle);
if (error)
goto err_free_handle;
error = input_open_device(handle);
if (error)
goto err_unregister_handle;
error = led_classdev_register(NULL, _led);
if (error < 0)
goto err_input_close_device;
return 0;
err_input_close_device:
input_close_device(handle);
err_unregister_handle:
input_unregister_handle(handle);
err_free_handle:
kfree(handle);
return error;
}
static void blink_disconnect(struct input_handle *handle)
{
struct blinker *blinker = handle->private;
led_classdev_unregister(_led);
cancel_rearming_delayed_work(>work);
input_close_device(handle);
input_unregister_handle(handle);
kfree(blinker);
}
static const struct input_device_id blink_ids[] = {
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_LEDBIT,
.evbit = { BIT(EV_LED) },
.ledbit = { [LONG(LED_CAPSL)] = BIT(LED_CAPSL) },
},
{ }
};
static struct input_handler blink_handler = {
.event = blink_event,
.connect= blink_connect,
.disconnect = blink_disconnect,
.name = "blink",
.id_table = blink_ids,
};
static int __init blink_handler_init(void)
{
return input_register_handler(_handler);
}
static void __exit blink_handler_exit(void)
{
input_unregister_handler(_handler);
flush_scheduled_work();
}
Re: blink driver power saving
On Tue 2007-07-03 01:42:35, Dmitry Torokhov wrote: > On Monday 02 July 2007 19:08, Pavel Machek wrote: > > On Mon 2007-07-02 14:39:27, Andi Kleen wrote: > > > > > > > > Perhaps one of you geniuses who all hate it can find a better way to > > > > > solve the "video output dead after kexec; but need visual feedback to > > > > > the user > > > > > while crash dumping" problem. I'm waiting for your patches. > > > > > > > > > > > > > I don't don't like it ;) Unfortunately too many people end up enabling > > > > > > Yes that's pretty weird. I admit I hadn't expected > > > that problem. blink is equivalent to "annoy me" and it > > > is a mystery why so many people should willingly ask their computer to > > > annoy them. > > > > tristate "Keyboard blink driver" > > > > ...drivers are not expected to act on their own. I was expecting to > > get nice /sys/class/led* interface to my keyboard leds. > > > > BTW ... I still believe we should have /sys/class/led* interface to > > those leds. I'd like to make them blink with hdd activity on some > > machines... of course, that needs non-buggy KBC. > > I'll take patches. Ofcourse we'll have to keep the current EV_LED interface > for compatibility. Update.. both your and mine code seem to do something here -- but they only keep turning the led off. If I press numlock to turn it on, they will turn it off. Strange. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness
On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote: > You could easily replace the cookie with a pointer to a free > page pool. It just occurred to me that something like this is *required* to get the performance benefit from MAP_NOZERO on a busy system. With Davide's current proposal, if there are N jobs with different "nozero cookies" busy allocating and deallocating pages on a single-NUMA-node system, then there's only a 1/N chance that the page returned by __alloc_pages will have the correct cookie, so (N-1)/N percent of the time MAP_NOZERO will have no positive effect -- 90% of the time for the case of N=10. (Of course on NUMA systems node affinity will probably make the situation a bit better.) So I'm afraid that it sounds like additional complexity would be required so that __alloc_pages could track and preferentially return pages with the correct "nozero cookie". In a mostly unrelated complaint, I note that having a function named "alloc_zeroed_page_vma" which returns a potentially nonzero page is, um, unintuitive. It needs a name which does not claim it returns zeroed pages. I'm no good at names, but perhaps "alloc_available_page_vma"? -andy - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
Hi! > >I was thinking about something like the atached (untested and sorry > >for using attachment). It shoudl blink just one led (numLock) on any > >keyboard that has such LED (and allows to control it). > > > > Argh, bad one. This one shoudl be better. Does it blink for you? It does not seem to do anything here :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/10] Scheduler profiling - Use immediate values
Alexey Dobriyan <[EMAIL PROTECTED]> writes: > On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote: > > Use immediate values with lower d-cache hit in optimized version as a > > condition for scheduler profiling call. > > I think it's better to put profile.c under CONFIG_PROFILING as > _expected_, so CONFIG_PROFILING=n users won't get any overhead, immediate or > not. That's what I'm going to do after test-booting bunch of kernels. No, it's better to handle this efficiently at runtime e.g. for distribution kernels. Mathieu's patch is good -Andi - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Some love to default profiler
Alexey Dobriyan <[EMAIL PROTECTED]> writes: > 2) Put profile.c under CONFIG_PROFILING. You enabled profiling in config, you >will get it. Removes conditional branch from schedule(). Code savings on my >usual config: > > textdata bss dec hex filename > 2921871 179895 180224 3281990 321446 vmlinux before > 2920141 179847 180224 3280212 320d54 vmlinux after > -- > -1730 -48 -1778 I think it's better to keep it by default. 1.7k is not really all that much. -Andi - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi,
On Wednesday, 4 July 2007 23:29, Pavel Machek wrote:
> Hi!
>
> > > > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > > > >
> > > > > > Seriously, though, I'd prefer not to. If we rename that acpi video
> > > > > > flags
> > > > > > variable (I assume this is what you're thinking of), we only create
> > > > > > cause for
> > > > > > confusion. A variable should for debugging or for controlling
> > > > > > quirks, not for
> > > > > > both at the same time.
> > > > >
> > > > > Cause for confusion? We are currently using 2 bits of that variable,
> > > > > and we want to add one more bit. I seriously doubt that can confuse
> > > > > anyone.
> > > >
> > > > Well, indeed it would be more elegant to rename the existing flags
> > > > variable
> > > > and use another bit out of it, but I personally don't think it's _that_
> > > > important. At least, I don't think we should block the patch
> > > > because of that.
> > >
> > > It is not _that_ important.
> > >
> > > > BTW, has anyone confirmed that it works on i386?
> > >
> > > If you have patch somewhere nearby, I can test it on i386 and make it
> > > use just one flags variable.
> >
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc6/patches/28-Optional-Beeping-During-Resume-From-RAM.patch
> >
>
> I can confirm that (Nigel's patch) works on i386; but it causes a warning:
>
> kernel/power/main.c: In function 's2ram_beep_show':
> kernel/power/main.c:319: warning: format '%d' expects type 'int', but
> argument 3 has type 'long unsigned int'
Yes, I've fixed the warning in the 2.6.22-rc7 series, but that's not a big
deal.
> Here's the version that uses just one variable, relative to Nigel's
> patch. Hmm, and it also closes nasty trap for the user in
> acpi_sleep_setup; order of parameters actually mattered there,
> acpi_sleep=s3_bios,s3_mode doing something different from
> acpi_sleep=s3_mode,s3_bios . It actually works here.
>
> Will you fold it into patch28, or should I create a changelog?
Hmm, I think we should keep the record straight. Please add a changelog
if that's not a problem.
> Testing welcome :-).
> Pavel
>
> diff --git a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
> index 4ee8357..5b67866 100644
> --- a/arch/i386/kernel/acpi/sleep.c
> +++ b/arch/i386/kernel/acpi/sleep.c
> @@ -14,7 +14,7 @@ #include
>
> /* address in low memory of the wakeup routine. */
> unsigned long acpi_wakeup_address = 0;
> -unsigned long acpi_video_flags;
> +unsigned long acpi_realmode_flags;
> extern char wakeup_start, wakeup_end;
>
> extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
> @@ -68,9 +68,11 @@ static int __init acpi_sleep_setup(char
> {
> while ((str != NULL) && (*str != '\0')) {
> if (strncmp(str, "s3_bios", 7) == 0)
> - acpi_video_flags = 1;
> + acpi_realmode_flags |= 1;
> if (strncmp(str, "s3_mode", 7) == 0)
> - acpi_video_flags |= 2;
> + acpi_realmode_flags |= 2;
> + if (strncmp(str, "s3_beep", 7) == 0)
> + acpi_realmode_flags |= 4;
> str = strchr(str, ',');
> if (str != NULL)
> str += strspn(str, ", \t");
> @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
>
> __setup("acpi_sleep=", acpi_sleep_setup);
>
> +/* Ouch, we want to delete this. We already have better version in
> userspace, in
> + s2ram from suspend.sf.net project */
> static __init int reset_videomode_after_s3(struct dmi_system_id *d)
> {
> - acpi_video_flags |= 2;
> + acpi_realmode_flags |= 2;
> return 0;
> }
>
> diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
> index 68e58f1..443fe85 100644
> --- a/arch/i386/kernel/acpi/wakeup.S
> +++ b/arch/i386/kernel/acpi/wakeup.S
> @@ -50,7 +50,7 @@ # BEEP
> movw%ax, %ds# Make ds:0
> point to wakeup_start
> movw%ax, %ss
>
> - testl $1, beep_flags - wakeup_code
> + testl $4, realmode_flags - wakeup_code
> jz 1f
> BEEP
> 1:
> @@ -64,7 +64,7 @@ # BEEP
> cmpl$0x12345678, %eax
> jne bogus_real_magic
>
> - testl $1, video_flags - wakeup_code
> + testl $1, realmode_flags - wakeup_code
> jz 1f
> lcall $0xc000,$3
> movw%cs, %ax
> @@ -72,7 +72,7 @@ # BEEP
> movw%ax, %ss
> 1:
>
> - testl $2, video_flags - wakeup_code
> + testl $2, realmode_flags - wakeup_code
> jz 1f
> mov video_mode - wakeup_code, %ax
> callmode_set
> @@ -111,11 +111,11 @@ # BEEP
> cmpl$0x12345678, %eax
> jne bogus_real_magic
>
> - testl $2, beep_flags - wakeup_code
> + testl $8, realmode_flags - wakeup_code
>
Re: blink driver power saving
Hi!
> > > > > Perhaps one of you geniuses who all hate it can find a better way to
> > > > > solve the "video output dead after kexec; but need visual feedback to
> > > > > the user
> > > > > while crash dumping" problem. I'm waiting for your patches.
> > > > >
> > > >
> > > > I don't don't like it ;) Unfortunately too many people end up enabling
> > >
> > > Yes that's pretty weird. I admit I hadn't expected
> > > that problem. blink is equivalent to "annoy me" and it
> > > is a mystery why so many people should willingly ask their computer to
> > > annoy them.
> >
> > tristate "Keyboard blink driver"
> >
> > ...drivers are not expected to act on their own. I was expecting to
> > get nice /sys/class/led* interface to my keyboard leds.
> >
> > BTW ... I still believe we should have /sys/class/led* interface to
> > those leds. I'd like to make them blink with hdd activity on some
> > machines... of course, that needs non-buggy KBC.
>
> I'll take patches. Ofcourse we'll have to keep the current EV_LED interface
> for compatibility.
It was simpler then I thought... but it has one small problem. It does
not actually work :-(..
it reaches the
printk("Setting led to %d\n", blinker->state);
input_inject_event(>handle, EV_LED, LED_NUML, blinker->state);
code, but my numlock led does not actually change. Any ideas?
Pavel
(leds-input.c:)
/*
* LED <-> input subsystem glue
*
* Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
* Copyright 2007 Dmitry Torokhov
* Copyright 2005-2006 Openedhand Ltd.
*
* Author: Pavel Machek <[EMAIL PROTECTED]>
* Based on code by: Richard Purdie <[EMAIL PROTECTED]>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
struct blinker {
struct delayed_work work;
struct input_handle handle;
int state;
};
struct blinker *blinker;
static void inputled_set(struct led_classdev *led_cdev, enum led_brightness
value)
{
blinker->state = value;
schedule_delayed_work(>work, 0);
}
static struct led_classdev input_led = {
.name = "input",
.default_trigger= "sharpsl-charge",
.brightness_set = inputled_set,
};
static void blink_task_handler(struct work_struct *work)
{
struct blinker *blinker = container_of(work, struct blinker, work.work);
printk("Setting led to %d\n", blinker->state);
input_inject_event(>handle, EV_LED, LED_NUML, blinker->state);
}
static void blink_event(struct input_handle *handle, unsigned int type,
unsigned int code, int down)
{
/*
* This is a very rare handler that does not process any input
* events; just injects them.
*/
}
static int blink_connect(struct input_handler *handler, struct input_dev *dev,
const struct input_device_id *id)
{
struct input_handle *handle;
int error;
blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
if (!blinker)
return -ENOMEM;
INIT_DELAYED_WORK(>work, blink_task_handler);
handle = >handle;
handle->dev = dev;
handle->handler = handler;
handle->name = "blink";
handle->private = blinker;
error = input_register_handle(handle);
if (error)
goto err_free_handle;
error = input_open_device(handle);
if (error)
goto err_unregister_handle;
error = led_classdev_register(NULL, _led);
if (error < 0)
goto err_input_close_device;
return 0;
err_input_close_device:
input_close_device(handle);
err_unregister_handle:
input_unregister_handle(handle);
err_free_handle:
kfree(handle);
return error;
}
static void blink_disconnect(struct input_handle *handle)
{
struct blinker *blinker = handle->private;
led_classdev_unregister(_led);
cancel_rearming_delayed_work(>work);
input_close_device(handle);
input_unregister_handle(handle);
kfree(blinker);
}
static const struct input_device_id blink_ids[] = {
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_LEDBIT,
.evbit = { BIT(EV_LED) },
.ledbit = { [LONG(LED_NUML)] = BIT(LED_NUML) },
},
{ }
};
static struct input_handler blink_handler = {
.event = blink_event,
.connect= blink_connect,
.disconnect = blink_disconnect,
.name = "blink",
.id_table = blink_ids,
};
static int __init blink_handler_init(void)
{
Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND
On Wednesday, 4 July 2007 21:33, Pavel Machek wrote: > Hi! > > > > What about this? (Only compile tested, but looks pretty obvious to > > > me). Something like this should get us rid of ugly option, and still > > > solve debugging problems... Hmmm? > > > Pavel > > > > > > Kill CONFIG_DISABLE_CONSOLE_SUSPEND; it should not be configurable at > > > all, instead, we should automatically keep console alive when > > > possible. > > > > > > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > diff --git a/drivers/char/lp.c b/drivers/char/lp.c > > > index 62051f8..8267ff8 100644 > > > --- a/drivers/char/lp.c > > > +++ b/drivers/char/lp.c > > > @@ -144,7 +144,7 @@ static unsigned int lp_count = 0; > > > static struct class *lp_class; > > > > > > #ifdef CONFIG_LP_CONSOLE > > > -static struct parport *console_registered; // initially NULL > > > +static struct parport *console_registered; > > > #endif /* CONFIG_LP_CONSOLE */ > > > > Could you please avoid fixing things like this, white space etc. in this > > patch? > > It would be easier to read ... > > Yep, sorry, it should be separate patch. I hope the idea is still > simple enough. Yes, but I'm not sure if netconsole is the only one that we will want to have disabled. Moreover, what if someone wants to use the netconsole regardless of the fact that it can crash the box? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Some love to default profiler
1) Drop __KERNEL__ out of profile.h. It contains only internal kernel stuff and
not in exported headers list
2) Put profile.c under CONFIG_PROFILING. You enabled profiling in config, you
will get it. Removes conditional branch from schedule(). Code savings on my
usual config:
textdata bss dec hex filename
2921871 179895 180224 3281990 321446 vmlinux before
2920141 179847 180224 3280212 320d54 vmlinux after
--
-1730 -48 -1778
3) Make timer_hook static (hi, Adrian!)
4) Convert do {} while (0) into static inline functions
5) minor misc stuff
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/profile.h | 78 +---
kernel/Makefile |3 +
kernel/profile.c|2 -
3 files changed, 44 insertions(+), 39 deletions(-)
--- a/include/linux/profile.h
+++ b/include/linux/profile.h
@@ -1,8 +1,6 @@
#ifndef _LINUX_PROFILE_H
#define _LINUX_PROFILE_H
-#ifdef __KERNEL__
-
#include
#include
#include
@@ -10,16 +8,22 @@
#include
-extern int prof_on __read_mostly;
+struct proc_dir_entry;
+struct pt_regs;
+struct notifier_block;
#define CPU_PROFILING 1
#define SCHED_PROFILING2
#define SLEEP_PROFILING3
#define KVM_PROFILING 4
-struct proc_dir_entry;
-struct pt_regs;
-struct notifier_block;
+enum profile_type {
+ PROFILE_TASK_EXIT,
+ PROFILE_MUNMAP
+};
+
+#ifdef CONFIG_PROFILING
+extern int prof_on __read_mostly;
/* init basic kernel profiler */
void __init profile_init(void);
@@ -42,22 +46,6 @@ static inline void profile_hit(int type, void *ip)
profile_hits(type, ip, 1);
}
-#ifdef CONFIG_PROC_FS
-void create_prof_cpu_mask(struct proc_dir_entry *);
-#else
-#define create_prof_cpu_mask(x)do { (void)(x); } while
(0)
-#endif
-
-enum profile_type {
- PROFILE_TASK_EXIT,
- PROFILE_MUNMAP
-};
-
-#ifdef CONFIG_PROFILING
-
-struct task_struct;
-struct mm_struct;
-
/* task is in do_exit() */
void profile_task_exit(struct task_struct * task);
@@ -77,14 +65,30 @@ int profile_event_unregister(enum profile_type, struct
notifier_block * n);
int register_timer_hook(int (*hook)(struct pt_regs *));
void unregister_timer_hook(int (*hook)(struct pt_regs *));
-
-/* Timer based profiling hook */
-extern int (*timer_hook)(struct pt_regs *);
-
-struct pt_regs;
-
#else
-
+#define prof_on 0
+static inline void profile_init(void)
+{
+}
+static inline void profile_tick(int type)
+{
+}
+static inline void profile_hits(int type, void *ip, unsigned int nr_hits)
+{
+}
+static inline void profile_hit(int type, void *ip)
+{
+}
+static inline void profile_munmap(unsigned long addr)
+{
+}
+static inline void profile_task_exit(struct task_struct *tsk)
+{
+}
+static inline int profile_handoff_task(struct task_struct *tsk)
+{
+ return 0;
+}
static inline int task_handoff_register(struct notifier_block * n)
{
return -ENOSYS;
@@ -105,10 +109,6 @@ static inline int profile_event_unregister(enum
profile_type t, struct notifier_
return -ENOSYS;
}
-#define profile_task_exit(a) do { } while (0)
-#define profile_handoff_task(a) (0)
-#define profile_munmap(a) do { } while (0)
-
static inline int register_timer_hook(int (*hook)(struct pt_regs *))
{
return -ENOSYS;
@@ -116,11 +116,15 @@ static inline int register_timer_hook(int (*hook)(struct
pt_regs *))
static inline void unregister_timer_hook(int (*hook)(struct pt_regs *))
{
- return;
}
+#endif
-#endif /* CONFIG_PROFILING */
-
-#endif /* __KERNEL__ */
+#ifdef CONFIG_PROC_FS
+void create_prof_cpu_mask(struct proc_dir_entry *);
+#else
+static inline void create_prof_cpu_mask(struct proc_dir_entry *pde)
+{
+}
+#endif
#endif /* _LINUX_PROFILE_H */
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-obj-y = sched.o fork.o exec_domain.o panic.o printk.o profile.o \
+obj-y = sched.o fork.o exec_domain.o panic.o printk.o \
exit.o itimer.o time.o softirq.o resource.o \
sysctl.o capability.o ptrace.o timer.o user.o \
signal.o sys.o kmod.o workqueue.o pid.o \
@@ -10,6 +10,7 @@ obj-y = sched.o fork.o exec_domain.o panic.o printk.o
profile.o \
kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
hrtimer.o rwsem.o latency.o nsproxy.o srcu.o die_notifier.o
+obj-$(CONFIG_PROFILING) += profile.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-y += time/
obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -37,7 +37,7 @@ struct profile_hit {
#define NR_PROFILE_GRP (NR_PROFILE_HIT/PROFILE_GRPSZ)
/* Oprofile timer tick hook */
-int (*timer_hook)(struct pt_regs *) __read_mostly;
+static int (*timer_hook)(struct pt_regs *) __read_mostly;
Re: implement-file-posix-capabilities.patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> 1. Exactly Andrew describes. Once userspace switches to a new cap
> format, an older kernel simply won't support them
Mmm. Let me see. I think I prefer this one! :-)
> 2. As Andrew describes, but also encode the version number into the
> capability name, i.e. security.capability.v3. Now userspace can
> optionally tack on more than one capability version to be backward
> compatible.
If you have a significant legacy of use of earlier versions, I guess
this makes sense. However, given the experimental nature of this support
(it will be a while before the user space support for this is
secure/robust), I'm not all that concerned about legacy support.
> 3. Somewhat different than Andrew describes. We mandate that any
> capability version N+1 consist of
>
> struct vfs_cap_data {
> __u32 magic;
> capability_version_1;
> capability_version_2;
> ...
> capability_version_N;
> capability_version_N+1;
> };
Ugh. I don't like this. It presumes that the kernel will get more and
more complicated over time. Please don't do this one.
> Or, for brevity,
>
> struct vfs_cap_data {
> __u32 first_magic;
> __u32 last_magic;
> capability_version_first;
> ...
> capability_version_last;
> };
>
> 4. Stick to the current plan, where switching to 64-bit caps will be
> done as
>
> struct vfs_cap_data_disk {
> __le32 version;
> __le32 data[]; /* eff[0], perm[0], inh[0], eff[1], ... */
> };
While asserting that it is more flexible etc., no one has yet actually
given an example of where fE being richer than a simple binary helps
anything. Until I see an example, I'm going to hold the position that
this is needless "complexity".
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGjBFXmwytjiwfWMwRAofJAKCXX2GkN39o45fCQmxpNpZIEVH8EgCeLaDy
AoWZNj/1MqT7oayabxUhIn8=
=OSBu
-END PGP SIGNATURE-
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
On Wednesday, 4 July 2007 21:25, Miklos Szeredi wrote: > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd > > wanting to resume devices during a system suspend transition? This is > > exactly what happens when those threads aren't frozen. > > OK, let me summarize the situation as I see it now: there are two > camps, the pro-freezers and the anti-freezers. > > Pro-freezers say: > > - don't remove the freezer, otherwise we'll have to deal with > numerous problems in drivers And these problems will generally be difficult to reproduce reliably and debug. > Anti-freezers say: > > - let's remove the freezer, which causes numerous problems > > Alan summerized the pro-freezer arguments well I think. What are the > anti-freezer arguments then? > > After having looked at the freezer and done some experiments with it, > the most obvious problem looks to be, that it can get stuck on a > process doing uninterruptible sleep. That's correct. > And yes, this can happen if a fuse filesystem daemon is frozen before a > filesystem user is. And this is not something that can be fixed in fuse, > some filesystem calls (rename(2) for example) are simply not restartable. > > This doesn't explain the deadlocks, but it could cause failure to > suspend which would be pretty annoying. I think the only thing that can deadlock in that context is the sync. At least, I don't see anything else. > Does this affect other things than fuse? Not that I know of. It may affect user space drivers, but there's no data on that. > Can this be fixed? > > It seems to be a fundamental problem with the freezer: while it does > make sure that user processes are not calling into drivers during > suspend, it also disallows perfectly harmless non-driver calls as > well. The problem is that when the freezer was designed (I didn't do that, BTW), there was no FUSE and similar things, so it's not prepared to cope with such interdependencies between user space tasks. We had an analogous problem with vfork() and it was solved by using the PF_FREEZER_SKIP flag. Perhaps we can do similar thing with FUSE. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Hi!
> > > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > > >
> > > > > Seriously, though, I'd prefer not to. If we rename that acpi video
> > > > > flags
> > > > > variable (I assume this is what you're thinking of), we only create
> > > > > cause for
> > > > > confusion. A variable should for debugging or for controlling quirks,
> > > > > not for
> > > > > both at the same time.
> > > >
> > > > Cause for confusion? We are currently using 2 bits of that variable,
> > > > and we want to add one more bit. I seriously doubt that can confuse
> > > > anyone.
> > >
> > > Well, indeed it would be more elegant to rename the existing flags
> > > variable
> > > and use another bit out of it, but I personally don't think it's _that_
> > > important. At least, I don't think we should block the patch
> > > because of that.
> >
> > It is not _that_ important.
> >
> > > BTW, has anyone confirmed that it works on i386?
> >
> > If you have patch somewhere nearby, I can test it on i386 and make it
> > use just one flags variable.
>
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc6/patches/28-Optional-Beeping-During-Resume-From-RAM.patch
>
I can confirm that (Nigel's patch) works on i386; but it causes a warning:
kernel/power/main.c: In function 's2ram_beep_show':
kernel/power/main.c:319: warning: format '%d' expects type 'int', but argument
3 has type 'long unsigned int'
Here's the version that uses just one variable, relative to Nigel's
patch. Hmm, and it also closes nasty trap for the user in
acpi_sleep_setup; order of parameters actually mattered there,
acpi_sleep=s3_bios,s3_mode doing something different from
acpi_sleep=s3_mode,s3_bios . It actually works here.
Will you fold it into patch28, or should I create a changelog?
Testing welcome :-).
Pavel
diff --git a/arch/i386/kernel/acpi/sleep.c b/arch/i386/kernel/acpi/sleep.c
index 4ee8357..5b67866 100644
--- a/arch/i386/kernel/acpi/sleep.c
+++ b/arch/i386/kernel/acpi/sleep.c
@@ -14,7 +14,7 @@ #include
/* address in low memory of the wakeup routine. */
unsigned long acpi_wakeup_address = 0;
-unsigned long acpi_video_flags;
+unsigned long acpi_realmode_flags;
extern char wakeup_start, wakeup_end;
extern unsigned long FASTCALL(acpi_copy_wakeup_routine(unsigned long));
@@ -68,9 +68,11 @@ static int __init acpi_sleep_setup(char
{
while ((str != NULL) && (*str != '\0')) {
if (strncmp(str, "s3_bios", 7) == 0)
- acpi_video_flags = 1;
+ acpi_realmode_flags |= 1;
if (strncmp(str, "s3_mode", 7) == 0)
- acpi_video_flags |= 2;
+ acpi_realmode_flags |= 2;
+ if (strncmp(str, "s3_beep", 7) == 0)
+ acpi_realmode_flags |= 4;
str = strchr(str, ',');
if (str != NULL)
str += strspn(str, ", \t");
@@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
__setup("acpi_sleep=", acpi_sleep_setup);
+/* Ouch, we want to delete this. We already have better version in userspace,
in
+ s2ram from suspend.sf.net project */
static __init int reset_videomode_after_s3(struct dmi_system_id *d)
{
- acpi_video_flags |= 2;
+ acpi_realmode_flags |= 2;
return 0;
}
diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
index 68e58f1..443fe85 100644
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -50,7 +50,7 @@ # BEEP
movw%ax, %ds# Make ds:0
point to wakeup_start
movw%ax, %ss
- testl $1, beep_flags - wakeup_code
+ testl $4, realmode_flags - wakeup_code
jz 1f
BEEP
1:
@@ -64,7 +64,7 @@ # BEEP
cmpl$0x12345678, %eax
jne bogus_real_magic
- testl $1, video_flags - wakeup_code
+ testl $1, realmode_flags - wakeup_code
jz 1f
lcall $0xc000,$3
movw%cs, %ax
@@ -72,7 +72,7 @@ # BEEP
movw%ax, %ss
1:
- testl $2, video_flags - wakeup_code
+ testl $2, realmode_flags - wakeup_code
jz 1f
mov video_mode - wakeup_code, %ax
callmode_set
@@ -111,11 +111,11 @@ # BEEP
cmpl$0x12345678, %eax
jne bogus_real_magic
- testl $2, beep_flags - wakeup_code
+ testl $8, realmode_flags - wakeup_code
jz 1f
BEEP
1:
- ljmpl $__KERNEL_CS,$wakeup_pmode_return
+ ljmpl $__KERNEL_CS, $wakeup_pmode_return
real_save_gdt: .word 0
.long 0
@@ -124,7 +124,7 @@ real_save_cr3: .long 0
real_save_cr4: .long 0
real_magic:.long 0
video_mode:.long 0
-video_flags: .long 0
+realmode_flags:.long 0
beep_flags:.long 0
real_efer_save_restore:
Re: md device files missing at boot time
On Wed, 04 Jul 2007 15:32:55 +0200, Ingo Freund <[EMAIL PROTECTED]> wrote: > Hi folks, > > one of the systems I'm working with was changed (copied) from single (scsi - > sda1) > to multiple disk (raid1) (sdb1,sdc1 --> md0). > When I try to boot from the new created md-device it stops with: > ... > loading reiserfs > "Waiting for device /dev/md0 to appear: not found -- Exiting to > /bin/sh > > A > # ls -la /dev/md* > shows nothing, so I understand why the "/" cannot be mounted, but > where are the /dev/md* files (I found them in "/lib/udev/devices")? > > The kernel is vanilla 2.6.21.5, the (I think) needed hardware and filesystem > drivers are built in modules and put into an initrd file for loading at boot > time. > > Does anyone have an idea what I might do wrong? > Stupid question, I suppose... Are you sdb1,sdc1 partitions "Linux RAID _autodetect_" ? All my raids use the md+raid modules builtin, no initrd, so I don't know if you have to force load of md on the initrd, or kernel will autoload if you use root=/dev/md0. Could you post your dmesg ? -- J.A. Magallon \ Software is like sex: \ It's better when it's free Mandriva Linux release 2008.0 (Cooker) for i586 Linux 2.6.21-jam10 (gcc 4.1.2 20070302 (4.1.2-1mdv2007.1)) SMP PREEMPT 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ieee1394: raw1394: fix a 32/64-bits compat fix
I was told that only i386 aligns 64 bit integers at 4 bytes boundaries
while all other architectures (32 bit architectures with 64 bit
siblings) align it on 8 bytes boundaries.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/raw1394.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux/drivers/ieee1394/raw1394.c
===
--- linux.orig/drivers/ieee1394/raw1394.c
+++ linux/drivers/ieee1394/raw1394.c
@@ -434,7 +434,11 @@ struct compat_raw1394_req {
__u64 sendb;
__u64 recvb;
-} __attribute__((packed));
+}
+#if defined(CONFIG_X86_64) || defined(CONFIG_IA64)
+__attribute__((packed))
+#endif
+;
static const char __user *raw1394_compat_write(const char __user *buf)
{
--
Stefan Richter
-=-=-=== -=== --=--
http://arcgraph.de/sr/
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: speed trends in pata world.
Gene Heskett skrev: Greetings; The drive speeds seem to be going the wrong way. Its an nforce2 equipt mobo, and I have 3 drives currently in this box. Running 2.6.22-rc6-cfs-v18 + the ftdi_sio.c patch. hda, the primary on cable 0, is running at around 28MB/Sec. Its a 200GB WD about 2 years old. Looks like this one is stuck at UDMA/33 Check the dmesg what the kernel detects, and why it ends up at low speed... hdb, is running at around 79MB/Sec, its a 4 year old 120GB WD. hdd is running at about 75MB/Sec, is a nearly new 300GB WD. Can I read anything into the fact that the 2 fast drives are on the slave end of the cables, whereas the slow one is master in the middle of the cable? -- Thomas - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: md device files missing at boot time
On 7/4/07, Ingo Freund <[EMAIL PROTECTED]> wrote: one of the systems I'm working with was changed (copied) from single (scsi - sda1) to multiple disk (raid1) (sdb1,sdc1 --> md0). When I try to boot from the new created md-device it stops with: ... loading reiserfs "Waiting for device /dev/md0 to appear: not found -- Exiting to /bin/sh # ls -la /dev/md* shows nothing, so I understand why the "/" cannot be mounted, but where are the /dev/md* files (I found them in "/lib/udev/devices")? The kernel is vanilla 2.6.21.5, the (I think) needed hardware and filesystem drivers are built in modules and put into an initrd file for loading at boot time. Does anyone have an idea what I might do wrong? How did you build the initramfs image? /sbin/mkinitrd? Did you add md support to the image? Kay - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Versioning file system
On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote: > (sorry for the late reply, just got back from holiday) > > On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > > As I mentioned in my Linux.conf.au presentation a year and a half ago, > > the main use of Streams in Windows to date has been for system > > crackers to hide trojan horse code and rootkits so that system > > administrators couldn't find them. :-) > > The only valid use of Streams in Windows I've seen was a virus checker > that stored a hash of the file in a separate stream. Checking a file > was a matter of rehashing it and comparing against the hash stored in > the special hash data stream for that particular file. And even that's not a valid use. All the virus would have to do is to infect the file, and then update the "special hash data stream". Why is it that when programmers are told about streams as a potential technology choice, it makes their thinking become fuzzy? :-) - Ted - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v2.6.21.5-rt19
I'm pleased to announce the v2.6.21.5-rt19 kernel on behalf of Ingo. It can be downloaded from the usual place: http://people.redhat.com/mingo/realtime-preempt/ More info about the -rt patch set can be found in the RT wiki: http://rt.wiki.kernel.org Changes since 2.6.21.5-rt18: - Fixed a nasty and hard to track down slowness / boot problem on SMP machines with CONFIG_NOHZ enabled. The problem was caused by the timer wheel base lock held during the get_next_timer_interrupt() call in the idle path, which eventually led to a bogus PI boosting of the idle task and in consequence a stale wrong scheduler selection for the affected idle task. Kudos to Carsten Emde, who patiently and meticulously isolated the problem and provided the traces, which allowed to identify the root cause. Problem solution: Prevent idle task boosting - back port of the ntp / clock_was_set fix - integration of the processor_idle fix from Venki Pallipadi, which resolves boot issues on some platforms - ep93xx clock events fix from Manfred Gruber To build a 2.6.21.5-rt19 tree, the following patches should be applied: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.5.tar.bz2 http://people.redhat.com/mingo/realtime-preempt/patch-2.6.21.5-rt19 Thanks, tglx - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/10] F00F bug fixup for i386 - use immediate values
On Tue, Jul 03, 2007 at 12:40:55PM -0400, Mathieu Desnoyers wrote:
> Use the faster immediate values for F00F bug handling in do_page_fault.
> --- linux-2.6-lttng.orig/arch/i386/mm/fault.c
> +++ linux-2.6-lttng/arch/i386/mm/fault.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -477,7 +478,7 @@
> /*
>* Pentium F0 0F C7 C8 bug workaround.
>*/
> - if (boot_cpu_data.f00f_bug) {
> + if (unlikely(immediate(f00f_bug_fix))) {
As I understand it, this never triggers in normal valid and invalid
pagefaults, because even invalid userspace pagefaults take branch
slightly earlier where catch SIGSEGV. Nobody cares about performance if
you reach this branch.
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch fixes (try #2)
Mike Frysinger wrote: > On 7/3/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: >> Bryan Wu wrote: >>> Jie's patch is required because we will release our new Blackfin toolchain. >> So, what is the new toolchain version? >> gcc 4.1.1 (adi 07r1) / binutils 2.17 doesn't seem to work anymore: > > we'll post new toolchain binaries in a bit Hrm, somehow I don't understand it. On [1] you're talking about gcc 4.1.2 and binutils 2.17 supporting the -mcpu switch. But if you download the 2007R1 RC9 toolchain from the Files section of the site (tar.gz) you actually get 4.1.1 without mcpu support. But the version string from gcc indicates 07r1. Care to explain? Thanks, Jan ps: All in all it is a bit unfortunate to put features in the upstream kernel for a toolchain version just available from svn. [1] http://docs.blackfin.uclinux.org/doku.php?id=toolchain_release_notes_2007r1 - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/10] Scheduler profiling - Use immediate values
On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote: > Use immediate values with lower d-cache hit in optimized version as a > condition for scheduler profiling call. I think it's better to put profile.c under CONFIG_PROFILING as _expected_, so CONFIG_PROFILING=n users won't get any overhead, immediate or not. That's what I'm going to do after test-booting bunch of kernels. Thus, enabling CONFIG_PROFILING option will buy you some overhead, again, as _expected_. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/10] Scheduler profiling - Use immediate values
On Tue, Jul 03, 2007 at 02:57:48PM -0400, Mathieu Desnoyers wrote: > * Alexey Dobriyan ([EMAIL PROTECTED]) wrote: > > On Tue, Jul 03, 2007 at 12:40:56PM -0400, Mathieu Desnoyers wrote: > > > Use immediate values with lower d-cache hit in optimized version as a > > > condition for scheduler profiling call. > > > > How much difference in performance do you see? > > > > Hi Alexey, > > Please have a look at Documentation/immediate.txt for that information. > Also note that the main advantage of the load immediate is to free a > cache line. Therefore, I guess the best way to quantify the improvement > it brings at one single site is not in terms of cycles, but in terms of > number of cache lines used by the scheduler code. Since memory bandwidth > seems to be an increasing bottleneck (CPU frequency increases faster > than the available memory bandwidth), it makes sense to free as much > cache lines as we can. > > Measuring the overall impact on the system of this single modification > results in the difference brought by one site within the standard > deviation of the normal samples. It will become significant when the > number of immediate values used instead of global variables at hot > kernel paths (need to ponder with the frequency at which the data is > accessed) will start to be significant compared to the L1 data cache > size. L1 cache is 8K here. Just how many such variables should exist? On hot paths! > We could characterize this in memory to L1 cache transfers per > seconds. > > On 3GHz P4: > > memory read: ~48 cycles > > So we can definitely say that 48*HZ (approximation of the frequency at > which the scheduler is called) won't make much difference, but as it > grows, it will. > > On a 1000HZ system, it results in: > > 48000 cycles/second, or 16µs/second, or 0.16% speedup. > > However, if we place this in code called much more often, such as > do_page_fault, we get, with an hypotetical scenario of approximation > of 10 page faults per second: > > 480 cycles/s, 1.6ms/second or 0.0016% speedup. > > So as the number of immediate values used increase, the overall memory > bandwidth required by the kernel will go down. Adding so many infrastructure for something that you can't even measure is totally unjustified. There are already too many places where unlikely() and __read_mostly are used just because they can be used, so adding yet another such very specific, let's call it annotation, seems wrong to me. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ext4: fix error handling in ext4_create_journal
On Wed, Jul 04, 2007 at 09:30:24PM +0200, Borislav Petkov wrote:
> Fix error handling in ext4_create_journal according to kernel conventions.
> --- linux-2.6.22-rc7/fs/ext4/super.c.orig
> +++ linux-2.6.22-rc7/fs/ext4/super.c
> @@ -2150,6 +2150,7 @@
> unsigned int journal_inum)
> {
> journal_t *journal;
> + int err;
>
> if (sb->s_flags & MS_RDONLY) {
> printk(KERN_ERR "EXT4-fs: readonly filesystem when trying to "
> @@ -2157,13 +2158,15 @@
> return -EROFS;
> }
>
> - if (!(journal = ext4_get_journal(sb, journal_inum)))
> + journal = ext4_get_journal(sb, journal_inum);
> + if (!journal)
> return -EINVAL;
OK.
> printk(KERN_INFO "EXT4-fs: creating new journal on inode %u\n",
> journal_inum);
>
> - if (jbd2_journal_create(journal)) {
> + err = jbd2_journal_create(journal);
> + if (err) {
> printk(KERN_ERR "EXT4-fs: error creating journal.\n");
> jbd2_journal_destroy(journal);
> return -EIO;
Original code is fine.
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New systems: eu.kernel.org
Sébastien Dugué wrote: > > One last thing, is there a git server as well for eu? > FWIW, I've set up git.eu.kernel.org; right now it's an alias to git.kernel.org, but that might change in the future. -hpa - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
speed trends in pata world.
Greetings; The drive speeds seem to be going the wrong way. Its an nforce2 equipt mobo, and I have 3 drives currently in this box. Running 2.6.22-rc6-cfs-v18 + the ftdi_sio.c patch. hda, the primary on cable 0, is running at around 28MB/Sec. Its a 200GB WD about 2 years old. hdb, is running at around 79MB/Sec, its a 4 year old 120GB WD. hdd is running at about 75MB/Sec, is a nearly new 300GB WD. Can I read anything into the fact that the 2 fast drives are on the slave end of the cables, whereas the slow one is master in the middle of the cable? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Dumb terminal - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blink driver power saving
Hi! > > > > > Perhaps one of you geniuses who all hate it can find a better way to > > > > > solve the "video output dead after kexec; but need visual feedback to > > > > > the user > > > > > while crash dumping" problem. I'm waiting for your patches. > > > > > > > > > > > > > I don't don't like it ;) Unfortunately too many people end up enabling > > > > > > Yes that's pretty weird. I admit I hadn't expected > > > that problem. blink is equivalent to "annoy me" and it > > > is a mystery why so many people should willingly ask their computer to > > > annoy them. > > > > tristate "Keyboard blink driver" > > > > ...drivers are not expected to act on their own. I was expecting to > > get nice /sys/class/led* interface to my keyboard leds. > > What's the benefit of such an interface? If you're able to trigger > keyboard LEDs via that interface, you're also able to use the ioctl() > on /dev/console. Well, at least it is standartized interface... plus it can do stuff like "blink that led on disk access". > I think the intention of the blink driver was to have a *early* blink, > i.e. before initrd (and on systems without intrd, before the first > init script runs). ...and yes, it can autoblink, too. It should be even possible to set default behaviour of led to blink, doing what the blink driver does, but in a clean way. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND
Hi! > > What about this? (Only compile tested, but looks pretty obvious to > > me). Something like this should get us rid of ugly option, and still > > solve debugging problems... Hmmm? > > Pavel > > > > Kill CONFIG_DISABLE_CONSOLE_SUSPEND; it should not be configurable at > > all, instead, we should automatically keep console alive when > > possible. > > > > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> > > > > diff --git a/drivers/char/lp.c b/drivers/char/lp.c > > index 62051f8..8267ff8 100644 > > --- a/drivers/char/lp.c > > +++ b/drivers/char/lp.c > > @@ -144,7 +144,7 @@ static unsigned int lp_count = 0; > > static struct class *lp_class; > > > > #ifdef CONFIG_LP_CONSOLE > > -static struct parport *console_registered; // initially NULL > > +static struct parport *console_registered; > > #endif /* CONFIG_LP_CONSOLE */ > > Could you please avoid fixing things like this, white space etc. in this > patch? > It would be easier to read ... Yep, sorry, it should be separate patch. I hope the idea is still simple enough. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ext4: fix error handling in ext4_create_journal
On Tue, Jul 03, 2007 at 03:25:43PM -0700, Andrew Morton wrote:
> Please prepare the equivalent patch for ext4. Without that, it'd probably
> be better to avoid applying the ext3 patch: there are advantages to keeping
> the two in sync where possible.
Hi Andrew,
here you go. By the way, this one is with generated diffstat. Do you prefer
it that way or is a diffstat for a patch touching a single file too much?
-
From: Borislav Petkov <[EMAIL PROTECTED]>
Fix error handling in ext4_create_journal according to kernel conventions.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
linux-2.6.22-rc7/fs/ext4/super.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6.22-rc7/fs/ext4/super.c
===
--- linux-2.6.22-rc7/fs/ext4/super.c.orig 2007-07-04 21:18:24.0
+0200
+++ linux-2.6.22-rc7/fs/ext4/super.c2007-07-04 21:19:46.0 +0200
@@ -2150,6 +2150,7 @@
unsigned int journal_inum)
{
journal_t *journal;
+ int err;
if (sb->s_flags & MS_RDONLY) {
printk(KERN_ERR "EXT4-fs: readonly filesystem when trying to "
@@ -2157,13 +2158,15 @@
return -EROFS;
}
- if (!(journal = ext4_get_journal(sb, journal_inum)))
+ journal = ext4_get_journal(sb, journal_inum);
+ if (!journal)
return -EINVAL;
printk(KERN_INFO "EXT4-fs: creating new journal on inode %u\n",
journal_inum);
- if (jbd2_journal_create(journal)) {
+ err = jbd2_journal_create(journal);
+ if (err) {
printk(KERN_ERR "EXT4-fs: error creating journal.\n");
jbd2_journal_destroy(journal);
return -EIO;
--
Regards/Gruß,
Boris.
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway
> Remember what I wrote a few minutes ago about khubd and ksuspend_usbd > wanting to resume devices during a system suspend transition? This is > exactly what happens when those threads aren't frozen. OK, let me summarize the situation as I see it now: there are two camps, the pro-freezers and the anti-freezers. Pro-freezers say: - don't remove the freezer, otherwise we'll have to deal with numerous problems in drivers Anti-freezers say: - let's remove the freezer, which causes numerous problems Alan summerized the pro-freezer arguments well I think. What are the anti-freezer arguments then? After having looked at the freezer and done some experiments with it, the most obvious problem looks to be, that it can get stuck on a process doing uninterruptible sleep. And yes, this can happen if a fuse filesystem daemon is frozen before a filesystem user is. And this is not something that can be fixed in fuse, some filesystem calls (rename(2) for example) are simply not restartable. This doesn't explain the deadlocks, but it could cause failure to suspend which would be pretty annoying. Does this affect other things than fuse? Can this be fixed? It seems to be a fundamental problem with the freezer: while it does make sure that user processes are not calling into drivers during suspend, it also disallows perfectly harmless non-driver calls as well. Miklos - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ata1: soft resetting port
On Thu, 2007-07-05 at 03:01 +0900, Tejun Heo wrote: > Soeren Sonnenburg wrote: > > On Tue, 2007-07-03 at 15:40 +0900, Tejun Heo wrote: > >> Soeren Sonnenburg wrote: > >>> Dear List, > >>> > >>> since the switch to > >>> > >>> CONFIG_ATA=y > >>> CONFIG_ATA_ACPI=y > >>> CONFIG_ATA_PIIX=y, > >>> > >>> the ATA_PIIX driver manages both, internal sata disk aswell as cd/dvd > >>> rom. However I am being flooded with the error messages below (well they > >>> appear from time to time, dominating dmesg). > >>> > >>> This happens on kernel 2.6.22-rc5, I am copying relevant parts from dmesg: > >> Does 2.6.22-rc7 fare better? > > > > Yes indeed. The only thing I've seen in the last two days was the > > following on resume: > > > > pci_express :00:1c.2:pcie03: resuming > > sr 0:0:0:0: resuming > > sd 2:0:1:0: resuming > > sd 2:0:1:0: [sda] Starting disk > > ata1.00: configured for UDMA/33 > > ata3.01: revalidation failed (errno=-2) > > ata3: failed to recover some devices, retrying in 5 secs > > ata3.01: configured for UDMA/133 > > Hmmm... That's NODEV_HINT being triggered after resume. Probably the > device isn't ready to respond yet at that point. How reproducible is > the problem? quite reproducible: $ dmesg | grep 'revalidation failed' | wc -l 4 Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
