On Sat, Oct 25, 2008 at 6:23 AM, Renato S. Yamane Could be, can't remember what happened that day (maybe too much beer), anyways I have noticed battery power being lost after power off, but not yet for 2.6.28, I think around 2.6.25-or-26, but when it happened it was seldom, or in any case once or twice, not enough times for me to say anything, just figured it was leaving the system unplugged while in suspend. -- Justin P. Mattock --

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11215 Subject : INFO: possible recursive locking detected ps2_command Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11476 Subject : failure to associate after resume from suspend to ram Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com> Date : ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11569 Subject : Panic stop CPUs regression Submitter : Andi Kleen <andi@firstfloor.org> Date : 2008-09-02 13:49 (54 days ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11512 Subject : sort-of regression due to "kconfig: speed up all*config + randconfig" Submitter : Alexey Dobriyan ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11210 Subject : libata badness Submitter : Kumar Gala <galak@kernel.crashing.org> Date : 2008-07-31 18:53 (87 days old) References : ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11699 Subject : 2.6.27-rc-7: BUG: scheduling while atomic, c1e_idle+0x98/0xe0 Submitter : Prakash Punnoor <prakash@punnoor.de> Date : ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11669 Subject : when CPU hotplugging is disabled, nr_cpu_ids does not get set properly during boot Submitter : Chuck Ebbert ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11543 Subject : kernel panic: softlockup in tick_periodic() ??? Submitter : Joshua Hoblitt <j_kernel@hoblitt.com> Date : 2008-09-11 ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11831 Subject : NULL pointer derefence since 2.6.27 in (e)poll Submitter : Ben Castricum <lk0810@bencastricum.nl> Date : 2008-10-19 ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11272 Subject : BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835 Submitter : Jaswinder Singh ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11829 Subject : Kernel 2.6.26.5 -> 2.6.27.2 [USB REGRESSION] (USB -> D_STATE) Submitter : Justin Piszcz ...

[Here's something new, a list of regressions introduced between 2.6.26 and 2.6.27. We haven't fixed all of them yet and they're still being reported. Also, they need to be fixed as well as those introduced later (although they may be considered as "less important"). Quite frankly, I don't know how this is going to work out, but I thought it's worth trying. Enjoy! ;-)] This message contains a list of some regressions introduced between 2.6.26 and 2.6.27, for which there are no fixes in the ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11820 Subject : 2.6.27: 0 MHz CPU and wrong system time on AMD Geode system Submitter : Antipov Dmitry <dmantipov@yandex.ru> Date : ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11832 Subject : 2.6.27: "irq 18: nobody cared" on Toshiba Satellite A100 Submitter : M. Vefa Bicakci <bicave@superonline.com> Date : ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11608 Subject : 2.6.27-rc6 BUG: unable to handle kernel paging request Submitter : John Daiker <daikerjohn@gmail.com> Date : 2008-09-16 ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11207 Subject : VolanoMark regression with 2.6.27-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-07-31 3:20 ...

This message has been generated automatically as a part of a report of regressions introduced between 2.6.26 and 2.6.27. The following bug entry is on the current list of known regressions introduced between 2.6.26 and 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11550 Subject : pnp: Huge number of "io resource overlap" messages Submitter : Frans Pop <elendil@planet.nl> Date : 2008-09-09 10:50 (47 ...

struct hid_device_id contains hidden padding which is bad for cross compiling. Make the padding explicit and consistent across architectures. Signed-off-by: Andreas Schwab <schwab@suse.de> --- diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h index eb71b45..0e4f303 100644 --- a/include/linux/mod_devicetable.h +++ b/include/linux/mod_devicetable.h @@ -135,6 +135,7 @@ struct usb_device_id { struct hid_device_id { __u16 bus; + __u16 pad1; __u32 vendor; ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11833 Subject : 2.6.27-git8 compile error in drivers/mfd/wm8350-core.c Submitter : Tilman Schmidt <tilman@imap.cc> Date : 2008-10-19 18:17 (7 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11827 Subject : suspend broken on powerbook5,6 Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2008-10-25 05:07 (1 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11799 Subject : xorg can not start up with stolen memory Submitter : arrow zhang <arrow.ebd@gmail.com> Date : 2008-10-21 06:08 (5 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11848 Subject : 2.6.28-rc1: NCQ devices connected to PMP are still dead Submitter : Petr Vandrovec <vandrove@vc.cvut.cz> Date : 2008-10-25 11:17 (1 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11847 Subject : 2.6.28-rc1 fails building on allnoconfig Submitter : Matt Mackall <mpm@selenic.com> Date : 2008-10-24 17:09 (2 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11852 Subject : v2.6.28-rc1: Regression in ext3/jbd Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-10-25 11:22 (1 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11854 Subject : v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-10-25 17:14 (1 days ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11825 Subject : appletouch broken Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2008-10-25 03:55 (1 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11849 Subject : default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems) Submitter : Kumar Gala <galak@kernel.crashing.org> Date : 2008-10-24 12:45 (2 days ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11826 Subject : extreme slowness of IO stuff using 2.6.28-rc1 Submitter : Yves-Alexis Perez <corsac@debian.org> Date : 2008-10-25 04:25 (1 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11798 Subject : [Radeon Xpress 1100 IGP] DRI fail on recent kernel updates Submitter : Gu Rui <chaos.proton@gmail.com> Date : 2008-10-21 04:28 (5 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11805 Subject : mounting XFS produces a segfault Submitter : Tiago Maluta <maluta_tiago@yahoo.com.br> Date : 2008-10-21 18:00 (5 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.27. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11806 Subject : iwl3945 fails with microcode error Submitter : Johannes Berg <johannes@sipsolutions.net> Date : 2008-10-22 02:36 (4 days old) References : ...

Applied to kbuild-fixes.git Will push out soon. Sam --

Thunderbird crashes out for me, no problems with 2.6.27-git10. I didn't try 2.6.28-rc1. 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 --

Hi Linus. Please pull the following two fixes for kbuild. One fix for make rpm (which is also stable material) And one fix so we are more robust for wrong asm symlinks None of these has been in -next but they are trivial and I would like to see them applied soon. Thanks, Sam The following changes since commit e013e13bf605b9e6b702adffbe2853cfc60e7806: Jens Axboe (1): libata: fix bug with non-ncq devices are available in the git repository at: ...

Just thought I'd chime in to report the same thing. I don't use the NICs very frequently, so I didn't notice until I read the report. On this machine, the NICs are never put through a suspend/resume cycle, so that doesn't seem to be anything to do with it. The NICs should have incremental MAC addresses, since they're mainboard devices. Put it this way, they used to. Now when they're detected, one has the correct MAC, and the second has the first 32bits of its MAC corrupted. eth0: ...

Ah, I thought I have broken hardware. I have similar problem, my mac is initially all zeroes. When I set it up, it works until suspend. After that I need to unbind the driver, bind it again, and it works then (mac is still the set one). I'm out of the notebook right now, but it is 10ec:8168: 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) Subsystem: ASUSTeK Computer Inc. Unknown device 11f5 I used it perfectly far ...

Please follow http://bugzilla.kernel.org/show_bug.cgi?id=11825 --

Updatescrollmode is marked inline, but it's big and is called only from non-critical codepaths (fbcon_resize, fbcon_switch, fbcon_modechanged). Dropping it saves almost 800 bytes of text size. text data bss dec hex filename 23859 287 8448 32594 7f52 drivers/video/console/fbcon.o.before 23065 287 8448 31800 7c38 drivers/video/console/fbcon.o.after Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: ...

I'd question the value in adding the config option. Why not make the Perhaps you were concerned about memory consumption? If so, it would be much much better to make this feature switchable at We have lots of global state here with no apparent locking protecting it. Possibly there's some higher-level lock which provides seralisation? If so, the addition of a comment explaining all this would be good. --

/sys knob seems to be the most flexible option. I checked it and this code is called under console_sem. vgacon_switch_scrollback <- vgacon_switch <- con_switch <- redraw_screen <- switch_screen <- complete_change_console <- 1) vt_ioctl (calls acquire_console_sem before complete_change_console) 2) change_console <- console_callback (calls acquire_console_sem before change_console) Thanks for a review! PS: why DECLARE_MUTEX _defines_ _semaphore_? there are only 8 uses of this macro so ...

convert kmap_init, permanent_kmaps_init, set_highmem_pages_init macros defined when !CONFIG_HIGHMEM to functions supresses following warning from gcc: arch/x86/mm/init_32.c: In function 'pagetable_init': arch/x86/mm/init_32.c:516: warning: unused variable 'pgd_base' Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> --- arch/x86/mm/init_32.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/init_32.c ...

Hi, When I run readlink on the /proc/*/exe-file for udevd, the kernel returns some unitialized data to userspace: # strace -e trace=readlink readlink /proc/4762/exe readlink("/proc/4762/exe", "/sbin/udevd", 1025) = 30 You can see it because the kernel thinks that the string is 30 bytes long, but in fact it is only 12 (including the '\0'). If we explicitly clear the buffer before calling readlink, we can also see that some garbage has been filled in there, after the string: # ...

Weird. The dentry for "udevd" has an incorrect length. Is something stomping the length somewhere? What filesystem does /sbin/udevd reside on? Eric --

I don't think this is the same issue, but in both cases it looks like the BIOS AML code is wrong (just judging from the output, haven't looked at the dump yet). _WAK is supposed to return a package of 2 DWORD values, a bit field of conditions that occurred during sleep, and the effective S-state the system actually entered (section 7.3.7 of the ACPI 3.0 spec). Presumably the BIOS is returning a single integer. --

Sorry for my resending, the previous patch can't be applied successfully. It seems strange to call kgdboc_option_setup with parameter of config from configure_kgdboc(), because kgdboc_option_setup() is used to fill config with stuff in other place. Now, kgdboc_option_setup will fill config with config itself. But on the other hand, kgdboc_option_setup has a additional effect to check whether config overflows or not. Is it ok to remove kgdboc_option_setup? Signed-off-by: Qinghuang Feng ...

Paramter @mem has been removed since v2.6.26, now delete it's comment. Signed-off-by: Qinghuang Feng <qhfeng.kernel@gmail.com> --- diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 64e5b4b..460f90e 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -38,7 +38,6 @@ static DEFINE_SPINLOCK(zone_scan_mutex); * badness - calculate a numeric value for how bad this task has been * @p: task struct of which task we should calculate * @uptime: current uptime in seconds - * @mem: target memory ...

When I viewed drivers/video/modedb.c, so I accidentally noticed a very old typo already contained in 2.6.0. This typo remained unheeded at least 5 years. Clear evidence of its importance. ;) --- diff -Nupr a/drivers/video/modedb.c b/drivers/video/modedb.c --- a/drivers/video/modedb.c 2008-10-25 16:18:00.000000000 +0200 +++ b/drivers/video/modedb.c 2008-10-25 16:18:10.000000000 +0200 @@ -329,7 +329,7 @@ const struct fb_videomode vesa_modes[] = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, ...

This one can wait for other Documentation/ changes/moves. --- ~Randy --

I have almost given up on this. Three merge attemps failed for different reasons, and I will not even have time for my maintainership duties the next months. Anyone that can bring it forward? Sam --

The incentive was to have a common place to add small tests that could be used to verify that the kernel works as expected. From inkernel modules (like rcutorture) to small userspace utilities such as something massaging the epoll interface or similar. The above was just to get it started. Having a set of tests to run when introducing a new syscall would make it much easier for an arch maintainer to verify that the implemented syscall works as expected. And forcing the developer to use ...

What are the reasons this is failing? Is it just moving different files around into the tests/ directory? Or is it new functionality here? If just moving stuff, is that really needed? thanks, greg k-h --

[Sorry in advance for the huge Cc, most of it is from the commit.] Hi, This commit: commit 2d7c820e56ce83b23daee9eb5343730fb309418e Author: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Date: Wed Oct 22 14:15:01 2008 -0700 ext3: add checks for errors from jbd introduces a regression which was discovered by kmemcheck: WARNING: kmemcheck: Caught 32-bit read from freed memory (f4f1b804) 00b0f1f4fbffffff404439ef008830f20200000097970000ad4eaddeffffffff i i i i f f f f f f f f f ...

Hello, I think I talked too fast: it seems impossible to have both drivers (leds-hp-disk and lis3lv02d) working at the same time. Only the first driver loaded is used. After a little look at it, I think it comes from the fact that both drivers are assigned to the same MODALIAS (HPQ0004). The ACPI PNP (through the generic bus infrastructure) only declare the device to one of the drivers supporting it, not all of them. How can I tell to ACPI that it should load both drivers for the same ...

^ --

[Empty message]

Your patch did not solve it. But you are right that the program I use is a mess, it was doing tv.tv_sec = 0; tv.tv_usec = 5000000L; So I changed it to tv.tv_sec = 5; tv.tv_usec = 0; and it worked (with and without your patch). From what I understand this is what your patch does, --

On Sat, 25 Oct 2008 07:05:42 -0700 This patch should fix it; I'm a bit worried that I need to fix up userlands "mess", but ok. I also checked all other converted functions, and only select has this problem. The problem is that the conversion from microseconds to nanoseconds is overflowing ;-( can you give this one a test? diff --git a/fs/compat.c b/fs/compat.c index fe3c9bf..95ceee6 100644 --- a/fs/compat.c +++ b/fs/compat.c @@ -1680,9 +1680,16 @@ asmlinkage long compat_sys_select(int n, ...

Hello Jens, while doing a backup on DVD+R I got the following warning (and a k3b hung). the drive is a Plextor 716A on a jmicron PATA port. I have never seen this with earlier kernels. I am a bit reluctant to reproduce or bisect this problem, since it might kills my blank DVDs. Could this be related to commit e013e13bf605b9e6b702adffbe2853cfc60e7806 (libata: fix bug with non-ncq devices)? Thank you for any idea. Oct 24 19:49:15 Festrechner kernel: [21790.704070] ------------[ cut here ...

The right answer is definitely "both". -hpa --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The background: So during the initial configuration of a box I enabled the xattr flags for ext3 and options of xattr in coreutils, and at the time didn't realize that I'd hit a snag that would finally annoy me enough after a month of getting a non-fatal error messages from cp "cp: listing attributes of `/dev/null`: Invalid argument" to spend half a day researching the cause and a potential solution. Setup: udev mounts a tmpfs to /dev then fills ...

If this is an outright violation of the ACPI spec, let me know (and if possible, please tell me the spec page). This is the kind of thing I expect it would be a no-brainer to get Lenovo to fix with a BIOS update. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

[ It was late at night, I didn't feel like sleeping so I wrote up this new utility for ftrace. This is not ready for inclussion, but produces nice information. It hooks into the ftrace function tracer to produce a count of all the functions that are hit. Paul, I used the RCU hlist manipulations to read and add fuctions to a list. I never delete (except for clearing out the array, with a memcpy). The comments say the that the iterator must be protected by a rcu_read_lock. ...

Hi Steven, The rcu function are on top of this profile. May be it's because you use rcu when you touch your hash table. Wouldn't be interesting to disable the counter adding for these functions when they Copy-paste error? :-) --

It looks like you provide one patch per file. You should group some of them together so that each patch does a functional change and everything still builds after incrementally applying that patch. The way you have splitted them will break builds if someone tries to build after patch 1 for instance. Willy --

Change the gate_desc typedef to use the new gate_struct. Signed-off-by: Joe Damato <ice799@gmail.com> --- include/asm-x86/desc_defs.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/desc_defs.h b/include/asm-x86/desc_defs.h index 68abda4..012df1f 100644 --- a/include/asm-x86/desc_defs.h +++ b/include/asm-x86/desc_defs.h @@ -72,7 +72,7 @@ typedef struct ldttss_desc64 tss_desc; #define gate_offset(g) ((g).offset_low | ((unsigned ...

Split the single descriptor struct into an IDT struct and a struct for ldt/gdt/tss. This was done because the fields in IDTs are not the same or in the same order as ldt/gdt/tss descriptors. More meaningful field names were added and the a/b fields were removed. Signed-off-by: Joe Damato <ice799@gmail.com> --- include/asm-x86/desc_defs.h | 32 +++++++++++++------------------- 1 files changed, 13 insertions(+), 19 deletions(-) diff --git a/include/asm-x86/desc_defs.h ...

Use static intializer for IDT entries. Signed-off-by: Joe Damato <ice799@gmail.com> --- arch/x86/kernel/traps.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index e062974..b308d71 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -86,7 +86,7 @@ char ignore_fpu_irq; * for this. */ gate_desc idt_table[256] - __attribute__((__section__(".data.idt"))) = { { { { 0, 0 } } }, ...

Use macros for getting/setting the hi and lo 32bits of descriptors since 'a' and 'b' were removed. Signed-off-by: Joe Damato <ice799@gmail.com> --- arch/x86/kernel/tls.c | 2 +- arch/x86/kernel/vmi_32.c | 3 ++- arch/x86/lguest/boot.c | 2 +- arch/x86/math-emu/fpu_system.h | 19 +++++++++---------- drivers/lguest/interrupts_and_traps.c | 18 +++++++++--------- drivers/lguest/segments.c | 14 +++++++------- ...

Use static intializers for GDT/LDT entries. Signed-off-by: Joe Damato <ice799@gmail.com> --- arch/x86/kernel/apm_32.c | 2 +- arch/x86/kernel/cpu/common.c | 28 ++++++++++++++-------------- include/asm-x86/lguest.h | 4 ++-- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c index 5145a6e..5cacdad 100644 --- a/arch/x86/kernel/apm_32.c +++ b/arch/x86/kernel/apm_32.c @@ -407,7 +407,7 @@ static ...

Add useful macros which can be used to access the lo and hi 32bit words, get the offset of the handler, and get the segment for gate_descs. Signed-off-by: Joe Damato <ice799@gmail.com> --- include/asm-x86/desc_defs.h | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/include/asm-x86/desc_defs.h b/include/asm-x86/desc_defs.h index 012df1f..d6a5310 100644 --- a/include/asm-x86/desc_defs.h +++ b/include/asm-x86/desc_defs.h @@ -75,8 +75,13 @@ typedef struct ...

Hi - This is my first submission to the kernel, so (beware!) please let me know if I can make any improvements on these patches. I attempted to clean up the x86 structs for 32bit cpus that store IDT/LDT/GDT data by removing the fields labeled "a" and "b" in favor of more descriptive field names. I added some macros and went through the kernel cleaning up the various places where "a" and "b" were used. I tried building my kernel with my .config and then also did a make allyesconfig build to help ...

x86: Add a synthetic TSC_RELIABLE feature bit. From: Alok N Kataria <akataria@vmware.com> Virtual TSCs can be kept nearly in sync, but because the virtual TSC offset is set by software, it's not perfect. So, the TSC synchronization test can fail. Even then the TSC can be used as a clocksource since the VMware platform exports a reliable TSC to the guest for timekeeping purposes. Use this bit to check if we need to skip the TSC sync checks. Along with this also set the CONSTANT_TSC bit ...

Add serial key as a field to check for in dmi_name_in_vendors. From: Alok N Kataria <akataria@vmware.com> In some user configured cases, VMware may choose not to put a VMware specific DMI string, but the serial key is always there and is VMware specific. Add that too to check for in the dmi_name_in_vendors function. Signed-off-by: Alok N Kataria <akataria@vmware.com> --- drivers/firmware/dmi_scan.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git ...

When cpusets are enabled, it's necessary to print the triggering task's set of allowable nodes so the subsequently printed meminfo can be interpreted correctly. We also print the task's cpuset name for informational purposes. Cc: Paul Menage <menage@google.com> Signed-off-by: David Rientjes <rientjes@google.com> --- include/linux/cpuset.h | 7 +++++++ kernel/cpuset.c | 15 +++++++++++++++ mm/oom_kill.c | 22 ++++++++++++++++++++++ 3 files changed, 44 insertions(+), ...

<linux/time.h> does not include <asm/time.h>. This sort of stuff happens if you believe checkpatch.pl. You only got away because the header isn't needed anyway. I'll apply the patch with this bit dropped. Ralf PS: Suspicion breeds confidence. At least in case of checkpatch ;-) --

Hmmm... I'd prefer firmware to actually update the device tree if the LED state needs to be preserved. In fact, it might be better use the name "current-state" instead of "default-state" similar to the current-speed property used in serial devices. However, I understand that there are practical implications with this were not all firmware is device tree aware. I don't see any reason not to support this approach, so: Acked-by: Grant Likely <grant.likely@secretlab.ca> (But consider ...

FWIW, I like the idea of removing __cpuinit. It often is quite difficult to determine if given piece of code should be marked as __cpuinit and that leads to bugs that are not so easy to resolve. Thanks, Rafael --

On Fri, 24 Oct 2008 23:37:10 +0200 applied and git-pushed -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

On Sat, 25 Oct 2008 09:59:25 +0200 those sections don't actually exist because of the linker script magic... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org --

On Sat, 25 Oct 2008 16:35:28 +0200 [linux.trees.git]# objdump -h vmlinux.before | grep init.text 25 .init.text 00037c25 ffffffff8152a000 000000000152a000 0092a000 [inux.trees.git]# objdump -h vmlinux.after | grep init.text 25 .init.text 000316c2 ffffffff81542000 0000000001542000 00942000 --

The interesting number here is the size of the cpuinit/cpuexit sections. cpuinit sections are discarded after init and cpuexit sections are discarded if you do not use modules. Can you share these numbers with us? Sam --

There's an assessment of this in the commit comment which you omitted. It compresses well, and it's __initdata. So it takes up very little space in the bzImage, and is dropped fairly quickly during boot. So the amount of time it's _actually_ taking up any noticeable amount of memory is really quite small. But if someone wants to extend modpost so that it can handle relocations and we can use string _pointers_ in the dmi tables, that would be good. -- David Woodhouse ...

Sure. But it's still suddenly one of the biggest data structures in the kernel image. And I expect we'll keep accumulating these sorts of The sad thing is that we've gone from using len(x) + 4 bytes to 79 bytes, where the average x appears to have been... 4 (counting the fact that most match slots are empty!). If we used strstr rather than strcmp, we could probably get by with < 8 bytes per id (and maybe roll some entries together). Also, painfully, we end the lists with 320+ byte empty ...

While you're at it you should change to using ARRAY_SIZE() in the for loop, and use sizeof in the rtas call - that way you'll only have the size in one place. I notice pm_rtas_activate_signals() also allocates a pm_signal_local on the stack and iterates over it. I take it something guarantees that count in that routine will not exceed NR_PHYS_CTRS ? cheers --=20 Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie ...

Run sparse with -D__CHECK_ENDIAN__ to see these warnings. Harvey --

Hi David, On Fri, 24 Oct 2008 19:44:01 +0100 David Howells <dhowells@redhat.com> wrot= It would be good if you could have a "next" (or "creds-next" or something) branch in your tree and I can fetch that (that way I don't have to keep updating my configs). It is OK if thet branch rebases and may just be an alias for another branch (or a subset if you have experimental stuff in there. Remember "posted, reviewed, tested before it is in linux-next". Thanks. --=20 Cheers, Stephen ...

Your patch seems to fix it for me, so ack on that. Please do send a version with a sign-off when you're ok with it - otherwise I'll have to revert the old one.. Linus --

Well, I don't know how you do it but on powerpc, we explicitely fill the affinity masks at boot time when we can spread interrupts... Maybe we should change it the other way around and limit the mask when we can't ? It's hard to tell for sure at this stage. Ben. --

No it's not recoverable but I get the error messages and can write them That's exactly what happened. Felix --

As a additional measure you could make the timer deferred when in idle state. Then you would only actually do something when changing from idle to non idle or keeps being busy, but nothing when a CPU stays idle for a longer time. The frequency wouldn't necessarily be 1 second then though. -Andi --

it is more worse pci 0000:00:1c.3: scanning behind bridge, config 080800, pass 0 PCI: Scanning bus 0000:08 PCI: Fixups for bus 0000:08 PCI: bridge 0000:00:1c.3 io port: [5000, 5fff] PCI: bridge 0000:00:1c.3 32bit mmio: [c8000000, c9ffffff] PCI: bridge 0000:00:1c.3 64bit mmio pref: [cc000000, cdffffff] PCI: Bus scan for 0000:08 returning with max=08 that c800000 and cc00000 is allocated by BIOS... may need to set pci_mem_start to 0xc0000000. and let 0x1f.3 to use 0xca00000 YH --

Hi, It is not possible to modify anything from the bios at least nothing related to memory. So what do you suggest forcing the pci_mem_start. When I look at the dmesg file I find some open windows such as 0xc0000001 -> 0xdfffffff and 0xf0000001 -> to 0xfebffffff or something like that. --

Hello, this fixes my DVD, but unfortunately NCQ devices connected to PMP are still dead - apparently as soon as mount() tries to do serious I/O on the drive. Backing out both post-2.6.28-rc1 fix as well as your original change brings storage back. I suspect that problem is that with PMP same tag cannot be (should not be? must not be?) used on multiple devices behind PMP - and before your change tags were allocated per-port, while now they are allocated ...

Leftover from the dark-ages... needs fixing. --

You should apply this one patch before: ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-exception-stor... Mikulas --

Hello. I tried on Fedora 9 (gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)), and I got the same result. Just applying http://lkml.org/lkml/diff/2008/10/24/240/1 : ---------------------------------------- # cat /proc/version Linux version 2.6.27.3 (root@tomoyo) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Sat Oct 25 09:30:00 JST 2008 # ls -ail /sys/module/paramtest/parameters/ total 0 201 drwxr-xr-x 2 root root 0 2008-10-25 09:33 . 200 drwxr-xr-x 3 root root 0 2008-10-25 ...

Thanks a lot for testing and your patience! The patch below moves the init call to its old place but makes the stop_machine initialization happen later. I added a BUG_ON to catch possible early calls, but there shouldn't be any. I think the patch should solve the regression you are seeing. Could you give it a try please? The patch applies on top of latest Linus' git tree. Thanks, Heiko --- include/linux/stop_machine.h | 6 ++++++ init/main.c | 5 +++-- ...

[Empty message]

ACK. It would be nice to get this in... currently MAINTAINERS are hard to use :-( -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Since this function runs from the HRTIMER_SOFTIRQ, it enables interrupts before calling the hrtimer-callback function. This has been the original behaviour (see A above) We would like to retain this behavior for the normal cases where we don't want to emulate hard-irq context. So if you see below, all we're doing in the normal case is enabling the interrupts before calling the callback in the normal case, and keeping the interrupts disabled when we want to emulate the hard-irq ...

Hi Nico, "My" patch is definitely needed to make the X intel driver work with 2.6.28- rc1. Its a patch for X and not for the kernel. It might also help to work with suspend, because seemingly (according to In= tel=20 people) its not expected that the driver works with that bug. So try the patch I posted (which is out of the upstream development version= )=20 to make X work with 2.6.28-rc1 and continue testing if X works with 2.6.28- rcx. Andres

Both alpha #define irqs_disabled() (getipl() == IPL_MAX) and m68k static inline int irqs_disabled(void) { unsigned long flags; local_save_flags(flags); return flags & ~ALLOWINT; } do have irqs_disabled(), but they don't have irqs_disabled_flags(). M68knommu has both, but they don't check the same thing: #define irqs_disabled() \ ({ \ unsigned long flags; \ local_save_flags(flags); ...

Your VESA BIOS seems to have some serious braindamage (the fact that the modes don't list at all is evidence of that), but finding out what can be done to help it would be useful. Again, a git bisect between v2.6.24 and v2.6.26 would be best: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git cd linux-2.6.git git bisect start git bisect bad v2.6.26 git bisect good v2.6.24 <build and test kernel> git bisect <good,bad> <keep going until one commit ...

On Fri, Oct 24, 2008 at 11:01 PM, Bharata B Rao Reviewed-by: Paul Menage <menage@google.com> So in technical terms this patch looks fine now. There's still the question of whether it's OK to change the existing API, since it's been in the kernel in its currently (non-hierarchical) form for --

Try reversing this patch (apply with patch -p1 -R) James --- commit 10dab22664914505dcb804d9ad09cad6bc94d349 Author: Jamie Wellnitz <Jamie.Wellnitz@emulex.com> Date: Thu Sep 11 21:39:36 2008 -0400 [SCSI] sd: Fix handling of NO_SENSE check condition The current handling of NO_SENSE check condition is the same as RECOVERED_ERROR, and assumes that in both cases, the I/O was fully transferred. We have seen cases of arrays returning with NO_SENSE (no ...

[Adding CCs] --

Btw, this obviously implies that all stop_machine() users had better be later in the boot sequence. And no, I didn't check that exhaustively. There's the tracing infrastructure, and it's also core_initcall(), but it should be linked later. And module loading will happen later. mm/page_alloc.c has special code for bootup, and intel-rng.c should be a normal driver. So it _should_ be ok. But I really didn't test. And my default kernel config doesn't even have CONFIG_STOP_MACHINE ...

This one actually causes a regression for me on one of my machines. Don't ask me why, but it's very repeatable, and it goes away when that commit is reverted. See the appended commit that I have queued up (but not yet pushed out) in my tree for details.. Linus --- From: Linus Torvalds <torvalds@linux-foundation.org> Date: Sat, 25 Oct 2008 14:04:40 -0700 Subject: [PATCH] Revert "Call init_workqueues before pre smp initcalls." This reverts commit ...

Thank you for your positive opinion about my question I also hope cgroup framework has good point related with power management I think I need more re-consideration for it. ^^ How do you think about cgroup based management of new HW devices, for example, SSD, NVRAM and so on. Is there any requirement for it ? and is there any required work for it? I didn't seriously consider about that until now.^^ so I don't have cool idea but, I think it is worthy to find new domain to be applied by ...

I'm not convinced that you a real race exists, and even if it does, I'm not convinced that hacking the assembly entry/exit code is the best way to do it. Let me explain: You are concerned about a race in which a signal is delivered to a task that resumes from restart to user space and is about to (re)invoke 'pause()' (because the restart so arranged its EIP and registers). This almost always means that the user code is buggy and relies on specific scheduling, because you can usually ...

Hi Mauro, It's actually the other way around. open() is closed while unloading the Best regards, Laurent Pinchart --

At Sat, 25 Oct 2008 16:53:12 +0200, I think you are correct. The best solution would be to use the I don't think so. Go ahead, and let's check whether we see any problems on it. There might be some kconfig dependency issues, but this won't be a big problem, I guess. Thanks! Takashi --

| ------------------------------------------------------ Ugh. I must not have had enough coffee when I wrote this email. Never mind! :) -Joe --

Oh, ok, so the echo/bkl-drop one is in .28, and the other 2 in .29? Sounds good. Do you just queue them yourself, or are they in some other git now? -Joe --

should be fixed by in upstream.. already commit 1cf44baad76b6f20f95ece397c6f643320aa44c9 Author: Ingo Molnar <mingo@elte.hu> Date: Thu Sep 4 21:26:06 2008 +0200 IO resources: fix/remove printk Andrew Morton noticed that the printk in kernel/resource.c was buggy: | start and end have type resource_size_t. Such types CANNOT be printed | unless cast to a known type. | | Because there is a %s following an incorrect %lld, the above code will | crash the ...

Hi, Yes, that repo may be outdated, please use Pekka's for the latest If you enable kmemtrace at boot-time using the "kmemtrace.enabled=yes" parameter, kmemtrace will start logging just after kmem_cache_init() finishes. There are plans for making tracing possible even earlier, however it involves quite a big rework of how relay allocates its The userspace app writes out those messages when it looks like a memory region has been allocated twice. In reality, it's most likely a free I ...

but.. (tbench/netperf numbers were tested with gcc-4.1 at this time in log, I went back and re-measured ring-test because I switched compilers) 2.6.22.19-up ring-test - 1.204 us/cycle = 830 KHz (gcc-4.1) ring-test - doorstop (gcc-4.3) netperf - 147798.56 rr/s = 295 KHz (hmm, a bit unstable, 140K..147K rr/s) tbench - 374.573 MB/sec 2.6.22.19-cfs-v24.1-up ring-test - 1.098 us/cycle = 910 KHz (gcc-4.1) ring-test - doorstop ...

No. Those numbers are with TSO/GSO disabled. I did a manual 100% sched and everything related revert to 26 scheduler, and had ~the same result as these numbers. 27 with 100% revert actually performed a bit _worse_ for me than 27 with it's overhead.. which puzzles me greatly. -Mike --

From: Mike Galbraith <efault@gmx.de> I understand, this is what happened to me when I tried to look into the gradual tbench regressions since 2.6.22 I guess the only way to attack these things is to analyze the code and make some debugging hacks to get some measurements and numbers. --

My test data indicates (to me anyway) that there is another source of localhost throughput loss in .27. In that data, there is no hrtick overhead since I didn't have highres timers enabled, and computational costs added in .27 were removed. Dunno where it lives, but it does appear to exist. -Mike --

Part of the .27 regression was added scheduler overhead going from .26 to .27. The scheduler overhead is now gone, but an unidentified source of localhost throughput loss remains for both SMP and UP configs. -Mike My last test data, updated to reflect recent commits: Legend: clock = v2.6.26..5052696 + 5052696..v2.6.27-rc7 sched clock changes weight = a7be37a + c9c294a + ced8aa1 (adds math overhead) buddy = 103638d (adds math overhead) buddy_overhead = b0aa51b (removes math overhead ...

I have been currently looking at very similarly looking issue. For the public record, here are the numbers we have been able to come up with so far (measured with dbench, so the absolute values are slightly different, but still shows similar pattern) 208.4 MB/sec -- vanilla 2.6.16.60 201.6 MB/sec -- vanilla 2.6.20.1 172.9 MB/sec -- vanilla 2.6.22.19 74.2 MB/sec -- vanilla 2.6.23 46.1 MB/sec -- vanilla 2.6.24.2 30.6 MB/sec -- vanilla 2.6.26.1 I.e. huge drop for 2.6.23 (this ...

matthieu castet wrote: .. Heh.. I didn't even look at the patch itself. But if it is relying upon a whitelist to work, then it's broken by design. Most new USB drives will be supporting SAT, and requiring a kernel patch/update (or some other whitelist in userspace) is a silly way to support them. Cheers --

OK, thanks. I won't consider this as a regression, then. Rafael --