Hi, I tried to launch the function tracer with the latest -tip. With DYNAMIC_FTRACE (I just tried one time), I set "function" to current_trace and it blocks during writing. I can't even switch to another console. Without DYNAMIC_FTRACE I can set the tracer to function but it doesn't produce any trace, even on trace or tracing_pipe. My config is in attachment. I will try some revert...or some other tracers.

Sorry I sent a config for the mainline. This new one is the right.

EeePC 901, BIOS revision 1603, current Debian lenny; running on AC. I've noticed the following errors & exceptions, apparently coinciding with the startup of xfce4-sensors-plugin: ACPI: EC: missing confirmations, switch off interrupt mode. ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for [EmbeddedControl] [20080926] ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7030d38), AE_TIME ACPI Error (psparse-0524): Method parse/execution ...

Hello Nick, KVM is currently broken upstream, starting with commit db64fe02258f1507e13fe5212a989922323685ce (rewrite vmap layer) The symptoms are some vmallocs from kvm fail. cat /proc/meminfo shows this at the time of the fail: VmallocTotal: 122880 kB VmallocUsed: 15184 kB VmallocChunk: 83764 kB so there's plenty of space. The allocation that fails seem to be 512 bytes long. I'm not sure it always fails in there, but it seems so. --

From: Stephen Rothwell <sfr@canb.auug.org.au> /scratch/sfr/next/kernel/cgroup.c: In function 'cgroup_tasks_start': /scratch/sfr/next/kernel/cgroup.c:2107: warning: unused variable 'i' Introduced in commit cc31edceee04a7b87f2be48f9489ebb72d264844 "cgroups: convert tasks file to use a seq_file with shared pid array". Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: ...

Date: Fri, 12 Sep 2008 18:09:55 +0200 (CEST) From: Stefan Richter <stefanr@s5r6.in-berlin.de> Reported by Jay Fenlason: The iso packet control accessors in fw-cdev.c had bogus masks. Same as commit 7a1003449c693f0d57443c8786bbf19717921ae0. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/fw-cdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: ...

Date: Wed, 22 Oct 2008 00:28:36 +0200 (CEST) From: Stefan Richter <stefanr@s5r6.in-berlin.de> This optimizes firewire-sbp2's device probe for the case that the local node and the SBP-2 node were discovered at the same time. In this case, fw-core's bus management work and fw-sbp2's login and SCSI probe work are scheduled in parallel (in the globally shared workqueue and in fw-sbp2's workqueue, respectively). The bus reset from fw-core may then disturb and extremely delay the login and SCSI ...

Date: Fri, 12 Sep 2008 18:20:16 +0200 (CEST) From: Stefan Richter <stefanr@s5r6.in-berlin.de> Reported by Jay Fenlason: ioctl() did not return as intended - the size of data read into ioctl_send_request, - the number of datagrams enqueued by ioctl_queue_iso. Same as commit 99692f71ee04c6f249d0bf6a581359f32f409a38. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/fw-cdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: ...

From: Pekka Enberg <penberg@cs.helsinki.fi> This patch moves the static struct ieee80211_supported_band initialization out of w35_probe() because it's really global read-only configuration data. Cc: Pavel Machek <pavel@suse.cz> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- drivers/staging/winbond/linux/wbusb.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/staging/winbond/linux/wbusb.c b/drivers/staging/winbond/linux/wbusb.c index ...

With today's git host kernel I can no longer boot my Ubuntu virtual machine - udevd, modprobe etc. just die with glibc detecting realloc() errors (invalid next size) and I am dropped to initramfs prompt. Going back to the distro kernel 2.6.26 makes the same VM work again. Here is the command line - kvm -m 2048m -drive file=ubuntu.img,if=virtio,boot=on -net nic,model=virtio -net user -cdrom xubuntu-8.10-rc-desktop-i386.iso -boot c -redir tcp:2222::22 $ kvm QEMU PC emulator version 0.9.1 ...

From: Pekka Enberg <penberg@cs.helsinki.fi> This removes the macro magic from MLME_GetNextPacket() to de-obfuscate the code. Cc: Pavel Machek <pavel@suse.cz> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- drivers/staging/winbond/mlmetxrx.c | 22 ++++++++-------------- 1 files changed, 8 insertions(+), 14 deletions(-) diff --git a/drivers/staging/winbond/mlmetxrx.c b/drivers/staging/winbond/mlmetxrx.c index eab562a..a071855 100644 --- a/drivers/staging/winbond/mlmetxrx.c +++ ...

Hi, While running my http://vanheusden.com/pyk/ script (which randomly inserts and removes modules) I triggered the folllowing oops in a 2.6.26 kernel on an IBM laptop, pentium 2. Unfortunately I could not ...

From: David Brownell <dbrownell@users.sourceforge.net> The atmel_serial driver is mismanaging its clock by leaving it on at all times ... the whole point of clock management is to leave it off unless it's actively needed, which conserves power!! Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> --- drivers/serial/atmel_serial.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/serial/atmel_serial.c +++ b/drivers/serial/atmel_serial.c @@ -1258,6 ...

From: David Brownell <dbrownell@users.sourceforge.net> When recording the irq trigger type, let's also make sure that IRQ_LEVEL gets set correctly. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> --- So long as IRQ_LEVEL exists and is used through enable_irq() and setup_irq(), I suspect it should get set correctly! However, now that we record IRQ_TYPE_LEVEL_* maybe IRQ_LEVEL should vanish... kernel/irq/chip.c | 1 + kernel/irq/manage.c | 15 +++++++++------ 2 ...

From: David Brownell <dbrownell@users.sourceforge.net> We periodically waste time tracking down problems from the genirq framework not respecting IRQF_DISABLED for some shared IRQ cases. Linus views this as "will not fix", but we're still left with the bugs caused by this misbehavior. This patch adds a nag message in request_irq(), so that drivers can fix their IRQ handlers to avoid this problem. Note that developers will never see the relevant bugs when they run with LOCKDEP, so it's no ...

Patch 1 of 2 Regression introduced by commit 6ae5ce8e8d4de666f31286808d2285aa6a50fa40. This patch fixes a broken symlink in sysfs that was introduced by the above commit also called "cciss: remove redundant code." We broke it in 2.6.27-rc on or about 20080804. Some installers are broken if this symlink does not exist and they may not detect the logical drives configured on the controller. It does not require being backported into 2.6.26.x or earlier kernels. Please consider this for ...

On Mon, 27 Oct 2008 16:01:36 -0500 What's 2 of 2? cciss patches which I presently have queued are: cciss-fix-regression-firmware-not-displayed-in-procfs-again-and-again.patch cciss-new-hardware-support.patch cciss-fix-sysfs-broken-symlink-regression.patch --

From: Pekka Enberg <penberg@cs.helsinki.fi> Use the kernel built-in true and false boolean values instead of duplicating them in the driver code. Cc: Pavel Machek <pavel@suse.cz> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- drivers/staging/winbond/linux/common.h | 17 ------- drivers/staging/winbond/linux/wb35reg.c | 70 ++++++++++++++-------------- drivers/staging/winbond/linux/wb35rx.c | 2 +- drivers/staging/winbond/linux/wb35tx.c | 14 +++--- ...

When we failed to get tasklist_lock eventually (count equals 0), we should only print " ignoring it.\n", and not print " locked it.\n" needlessly. Signed-off-by: Qinghuang Feng <qhfeng.kernel@gmail.com> --- diff --git a/kernel/lockdep.c b/kernel/lockdep.c index dbda475..12bf812 100644 --- a/kernel/lockdep.c +++ b/kernel/lockdep.c @@ -3417,10 +3417,12 @@ retry: } printk(" ignoring it.\n"); unlock = 0; + goto print_locks; } if (count != 10) printk(" locked ...

Hi, Just to keep you updated: I've fixed further bugs. The code survived concurrent kernel compiles and cpu online/offline on a 4-cpu system. The code tries to minimize the operations between call_rcu() and the final rcu destruction callback. It should achieve a lower latency than the current rcu backends, but I haven't written a benchmark yet. Comments are welcome. -- Manfred

hmmmm, I used to see something similar on ICH7 but it went away. Can you try various strategies associated with interrupts (trying to determine the cause of the timeouts), such as booting with "noapic", "acpi=off", and/or pci=biosirq. Jeff --

This driver supports the Xilinx XPS GPIO IP core which has the typical GPIO features. Signed-off-by: Kiran Sutariya <kirans@xilinx.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: John Linn <john.linn@xilinx.com> --- V2 - Updated based on Anton's comments V3 - Cleaned up Kconfig badness in patch generation and added Grant's signoff drivers/gpio/Kconfig | 8 ++ drivers/gpio/Makefile | 1 + drivers/gpio/xilinx_gpio.c | 235 ...

Pulled from Linus's git today so it is a 2.6.28-rc2+ kernel and this is still a regression I was able to hit. -Eric --

NAK. The existing line is correct because the _module_ is called nfs_acl.ko. Trond --

From: Gerald Schaefer <gerald.schaefer@de.ibm.com> My last bugfix here (adding zone->lock) introduced a new problem: Using pfn_to_page(pfn) to get the zone after the for() loop is wrong. pfn then points to the first pfn after end_pfn, which may be in a different zone or not present at all. This may lead to an addressing exception in page_zone() or spin_lock_irqsave(). Using the last valid page that was found inside the for() loop, instead of pfn_to_page(), should fix this. Signed-off-by: ...

We only return -EBUSY if pfn < end_pfn, but after completing the loop w/o a break pfn will be > end_pfn. Also, the last call to __first_valid_page() may return NULL w/o causing a break, so page may also be invalid after the I think pfn will always be > end_pfn if we complete the loop. And breaking Calling __first_valid_page() again might be a good idea. Thinking about it now, I guess there is still a problem left with my patch, but for reasons other than what you said :) If the loop is ...

Ouch, stupid Thunderbird broke the patch (or stupid me used Thunderbird...), will send a new one. Gerald --

applied to tip/sched/urgent, thanks Jiri! Ingo --

These two patches make use of __acpi_nmi_disable() to make possible to: - enable and disable IOAPIC NMI watchdog using procfs - disable NMI generation if the NMI watchdog is not working on boot time -- Aristeu --

okay - they look reasonable so i've applied Aristeu's patches to tip/x86/apic and integrated them into tip/master, we'll see how they work out. Please Ack/Nak them once you have the time to have a close look. Ingo --

Linus, please pull from the for-linus branch at git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus to receive the following FireWire subsystem updates. They fix long- standing bugs, among them a quite visible panic. It's very new stuff but stress-tested. Jay Fenlason (4): firewire: Survive more than 256 bus resets firewire: fix struct fw_node memory leak firewire: fw-ohci: don't leak dma memory on module removal firewire: ...

Hi, So I managed to bisect my suspend to RAM regression in 2.6.27-rc2 to commit 3b7ee69d0caefbdb85a606a98bff841b8c63b97e ("mac80211: disassociate when moving to new BSS") by Tomas Winkler (Cc:-ed). Unfortunately it doesn't revert cleanly so I can't double check it. My laptop is a Vaio FZ240E Core2Duo@2GHz and I use the iwlagn module for the wireless connection. The symptom is that suspending to RAM from inside X with 'echo mem > /sys/power/state' leaves me a black screen when resuming ...

If you have quilt installed, you can do: $ git show 3b7ee69d > suspicious.patch $ quilt import -R suspicious.patch $ quilt push (that should work without rejects) and build the kernel. Thanks, Rafael --

Hmmhh, I still have the problem when removing the mac80211 and other wireless modules before s2ram... Soeren --

[Added some CCs] Carlos, thanks a lot for bisecting this. Johannes, can you pls have a look? Thanks, Rafael --

And that makes even less sense :) johannes

I wanted to do it with git, but gave up after some time :-( So I finally read the commit in question 3b7ee69d0caefbdb85a606a98bff841b8c63b97e and applied the patch below, which reverts it up to the whitespace fixes. And reverting it really made my brand new 2.6.28-rc2-something work again, regarding suspend to RAM. So consider it confirmed that this commit is guilty here. --- net/mac80211/mlme.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git ...

Can someone try this one (it might be space broken I've just pasted that in) It's on top of 1d63e726408dfdb3e10ed8f00c383b30ebb333d3 (latest linux-2.6.git) diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c index 24a1aeb..321dbc8 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c @@ -2090,7 +2090,6 @@ static void iwl_alive_start(struct iwl_priv *priv) iwl4965_error_recovery(priv); ...

Ok, but that means you _can_ get messages, it would help a lot if you could put a few printks into the set_disassoc function before/after each other function call, so we know where exactly it hangs. Pretty much all of them could possibly hang if there is some sort of locking error happening or anything relies on userspace to be running... johannes

The only thing I can remotely think of is that iwlwifi doesn't like being called back from within the call that it did to mac80211, which obviously happens here. But I have no idea, the code as it stands is correct, just the interaction with iwlwifi's resume seems to be broken. Try this patch instead: +++ everything/drivers/net/wireless/iwlwifi/iwl-agn.c 2008-10-27 19:44:15.0= 00000000 +0100 @@ -2084,7 +2084,6 @@ static void iwl_alive_start(struct iwl_p ...

Done. --

Ok, I humbly tried to do that with the patch at the end of the email, but I did not appear to hang in this function tough. Somehow I could get some messages printed when it was a black screen before (I think it has to do with the debug level I set with SysRq...) and I could see all the printks I've put there. The good thing is that I could get the complete syslog of the boot until the it failed after suspending to RAM (in 2.6.28-rc2 with my debug patch below applied). The last messages ...

h Definitely I would post it to wireless and stable. I would like to hear from Harvey, though if this is somehow related to b43 as well. I will it give some more testing tomorrow morning I don't have any HW right now and need to suspend to bed :) Again, sorry for troubles. Tomas --

Good, this was actually part of some older and bigger patch I wasn't aware it has this affect. It has some millage in iwl5000 branch. RFKIll went through some changes in the mainline so it wasn't merged yet. commit a91ad840c23a70bc0eabe239e178e0d979a6d44e Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Mon Jun 30 17:48:26 2008 +0300 iwlwifi: bug fixes in RF-kill flows --

OK, I can try and do that tomorrow when I'm at the desktop again, I have the dock there serial console. -- Jens Axboe --

Hmm, this looks like a result of playing with the magic SysRq. Did you try to press SysRq-something when the box became unresponsive? Rafael --

I double checked it. Linus' tree v2.6.28-rc2-58-g1d63e72 does not work, whereas --

No messages appear, just a black screen. But I can use the SysRq keys, and when I umount the screen shows the message that umount succeed. I also tried SysRq+t but --

When fixing up invalid years rtc_read_alarm() is callign rtc_valid_tm() as a boolean but rtc_valid_tm() returns zero on success or a negative number if the time is not valid so the test is inverted. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- drivers/rtc/interface.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index 7af60b9..a04c1b6 100644 --- a/drivers/rtc/interface.c +++ ...

Unfortunately I added the __devexit_p() annotation in response to Alessandro's comments. I'll remove it again, other than that all that's changed is a tweak to the module description and Andrew's change to use schedule_timeout_uninterruptible(). How should these drivers be merged? --

This adds support for the RTC provided by the Wolfson Microelectronics WM8350. This driver was originally written by Graeme Gregory and Liam Girdwood, though it has been modified since then to update it to current mainline coding standards and for API completeness. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- This revision: - Marks remove() with __devexit_p() - Fixes grammar in MODULE_DESCRIPTION() which should address all the feedback from Alessandro. ...

No, don't -- that's why I said "this code is fine..." !! You're not using platform_driver_probe(), so it's appropriate to Andrew is the keeper of the RTC patch queue, so I suggest you issue one patch against the two in MM: rtc-rtc-wm8350-add-support-for-wm8350-rtc.patch rtc-rtc-wm8350-add-support-for-wm8350-rtc-fix.patch That would probably cause the least amount of extra work for Andrew. - Dave --

The comment about probe()/__devinit and remove()/__devexit/__devexit_p isn't right ... when the driver uses platform_driver_probe(), the "__dev" variants should not be used. (It's a Good Thing to shrink runtime code footprints, by using platform_driver_probe for non-hotpluggable devices.) Also: rtc_ops.ioctl() method should only handle RTC_{AIE,UIE}_{ON,OFF}, since the other standard ioctls have rtc_ops equivalents. (This code is fine in both respects. Though since I've received ...

This driver implements support for the watchdog functionality provided by the Wolfson Microelectronics WM8350, a multi-function audio and power management subsystem intended for use in embedded systems. It is based on a driver originally written by Graeme Gregory, though it has been extensively modified since then. Use of a GPIO to kick the watchdog is not yet supported. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- Changes since last submission (which should address ...

Signed-off-by: Alan Cox <alan@redhat.com> diff --git a/drivers/message/i2o/exec-osm.c b/drivers/message/i2o/exec-osm.c index 56faef1..06c655c 100644 --- a/drivers/message/i2o/exec-osm.c +++ b/drivers/message/i2o/exec-osm.c @@ -19,7 +19,7 @@ * Auvo Häkkinen <Auvo.Hakkinen@cs.Helsinki.FI> * Deepak Saxena <deepak@plexity.net> * Boji T Kannanthanam <boji.t.kannanthanam@intel.com> - * Alan Cox <alan@redhat.com>: + * Alan Cox <alan@lxorguk.ukuu.org.uk>: * Ported to Linux 2.5. ...

Yes, just the parent must process the event (signal). In your testcase the parent finished before the signal could be delivered. If the tracer exits the Fixed the races in your code and I do not see there any problem, do you? The ptrace problems/testsuite is being maintained at: http://sourceware.org/systemtap/wiki/utrace/tests Regards, Jan

Hi, While running my http://vanheusden.com/pyk/ script (which randomly inserts and removes modules) I triggered the ...

Actually... MSI does seem to be working for my ethernet. $ grep eth /proc/interrupts 44: 2446 PCI-MSI-edge eth1 DRM wasn't using MSI in 2.6.27 though. So I'm still doubtful that the MSI issue is really an "*ERROR*". Thanks Alan --

This means that something went wrong with our detection of the CPU-versus-GPU tiling swizzling mode, and object tiling under GEM will be disabled as a result. I should get access to an eee 7xx on Thursday to see what's up with it -- it's supposed to be just a normal 915gm as Looks like we emit the error message even if your chipset doesn't support MSI. That's a mistake, I'll get it cleaned up. (MSI didn't actually get supported for integrated graphics until the G965 for the desktop and ...

It was only used by two SGI platforms which recently were converted to RTC_LIB and with RTC_LIB enabled the legacy drivers are no more selectable. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> --- arch/mips/Kconfig | 5 - arch/mips/configs/ip22_defconfig | 1 - arch/mips/configs/ip28_defconfig | 2 - drivers/char/Kconfig | 11 - drivers/char/Makefile | 1 - drivers/char/ds1286.c | 585 -------------------------------------- ...

Looks good. --

It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. Signed-off-by: Dave Chinner <dgc@sgi.com> Signed-off-by: Takashi Sato <t-sato@yk.jp.nec.com> --- fs/xfs/linux-2.6/xfs_ioctl.c | 15 --------------- fs/xfs/linux-2.6/xfs_ioctl32.c | 2 -- fs/xfs/xfs_fs.h | 4 ++-- 3 files changed, 2 insertions(+), 19 deletions(-) diff -uprN -X linux-2.6.28-rc2-freeze/Documentation/dontdiff ...

The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. ...

-- Bäste umu.se konto Användare, Det här meddelandet är från MMS-centralen till alla våra umu.se e-post konto ägare. Vi håller för närvarande på att uppgradera vår databas och e- postkonto Center. Vi vill ta bort alla våra umu.se e-postkonton för att skapa mer utrymme för nya konton. För att förhindra att dina umu.se konto från nedläggning måste du uppdatera det, under så att vi vet att det är en närvarande används konto. Vi har varit att skicka detta meddelande till alla våra ...

This is also happening with my Vaio, and 2.6.27 works fine suspending to RAM from inside X. I was silent about this issue (it happened before -rc1) because I really did not have the time to bisect it, which I think is the best way to solve this issues quickly. I will try to bisect it in the next days, but I can't promiss anything. --

Applied, thanks. -- Jiri Kosina SUSE Labs --

Usbhid structure is allocated on start invoked only from probe of some driver. When there is no driver, the structure is null and causes null-dereference oopses. Fix it by allocating the structure on probe and disconnect of the device itself. Also make sure we won't race between start and resume or stop and suspend respectively. References: http://bugzilla.kernel.org/show_bug.cgi?id=11827 Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: ...

This is strange, it compiles OK on ARM, I don't know why this failed on x86-64. But anyway, <linux/workqueue.h> should really be explicitly included here. The attached patch should fix this. - eric -----Original Message----- From: Jean Delvare [mailto:khali@linux-fr.org]=20 Sent: Monday, October 27, 2008 4:45 PM To: Mike Rapoport; Eric Miao; Richard Purdie Cc: LKML; Linus Torvalds Subject: CONFIG_LEDS_DA903X=3Dm breaks 2.6.28-rc2-git1 build on x86-64 Hi Mike, Eric, Richard, With ...

All kernel memory which is used for kernel/hardware data transfer must be registered with firmware using "memory regions". 16GB hugepages may not be part of a memory region due to firmware restrictions. This patch modifies the walk_memory_resource callback fn to filter hugepages and add only standard memory to the busmap which is later on used for MR registration. Signed-off-by: Thomas Klein <tklein@de.ibm.com> --- This reworked patch accounts for comments I got. It's based on davem's ...

Dave, thanks for your valuable comments - see mine below. I'll send a reworked patch asap. Thomas I decided to just rename the var to nr_pages as it is used in all other busmap-related functions in our code. That makes the condition check quite Thanks for this comment. I totally agree - and I'm happy to aerate it a bit. I don't agree at this point. The 16GB hugepages we're dealing with here are imho a different thing than the hugetlb stuff. Furthermore as far as I can see the ...

After commit a1d35a7a (cirrusfb: use modedb and add mode_option parameter), these variables are no longer used, so remove them to fix compilation warning. Signed-off-by: Vlada Perić <vlada.peric@gmail.com> CC: Krzysztof Helt <krzysztof.h1@wp.pl> --- drivers/video/cirrusfb.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/video/cirrusfb.c b/drivers/video/cirrusfb.c index 048b139..ace4001 100644 --- a/drivers/video/cirrusfb.c +++ b/drivers/video/cirrusfb.c @@ -2462,8 ...

--nextPart3480442.bVZSW9GQNi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline i'm hoping my understanding of ptrace is correct and that the attached test= =20 case (reduced from LTP) isnt just completely broken ... my understanding is= =20 that if a parent forks and the child does a ptrace(TRACEME) right before=20 doing an exec(), the kernel should always halt it and wait indefinitely for= =20 the parent to start ...

ia32_setup_rt_frame() has a duplicated code block labelled "Make -mregparm=3 work" for setting up the register parameters to the user-mode signal handler. This is harmless but ugly. Remove the redundant assignments. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> --- arch/x86/ia32/ia32_signal.c | 5 ----- 1 file changed, 5 deletions(-) diff -rupN linux-2.6.28-rc2/arch/x86/ia32/ia32_signal.c linux-2.6.28-rc2.x86-signals-fixes/arch/x86/ia32/ia32_signal.c --- ...

Ingo Molnar writes: > > * Mikael Pettersson <mikpe@it.uu.se> wrote: > > > Fix 2.6.28-rc2 build failure on i386 with CONFIG_PCI=n: > > > +#ifdef CONFIG_PCI > > if (!strncmp(p, "allowdac", 8)) > > forbid_dac = 0; > > if (!strncmp(p, "nodac", 5)) > > @@ -210,6 +211,7 @@ static __init int iommu_setup(char *p) > > forbid_dac = -1; > > return 1; > > } > > +#endif /* CONFIG_PCI */ > > there's a better fix for this queued up in the PCI tree, see: > > ...

there's a better fix for this queued up in the PCI tree, see: http://marc.info/?l=linux-kernel&m=122480590627590&w=2 Ingo --

This patch is a fix for Bugzilla bug http://bugzilla.kernel.org/show_bug.cgi?id=11796. To summarize, a simple testcase is concurrently running an infinite loop on msgctl(IPC_STAT) and a call to msgget(): while (1) msgctl(id, IPC_STAT) 1 | | | 2 id = msgget(key, IPC_CREAT) | | | In the ...

??? The bad new, is that it becomes unreprodicible on my side. For my part, I've got 2 2.8 GHz Xeon CPUs. Will review the code once more. Thanks! -- Nadia Derbey <Nadia.Derbey@bull.net> --

At Mon, 27 Oct 2008 18:19:33 +1100, Aye, sir! :) Takashi --

On Mon, 27 Oct 2008 18:17:25 +1100 Yes, not many build problems (in randconfigs). linux-next-20081027/drivers/staging/go7007/go7007-v4l2.c:1457: error: 'VI D_TYPE_CAPTURE' undeclared here (not in a function) This happens if: CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m # CONFIG_VIDEO_ALLOW_V4L1 is not set # CONFIG_VIDEO_V4L1_COMPAT is not set <<<<<<<<<< CONFIG_DVB_CORE=m CONFIG_VIDEO_MEDIA=m full config attached. -- ~Randy

On Mon, 27 Oct 2008 18:17:25 +1100 This blasted build problem is back. Are there any outstanding patches in this area? build-r5284.out:hp-plus.c:(.text+0x2b99a): undefined reference to `eip_interrupt' build-r5284.out:hp-plus.c:(.text+0x2ba0d): undefined reference to `eip_open' build-r5284.out:hp-plus.c:(.text+0x2baef): undefined reference to `eip_close' build-r5284.out:hp-plus.c:(.init.text+0x38ee): undefined reference to `NS8390p_init' build-r5284.out:(.init.text+0x3948): undefined reference ...

Acked-by: Steven Rostedt <srostedt@redhat.com> -- Steve --

Hi Ingo, I think (from a comment from DaveM) that it led into a real mess. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Several bug fixes: 1) Skb ->when timestamp setting for syncookies got messed up by TCP option building engine changes in 2.6.27. Fix from Florian Westphal I'll submit this thusly to -stable as well. 2) Couple places trying to pass sk_buff to kfree() instead of kfree_skb(). Fixed by Sergio Luis 3) Two fixes for the new phonet protocol layer from Remi Denis-Courmont Please pull, thanks a lot. The following changes since commit ...

In my test, I found that if a cpu has been offline, the next cpus may not be shown in the /proc/cpuinfo. if one read() cannot consume the whole /proc/cpuinfo file, c_start() will be called again in the next read() calls. And *pos has been increased by 1 by the caller(seq_read()). if this time the cpu#*pos is offline, c_start() will return NULL, and the next cpus can not be shown. this fix uses next_cpu_nr(*pos - 1, cpu_online_map) to search the next unshown cpu. the way to reproduce this ...

A local definition of devid in autofs_dev_ioctl_ismountpoint() shadows the fuction wide definition. Signed-off-by: Ian Kent <raven@themaw.net> --- fs/autofs4/dev-ioctl.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c index a040639..e19d584 100644 --- a/fs/autofs4/dev-ioctl.c +++ b/fs/autofs4/dev-ioctl.c @@ -597,17 +597,17 @@ static int autofs_dev_ioctl_ismountpoint(struct file *fp, magic = ...

Return value and argument of block_device_operations.release of gdrom was changed. This patch fix this problem. Signed-off-by: Nobuhiro Iwamatsu <iwamatsunigauri.org> --- drivers/cdrom/gdrom.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c index 9aaa86b..2eecb77 100644 --- a/drivers/cdrom/gdrom.c +++ b/drivers/cdrom/gdrom.c @@ -495,9 +495,10 @@ static int gdrom_bdops_open(struct block_device *bdev, fmode_t ...

I've got a few questions about this approach. The most logical way to do this seems to be: 1) Leave the epoll_wait with the EPOLLIN|EPOLLOUT event flags and use epoll_ctl to switch the interest mask for each fd between EPOLLIN and EPOLLOUT on a per fd basis. 2) When I'm ready to write, I do a write and if it does not fully write and I get the EAGAIN flag, I switch the fd with epoll_ctl(fd,MOD,EPOLLOUT). However, I get strange behavior when I tried adding fd's with only the EPOLLIN ...

lol, I was a bit tired when I wrote that. Ok, ignore the stuff related This is good to know. So, I've got a few questions about what happens to data that accumulates while I am sending and the fd is set to EPOLLOUT? If I am send out a large buffer and incoming data wants to stream in on a full duplex connection, what happens to that data when I am processing the socket while it is in epollout mode? Is the following accurate? When data comes in while I am sending, I guess the ...

Since when are IPv4 addresses "usually" printed in colon-separated hex? -hpa --

Sure. I'll build on top. Harvey --

On Mon, 2008-10-27 at 12:59 -0700, Harvey Harrison wrote: The changes to use %p4 aren't too bad. I did that last year using a similar style to print_mac. 80 or so files. http://repo.or.cz/w/linux-2.6/trivial-mods.git?a=shortlog;h=refs/heads/print_ipv4 ipv6 was 30 or so files I think length would not be good addition. print_dump_hex already does a fine job. There are also BE/LE expectation problems with pW. The %p6 pointer should be in6_addr * The %p4 pointer should be __be32 ...

HIPQUAD is horrible and should disappear. Just use htonl first. I think just %p4 %p6 %#p6 for the NIP6_SEQFMT uses. --

%#pI4 is horrible and %p4 and %p6 were cool. --

Add format specifiers for printing out six colon-separated bytes: MAC addresses (%pM): xx:xx:xx:xx:xx:xx %#pM is also supported and omits the colon separators. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- Dave, this passes testing here, but I was wondering if perhaps it would be better to allow a length to be specified as well, which would allow: %pM6 for mac addresses, etc as there seem a lot of places in kernel that print out a list of colon separated bytes of ...

Did you happen to have a preference with regard to the specifier for IPv6 addresses: I was thinking of using %pI6 to replace NIP6() and NIP6_FMT and using %#pI6 for NIP6_SEQFMT. On the IPv4 side, maybe use %pI4 for network endian NIPQUAD() and NIPQUAD_FMT and then %#pI4 for host-endian HIQUAD(), as displaying the IPv4 address without the periods isn't useful? What do you think of that? Harvey --

The # for ipv4 we might use for cpu-endian rather than network-endian maybe? Also can you keep mac/ip address patches split up so we can use my version of the mac address patch (it's already well-tested)? johannes

On Sun, Oct 26, 2008 at 4:46 PM, Diego M. Vadell can you try 2.6.28-rc2 ot tip/master and boot with mtrr_cleanup_debug ? YH --

Well, in the end it comes down to the same thing: SMM expects the memory map to reside in MTRRs. We can "sanitize" the memory map, but we can't throw it out the window like what we really should be able to. -hpa --

On Sun, 26 Oct 2008 17:21:41 -0700 yeah.. one thing we need to investigate is if we can set the default "no mtrr coverage" value to cached (and also.. to check we don't set that to uncached if the bios had it set to cached..) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for ape savings, visit http://www.lesswatts.org --

Hello, I think I have hit something similar on a box running nbd-server to export a 3 SATA disk raid0 block device over Gigabit Ethernet. Increasing min_free_kbytes got rid of the messages for me... Though the load on your system is much higher than on mine. Regards Cláudio --

The allocation is 'mode:0x10000', which is __GFP_NOMEMALLOC. That means the allocation doesn't have __GFP_WAIT, so it cannot do reclaim, it doesn't have __GFP_HIGH so it can't access some emergency reserves. The DMA stuff is special, and part of it is guarded for anything but __GFP_DMA allocations. You just ran the system very low on memory, and then tried an allocation that can't do anything about it.. I don't find it very surprising it fails. The 'bug' if any, is having such a poor ...

Good idea, for example bootgraph.pl matches the case, if Arjan agrees. --

Ok it's corrected thanks to the trace sent by Steven. Here is a V2. --- From: Frederic Weisbecker <fweisbec@gmail.com> Subject: [PATCH] ftrace: Add a script to produce a hierarchical view of a function trace This script parses a function trace and then produces a hierarchical view of the function call stack after processing it into a tree. Changes on V2: _ Support both the files "trace" and "trace_pipe" (comments and space differences) _ Correct the mini HOW-TO at the ...

On Mon, 27 Oct 2008 11:27:57 +0100 bootgraph.pl is sort of borderline since it also works without tracing but I'm not opposed to it if it makes scripts/ more organized --

Right, but it could also be sleeping in any other wait_event(), Please post the full patch, it'd be a lot better to see the big picture instead of just a small part of it. Thanks, Miklos --

The description is missing some details: why is the filesystem frozen before suspend? AFAICS this can happen when DM calls bdev_freeze() on the device before the task freezing begins. Is this the case? Also, while the patch might solve some of the symptoms of the fuse vs. process freezer interaction, it will not fully fix that problem. As such it's just a hack to hide the problem, making it less likely to appear. So I'm not at all conviced about this patch. Thanks, Miklos --

Hi Miklos. It doesn't matter why a process is sitting in that wait_event call. What does matter is that one can be there. In the case where I saw it, I was working on fuse freezing. I don't remember the details, as it's a year No, it's part of the solution. I haven't posted the full fuse freezing patch because I thought this could be profitably merged without the rest of the patch. Regards, Nigel --

Hi. Sorry. You're right - I was confusing things in what I said, but I do have a (unconfused) solution: The answer is to freeze the fuse filesystems first, stopping new requests (freezing the processes making them) before they are passed on to userspace and allowing existing requests to complete or freeze. Once that is done, the userspace fuse processes will be idle, at least as far as fuse activity is concerned. After fuse activity is stopped, userspace can be frozen without worrying ...

For the record: the driver depends on MTD_JEDECPROBE && 8260, where 8260 is filed under "82xx-based boards" in PowerPC. I don't know if we have that much compile tests for this particular arch. http://l4x.org "only" lists cell_defconfig and g5_defconfig... C. -- BOFH excuse #167: excessive collisions & not enough packet ambulances --

Really? It will still break if your AP uses one of those channels, right? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

There is a commit in MTD git fixing this build issue http://git.infradead.org/mtd-2.6.git?a=commit;h=f04de505e3fa322728d1a851e08bf7060b117743 Thank you, Alexander

Hi Wim, Yeah, thanks for spotting that. I was a bit in hurry while creating the patch ... I'll come up with an updated patch with the suggestions from Vivek. Probably tomorrow. Regards, Bernhard -- Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development --

.write() and .mmap() were not serialized against each other and against .ioctl() at all in raw1394 before 2.6.28-rc1. Only .ioctl() was (somewhat) serialized against itself due to traditionally being implemented as .ioctl() instead of .unlocked_ioctl(). If there were ever concurrent userspace contexts accessing the same file handle, they would have corrupted raw1394's internal state eventually. Application developers have been advised all the time to access the file handle only from a ...

PS: There is a need for serialization to some degree because the client registers itself with a controller via .write() (among many other things that are implemented through .write()), manages isochronous I/O contexts on this controller via .ioctl() and maps DMA buffers for isochronous I/O via .mmap(). The raw1394 driver tracks respective state by means of two state variables and some other variables, and accesses of the state variables is not reentrant within one opener of /dev/raw1394. ...

I was trying to recreate this error using ata_ram wth v2.6.28-rc2. Currently I am not able to see this error on timeout recovery using this setup. Does IO load (or other factors) effect the error being seen? -andmike -- Michael Anderson andmike@linux.vnet.ibm.com --

From: Sergio Luis <sergio@larces.uece.br> Also applied, thanks Sergio. --

From: Sergio Luis <sergio@larces.uece.br> Since this is pretty obvious I'm applying this directly, I hope Marcel doesn't mind :-) --

Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> --

Arjan, so newer kernels require CRDA and iw to set regulatory domain, otherwise only the world regulatory domain is set so if your AP is not in the world regulatory domain it won't connect. To enable the other channels you need CRDA and iw installed. http://wireless.kernel.org/en/developers/Regulatory/CRDA http://wireless.kernel.org/en/users/Documentation/iw Drivers can also hint to CRDA as per the API a country and in those cases only CRDA is required, however right now only zd1211rw is ...

Luis, Arjan's bug is actually indicative of a driver bug, he told me that he actually runs into driver message like "cannot set TX power while scanning", and it's fixed by setting WIRELESS_OLD_REGULATORY for some reason. Arjan, do you still have the actual messages you get when it fails? That's a separate bug we should address, rather than relying on it not happening with the old regulatory setting. johannes

a belated Acked-by - thanks Randy! Ingo --

-rc2 should be better at that. :-) Thanks, Rafael --

Thanks, closed. Rafael --

Technically you neither need autoconfiguration nor CONFIG_ROOT_NFS. With an initrd/initramfs you can do the whole procedure from userspace. And AFAIR a few years back those options where on the brink of beeing deprecated for just that reason. Just my 2 cents. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- ...

Hi, Thanks for looking into this. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> bye, Roman --

indeed w/ -rc2 the mouse works fine. Re' fn-keys the path in /sys changed to /sys/module/hid_apple/parameters/fnmode ... Soeren --

ok - i've queued up the patch below in tip/tracing/urgent, thanks guys. Ingo From 5209f08dc8e5f520ca81b87fa9a7142f58a109f4 Mon Sep 17 00:00:00 2001 From: Jonas Bonn <jonas.bonn@gmail.com> Date: Sat, 25 Oct 2008 11:49:20 +0200 Subject: [PATCH] asm-generic: define DIE_OOPS in asm-generic Impact: build fix DIE_OOPS is now used in the generic trace handling code so it needs to be defined for all architectures. Define it in asm-generic so that it's available to all by default and ...

The XFS tree used for linux-next got a bit out of whack and I couldn't make sense of the mess so I've been using a different tree for the mainline pull requests. We'll have this mess sorted out soon. --

Ah, OK. I fixed the commit log. Thanks, Subject: [PATCH 1/2] ext3: fix a bug accessing freed memory in ext3_abort Vegard Nossum reported a bug which accesses freed memory (found via kmemcheck). When journal has been aborted, ext3_put_super() calls ext3_abort() after freeing the journal_t object, and then ext3_abort() accesses it. This patch fix it. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Acked-by: Jan Kara <jack@suse.cz> --- fs/ext3/super.c | 10 ...

Hi Vegard, Thank you for reporting this regression. It's my fault. I send patches to fix. Regards, Subject: [PATCH 1/2] ext3: fix a bug accessing freed memory in ext3_abort Vegard Nossum reported a bug which accesses freed memory. When journal has been aborted, ext3_put_super() calls ext3_abort() after freeing the journal_t object, and then ext3_abort() accesses it. This patch fix it. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> --- fs/ext3/super.c | 10 ...

could you please put the word "kmemcheck" into the commit log? ("found via kmemcheck" or so) We want to have an easily git-greppable track record of upstream kernel bugs that were found via kmemcheck. (and there's already a long list) Ingo --

Vegard Nossum reported a bug which accesses freed memory. When journal has been aborted, ext4_put_super() calls ext4_abort() after freeing the journal_t object, and then ext4_abort() accesses it. This patch fix it. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> --- fs/ext4/super.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) Index: linux-2.6.28-rc2/fs/ext4/super.c =================================================================== --- ...

But for long-term the HPQ0004 specific things in the lids3v driver should get merged with your HP leds driver also registering for HPQ0004 and the lids3v specific things should get a separate driver which HPQ0004 driver makes use of? Kay may know whether this should work and how. IMO having several drivers registering for the same HID should get avoided if possible, it's confusing. Thomas Pavel: I am also not sure whether it's a good idea to mis-use the HP's LED for mail ...

There is currently no driver core support to bind two "struct device" to one parent "struct device" from different drivers. You can work around that by creating a custom "struct bus_type", create the several function devices there, and let them bind different drivers. This is what matches a lot of hardware like custom devices all hiding behind a single PCI device. Or the code for the two functions must live in the same driver, and create class devices, so it looks to the core like a single ...

Yes indeed, and thank you. Stephen has already suggested a fix, I just need to do some code, build, and test once I get to Smack time. --

All, Indeed the kernel cmdline option security=none did disable smack. So atleast that works. Thank you all for helping me track this down. I can now return to updating packages (some of which have been waiting patiently for this to be cleared up)! Though I will be looking forward to this feature working as it was intended. ;) Let me know if there is a bug # assigned and I'll quietly return to lurking... ;) -- Rob --

Yes, there is at least one bug there; this kernel is broken. You may want to try booting with a kernel command line option like "security=none", which *should* turn smack off. Andreas --

yes, at every step the kernel is expected to build and boot fine. Ingo --

Thanks for your very useful comments and feedback. I've included a few Out of curiosity what exactly do you mean when you say "fragile"? Sorry That sounds reasonable, I will play around, write a few, and probably OK, I'll try to use more descriptive names. As hpa pointed out in his email, 'p' is the name of the field in the intel x86 documentation. I will probably continue to play around with it and try to resubmit something in a few days that incorporates your feedback. I've ...

please do _NOT_ call anything like this a "backdoor", anywhere in the source or the commit log. "Backdoor" is most commonly used for intentional security holes, and we dont want anything like that in the kernel code. What this code implements is not a backdoor, it is simply a facility to discover the hypervisor environment, not a "backdoor". Ingo --

okay, this looks a lot better structurally - the DMI angle and the synthetic CPU flag, and the clocksource smarts are all a clean approach. Peter, any objections? Ingo --

I was referring to the extract_data helper inline, it's only used ~5 times and doesn't add much (IMO) over just opencoding it. Cheers, Harvey --

That 1024 is supposed to effectively be infinity. Printk is intended to be a largely line-oriented facility. If you're printing something large enough that you even have to ask yourself 'hmm, how big a buffer can I print?', you're printing something -way- too large. First, I don't think it's accurate to apply the adjective 'critical' to a facility that's existed in mainline for mere days, while sysfs itself has existed many years. Second, I didn't pull it out of my ass, actually. I did a ...

It's critical for debugging *new* things like PCI domain support, that people Does your system have multiple NUMA nodes, cascaded PCI bridges, and multipathed fibre channel storage? The point of this debugging feature is to help debug the cases that are *not* trivial. Your workstation probably isn't very interesting Showing the last 20 characters doesn't help in a highly repetitive file hierarchy where how you got there may be more important than where you ended up. I agree with ...

I've applied this, but it does add the following warnings, which I don't think you want to have: drivers/staging/at76_usb/at76_usb.c:885: warning: ‘at76_set_associd’ defined but not used drivers/staging/at76_usb/at76_usb.c:903: warning: ‘at76_set_listen_interval’ defined but not used drivers/staging/at76_usb/at76_usb.c:989: warning: ‘at76_add_mac_address’ defined but not used I'll remove these unused functions now from the in-kernel version. Is there any way to do development on this in ...

Hi, Now in the -nmw GFS2 git tree. Thanks, Steve. --

ahh, I see now. - k --

While we have the comment the code appears not to really follow it. We appear to write 1 << hard_smp_processor_id(). - k --

Change UV heartbeat function to use idle_cpu to determine cpu's "idleness". Realign uv_hub definitions. Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/include/asm/uv/uv_hub.h | 26 +++++++++++++------------- arch/x86/kernel/genx2apic_uv_x.c | 4 ++-- 2 files changed, 15 insertions(+), 15 deletions(-) --- test-tip-latest.orig/arch/x86/include/asm/uv/uv_hub.h +++ test-tip-latest/arch/x86/include/asm/uv/uv_hub.h @@ -128,19 +128,19 @@ struct uv_scir_s { * They are kept ...

Thanks for the heads up! Yes, -rt is supported. Might as well avoid that problem now. Signed-of-by: Mike Travis <travis@sgi.com> --- arch/x86/kernel/genx2apic_uv_x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- test-tip-latest.orig/arch/x86/kernel/genx2apic_uv_x.c +++ test-tip-latest/arch/x86/kernel/genx2apic_uv_x.c @@ -372,7 +372,7 @@ static void uv_heartbeat(unsigned long i bits ^= SCIR_CPU_HEARTBEAT; /* is this cpu idle? */ - if ...

applied to tip/x86/uv, thanks Mike! Please send the cpu_idle() cleanup patch separately. Another minor thing i noticed: @@ -130,7 +140,9 @@ struct uv_hub_info_s { unsigned char blade_processor_id; unsigned char m_val; unsigned char n_val; + struct uv_scir_s scir; please align the new field vertically, like they were aligned before - by adding another tab to the whole lineup. (This will also make it appear nicer when viewed together with followup definitions below this ...

Hi Andi, Sorry, I didn't see this message until now. I will look into doing this and ask the hw group if it's acceptable to drop BMC records when the cpu is idle. (I think they may still want them since this might also be confused with "the cpu is no longer uninterruptible".) Thanks, Mike --

Yeah, that was a misunderstanding between Heiko and me. I planned it for 2.6.29 and didn't tell him about it before I left for vacation. Heiko Ok, thanks. Less confused now. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --

okay, then i'm confused, the subject line says v2.6.28: [GIT PULL] s390 updates for 2.6.28-rc1 it's just a historic/quirky connection (non-executable stack was the first and biggest step towards a more flexible address space layout) - you were correct to have it cleaned up. Ingo --

No. It went through same story as without patch - first it declared drive #2 hung, after port reset drives #0,1,2 were declared hung, after second port reset drive #2 was declared dead, after third port reset drive #3 was hung, after fourth reset it said that /dev/sde changed capacity from 0 to 1TB, and at that point I decided that it is time to hit alt-sysrq-b to prevent damage... Also I think that this change leaks memory a bit... Petr Petr --

No, it doesn't. It was convenient to reuse that mechanism, but I can easily re-add something else (which would be more or less identical). J --

On Fri, 24 Oct 2008 13:58:58 -0700 As I wrote, the patch doesn't look correct (I think that the first patch is fine if some arch want to use __BIOVEC_PHYS_MERGEABLE but no one in mainline overrides BIOVEC_PHYS_MERGEABLE): http://lkml.org/lkml/2008/10/27/1 --

On Mon, 27 Oct 2008 20:18:44 +1100 I still don't see how Xen needs something like the virtual merge (sounds that overriding BIOVEC_PHYS_MERGEABLE perfectly works for Xen) or why Xen needs a new boot parameter for it. The virtual merge just defines how IOMMUs should work. --

Alright, then add a xen_biovec_phys_mergeable(vec1, vec2) in the xen code that actually checks this for real. You can add your switch there as well. Then put the BIOVEC_PHYS_MERGEABLE() in the xen arch includes, done. What Tomo is saying is that this has nothing to do with virtual merging, and he's right. -- Jens Axboe --

On Fri, 24 Oct 2008 13:59:06 -0700 This doesn't look correct. The block layer always done the physical merge if possible. We don't provide any kernel parameter to disable it. The iommu_bio_merge parameter had been used to enable the virtual merge. As I wrote, the virtual merge feature was completely removed. Effectively, the iommu_bio_merge parameter is meaningless now. --

Hi, Paul, Thanks, we do not have problems with this at the moment. I suddenly had an association of ideas to synchronize_srcu(), so I made use of the ideas in synchronize_srcu() and this patch was made. --

plus there are also the fixlets below. Ingo --------------> From a14b735fb7a82bb6561449dda4067365af7ee95c Mon Sep 17 00:00:00 2001 From: Rusty Russell <rusty@rustcorp.com.au> Date: Thu, 23 Oct 2008 14:35:31 -0700 Subject: [PATCH] cpumask: fixlets [ from Mike ] Here are the only changes I could find from Rusty's last patches that apply to tip/cpus4096-v2. * Fix NR_CPUS reference in arch/powerpc/platforms/cell/spu_base.c * modify arch/x86/Kconfig so CONFIG_NR_CPUS is always ...

ok - applied it to tip/cpus4096-v2, thanks Rusty! If there's any chance for this in v2.6.28 then only if we disable the dynamic API branch altogether [CONFIG_MAXCPUS] and keep that for v2.6.29. This means we'd bring in the API changes which should have trivial impact only - and none of the riskier changes. Hm? Andrew, have we missed the boat on this? Ingo --

the sched_init() slab corruption bug is still there, i just triggered it on two separate test-systems: [ 0.510620] CPU1 attaching sched-domain: [ 0.512007] domain 0: span 0-1 level CPU [ 0.517730] groups: 1 0 [ 0.520528] ============================================================================= [ 0.524002] BUG kmalloc-8: Wrong object count. Counter is 11 but counted were 50 [ 0.524002] ----------------------------------------------------------------------------- [ ...

applied to tip/x86/signal, thanks! Ingo --

Once I added ehci_hcd to my initrd, which ensured that it was loaded first, the error messages seem to have disappeared. If they return, I'll open a new thread. Thanks for the help, Larry --

Yes. It's also suitable for use with git-send-email --cc-cmd Some examples picking a random file (drivers/net/b44.c): Get maintainers for a single file (this includes git -by: signatories and the script does a sort | uniq so the maintainer is not listed first) $ ./scripts/get_maintainer.pl -f drivers/net/b44.c "Miguel Botón" <mboton@gmail.com> Gary Zambrano <zambrano@broadcom.com> Jeff Garzik <jeff@garzik.org> Jeff Garzik <jgarzik@pobox.com> John W. Linville ...

applied to tip/x86/urgent, thanks Cliff! Ingo --

good catch - applied to tip/x86/cleanups, thanks Dan! Ingo --

Evgeniy, Some comments / fixes below. Probably better: ... except creation of hard and symbolic links, and rename events. This is the number of times that a transaction will be resent to a server that did not answer for the last @trans_scan_timeout "a single" "controls" "the working set" I've stopped here for the moment. There are many other cases below where an article ("a" or "the" is needed) -- this matters because without the right ...

On Thu, 23 Oct 2008 13:33:35 -0500 It is 100% unclear (to me) why this change is being made. Apparently this is considered a needed-in-2.6.28 change. But I don't know why. If I knew that then I'd be in a better position to work out whether it is also needed in 2.6.27.x, to which it also applies cleanly. IOW: better changelogs, please. --

Ingo, I'm not quite sure what you mean here. Are you referring to an explicit call to exit_idle() that is done somewhere else (such as do_IRQ())? --

Thanks guys! Neil -- /**************************************************** * Neil Horman <nhorman@tuxdriver.com> * Software Engineer, Red Hat ****************************************************/ --

i've updated the commit, thanks. Ingo --

On Sat, 25 Oct 2008 08:38:52 -0700 Hmm..how about having 2 params as "aggregated usage" and "private usage" ? cpuacct.usage. cpuacct.all_subtree_usage. heavy ? -Kame --

On Mon, Oct 27, 2008 at 10:13 AM, Bharata B Rao If a particular application desires to derive the usage of its immediate tasks and does not care about subcgroups, it is a simple iteration (after this fix) cpuacct - sigma(cpuacct_child) and currently if we cared about child accounting, we could do cpuacct + recursively(sigma(cpuacct_child)) In that sense this fix makes more sense, but like Paul said we need to figure out if it is an API change. My take is that it is a BUG fix, That ...

I think one reason is, cpu_cgroup_subsys has to be initialized very early, and at that time kmalloc() is not usable, so we use statically defined init_task_group. --

On x86, maybe. On powerpc it's as expensive as mb(). Paul. --

Do you have performance measurements for this ? On x86 it's a nop, Hrm, I think this will utterly slow down the batch registration/unregistration. Can you try to register 100 markers in batch on a loaded machine (e.g. running tbench on all cores) and see how long it takes ? Comparing before/after your patch would be welcome. I have merged the modules_mutex, tracepoint_mutex and marker_mutex in the -lttng tree. It makes locking much much simpler and actually fixes an issue we currently have ...

On Thu, 23 Oct 2008 10:35:22 +0800 Why is it unnecessary? Does this change alter behaviour in any way? Does it fix a bug? --

ok - although the cleanups Rusty did look independent to me. We can just keep it in mind for the future, the whole topic is complex enough already as-is. Ingo --

small sidenote: please preserve feedback/review activities in the changelog, even if there is no delta patch. I have added this to the changelog: v2: fix i386 bug, noticed by Andrew Morton Ingo --

No problem, we can forget about it. My goal was to produce some statistics to locate the points that most often hold the bkl. That would help to define some priorities on which bkl holding is to remove first. But if that would be better to rather invest the time on the kill-the-bkl tree (which I thought was dead), so I would be pleased to help. --

[ Resending patch. Sam, can you Ack this? -- Steve ] From: Steven Rostedt <srostedt@redhat.com> Subject: ftrace: handle generic arch calls The recordmcount script requires that the actual arch is passed in. This works well when ARCH=i386 or ARCH=x86_64 but does not handle the case of ARCH=x86. This patch adds a parameter to the function to pass in the number of bits of the architecture. So that it can determine if x86 should be run for x86_64 or i386 ...

applied to tip/tracing/urgent, thanks Frederic! Ingo --

Hm, where in the code can I change it to return less that what it thinks is the last sector? No luck. I'm going to try 2.6.28-rc2 now. Regards, Luciano Rocha -- Luciano Rocha <luciano@eurotux.com> Eurotux Informática, S.A. <http://www.eurotux.com/> --

This looks exactly like the "infinite retry" problem I warned about earlier. Here are the important parts of the log. For people who don't know how to interpret these messages, the CDB starts in the 16th byte of the 31-byte messages. For example, the first command here The response is 0x2e9390b0. In typical broken fashion, that is undoubtedly the total number of sectors rather than the highest sector number. Later on the system tries to read the contents of what it thinks is the ...

Okay, I tried the same sort of experiment in 2.6.27.4 and got the same result as you did. I was able to fix it by applying the 8bfa24727 commit mentioned earlier together with the patch below. Now, I'm pretty sure this is not the ideal solution. Fixing the block core would be better. Still, it does indicate for sure that there's a real problem. It's worth noting that the test added to scsi_requeue_command() succeeds every time, that is, req->retries is always 0. Clearly more work ...

Now in 2.6.27.4, same problem. The usb traffic is: f7161ec0 3564884672 C Ii:1:005:1 0:2048 1 = 02 f7161ec0 3564884690 S Ii:1:005:1 -115:2048 1 < f20138c0 3564884706 S Ci:1:005:0 s a3 00 0000 0001 0004 4 < f20138c0 3564885023 C Ci:1:005:0 0 4 = 01010100 f20138c0 3564885039 S Co:1:005:0 s 23 01 0010 0001 0000 0 f20138c0 3564885273 C Co:1:005:0 0 0 f20138c0 3564885291 S Co:1:005:0 s 23 03 0016 0001 0000 0 f20138c0 3564885522 C Co:1:005:0 0 0 f20138c0 3564885534 S Ci:1:005:0 s a3 00 0000 0001 ...

Window$ never reads the last sector unless it is actually written to. I had such a device it got stuck when I wrote to the That would be udev or hald, I can't remember which. It is a special Linux Boaz --

We thought of that years ago. Unfortunately there is no reliable way of telling when a capacity value is wrong. There definitely do exist disks with an odd number of sectors. Furthermore, doing I/O to a suspect block is not a good idea. There are plenty of devices which simply crash when you try to access a I imagine they do. However Linux has partition code that stores information in the last sector of a partition (EFI GUID and md, for example). Other OS's apparently do not try to ...

Heh, I already did this on my own. thanks, greg k-h --

That's because I forgot to send the following patch. Sorry about that. Pekka From 564d8ad6fd7b72ac7b5c10ebc56b5c3180cd9cc0 Mon Sep 17 00:00:00 2001 From: Pekka Enberg <penberg@cs.helsinki.fi> Date: Wed, 22 Oct 2008 18:29:13 +0300 Subject: [PATCH] w35und: usb urb wrapper removal This patch removes the useless wb_usb_{submit|alloc}_urb() wrappers from driver code. Cc: Pavel Machek <pavel@suse.cz> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- ...

I still get the following errors with this patch applied: CC [M] drivers/staging/winbond/./linux/wb35reg.o drivers/staging/winbond/./linux/wb35reg.c: In function ‘Wb35Reg_BurstWrite’: drivers/staging/winbond/./linux/wb35reg.c:29: error: implicit declaration of function ‘wb_usb_alloc_urb’ drivers/staging/winbond/./linux/wb35reg.c:29: warning: assignment makes pointer from integer without a cast drivers/staging/winbond/./linux/wb35reg.c: In function ...

You'll have the powertop police on your tail. --

From: ebiederm@xmission.com (Eric W. Biederman) So let's figure out what happens with this patch. I'm personally ok with the change, the question is when and where. My net-2.6 tree was closed to new features long ago, so I really don't want to try to merge this sucker into 2.6.28-rcX :-) But if you guys think that is prudent, feel free to submit it directly to Linus and add my signoff: Signed-off-by: David S. Miller <davem@davemloft.net> otherwise if we shoot for 2.6.29 I would suggest ...

Yes, that is true, but userspace doesn't have to write to those files That's fine, you can still use the same interface, no problems. Just use the "async" version of the firmware interfae and you will be fine. thanks, greg k-h --

OK. That points a finger at the garbage collector. Does the following patch help at all? Cheers Trond ------------------------------------------------------------------------ From: Trond Myklebust <Trond.Myklebust@netapp.com> Date: Mon, 27 Oct 2008 11:43:48 -0400 SUNRPC: Fix rpcauth_prune_expired We need to make sure that we don't remove creds from the cred_unused list if they are still under the moratorium, or else they will never get garbage collected. Signed-off-by: Trond ...

On Thu, Oct 23, 2008 at 4:11 AM, Luis R. Rodriguez This is now fixed on the master branch, also the branch "for-upstream" does a lot of cleanup I thought you may like before stuffing it into staging like removing all KERNEL_VERSION checks, all wireless extensions checks, some compile warnings, removal of compat, dos2unix, use utf-8, etc. Unfortunately this still requires a specific version of wpa_supplicant but it seems it works. Not sure what bars you have for staging at this point. Will ...

Can you send me your .config, please? I'm trying to duplicate it on my end. - Ted --

On Fri, 24 Oct 2008 00:00:17 +0900 (JST) Or we change the callers of lru_add_drain_all() to call it without holding any locks. I mean, what's the *point* in calling it with mmap_sem held? That won't stop threads from adding new pages into the Because it's pretty sad to add yet another kernel thread on each CPU (thousands!) just because of some obscure theoretical deadlock in page-migration and memory-hotplug. Most people don't even use those. --

Done. Now, I think smp_call_function() is better for this issue. I'll try it. --

Yeah, I know, and the cpu-hotplug discussion needed another thread due to yet another locking incident. I was hoping these two could go together. Neither are general-purpose workqueues, both need to stay away from the normal eventd due to deadlocks. ego, does you extra thread ever use mmap_sem? --

What you mention is already included in 2.6.28 merge window. I think we can use this feature on NVRAM, too. I think it's not cgroup controller's role but each subsystem's one. As you can see above article, Many mainline guys try to improve performance in each subsystems. Do you have a scenario or idea how to use cgroup frame work to manage -- Kinds regards, MinChan Kim --

Yeah since akpm's review a few days back, a few things have been rearranged resulting in this figure blowing out to 13k on AVR32. Obviously not acceptable so I'm looking for a nicer way around this. So long as I allow the interrupt to be shared that should work fine (assuming gpio_to_irq returns the irq of the chip-wide pin change signal for all pins on the chip). akpm pointed out that sysfs_notify() cannot be called from interrupt context so now all irqs are really taken as Right. ...

If the calling process has signal_pending() (eg: someone typed ^C) then I'll switch those to schedule_timeout_uninterruptible(), OK? --

Hi, Thanks for your answer. I will eventually add a netconsole, but for now, I find how to bypass my problem (getting debug information). However I come with a new question, related to an unexpected VM-exit. The scenario is as follows: 1. some setup occur 2. vmlaunch is executed by a function F, so the guest is launched. This guest (as I explained in my previous mail) executes the end of the function F. 3. The end of F, do some "printk" then return to the module init function. The ...

If most setuid programs hold privileged resources for extended periods of time after dropping privileges then it seems like a good idea to refuse to checkpoint. Restart of those programs would be quite How will folks not specializing in checkpoint/restart know when to use this as opposed to deny? Instead, how about a flag to sys_checkpoint() -- DO_RISKY_CHECKPOINT -- which checkpoints despite !may_checkpoint? Cheers, -Matt Helsley --

True. And this works very well for HPC applications. However, it doesn't work so well for server applications, for instance. Also, you could use file system snapshotting to ensure that the file system view does not change, and still face the same issue. So I'm perfectly ok with deferring this discussion to a later time :) --

Oren, is this a good place to stick a process_deny_checkpoint()? Both so we refuse to checkpoint, and document this as something that has to be addressed later? -- Dave --

This sounds like an awful lot of policy to determine *inside* the kernel. Everybody is going to have a different definition of risky, so this scheme will work for approximately 5 minutes until it gets patched. :) Is it possible to enhance our interface such that users might have some kind of choice on these matters? -- Dave --

I don't know about the context, but SGID bits for directories are not magic, they mean the newly created files will inherit GID from the parent directory, and if the file is actually a subdirectory, it will also have SGID set. The same was also true WRT SUID bits on some systems. -- Krzysztof Halasa --

Are we sure that should_remove_suid() is not and never will used for What's wrong with blockdevs triggering this path? --

This has been broken since 2.6.26. Nobody noticed because there is no way of enabling CONFIG_HDPU_FEATURES in Kconfig. I wonder what's up with that. --

I noticed that don't take the appropriate locks when browsing through tasks lists (siblings, children, global list). Although I realize that the container should be frozen at this time, I keep wondering if this is indeed always safe. For instance, are you protected against an OOM killer that might just occur uninvited and kill one of those tasks ? Can the administrator force an un-freeze of the container ? Or perhaps Here too. [...] Oren. --

Small bits of it have to be inside the kernel - Markup (_("Hello") To extract the strings) - To format the data in a way that can be recovered by ksyslogd and translated. Alan --

Ok, understood. Not that the reaction surprises me, seems like nobody likes documentation (including me). What I will do is to replace the kmsg_xxx macros with the pr_xxx macros in the device drivers patches and request the pull as a cleanup for 2.6.29. The out-of-tree kmsg patches will then play tricks with pr_xxx analog to dev_xxx. That way the patch should be minimal. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --

You really don't want 32 languages in mixed left/right rendering with multiple fonts in your kernel source. At least not with most editing and viewing tools.... User space uses message catalogues and has tools for maintaining them which make using any other format somewhat dumb. They extract strings using _("hello") type wrappers to identify what are translatable strings so if the kernel source has _() macros all the tooling just works and can live outside and way from the kernel. Just ...

On Mon, 27 Oct 2008 12:19:23 -0400 As I said a few months ago, please make it "almost kernel-doc style" but something that can be distinguished from the current kernel-doc. They aren't quite the same thing AFAICT. -- ~Randy --

OK but the error bits are cleared as soon as the status has been reported, which is in the command response or, in the case of timeout, the response to the next command. Reading the status after that shows nothing. The status would have to be fished out of brq->mrq.cmd->resp[0]. ETIMEDOUT is a special case because it is not a hint for the error, it is I don't have SPI, so I can't test it. AFAICT timeouts are not meant to happen with SPI so it is a genuine error. The SPI error ...

Are there any objections to this patch? The problem has been reproduced in 2.6.18 and 2.6.27, so existing changes in the gart code have not addressed it. The patch disarms a landmine left behind for the kdump kernel. You could leave it there and warn people not to step there, or you can disarm it so it isn't a danger. Thank you, --

i_mode read not protected by i_mutex in should_remove_suid() and we may have race condition with chown(). Sorry, seems I've been too crazy about this. The truth is: 1: No one will call truncate() and chown() concurrently. 2: This race is still possible regardless to this fix. --

Test with 2.6.28-rc2, run wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf, kernel warning triggered: [ 1648.091084] ------------[ cut here ]------------ [ 1648.091090] WARNING: at net/mac80211/rx.c:2201 __ieee80211_rx+0x1d0/0x5f0 [mac80211]() [ 1648.091094] Modules linked in: rfcomm l2cap bluetooth container fuse ath5k mac80211 led_class psmouse serio_raw sg cfg80211 e100 mii intel_agp agpgart thermal button processor thermal_sys evdev [ 1648.091127] Pid: 0, comm: swapper Not tainted ...

done - find the tip/tracing/urgent commit below. I also added an Impact: line. Ingo ----------------> From 8115f3f0c939c5db0fe3c6c6c58911fd3a205b1e Mon Sep 17 00:00:00 2001 From: Steven Rostedt <rostedt@goodmis.org> Date: Fri, 24 Oct 2008 09:12:17 -0400 Subject: [PATCH] ftrace: use a real variable for ftrace_nop in x86 Impact: avoid section mismatch warning, clean up The dynamic ftrace determines which nop is safe to use at start up. When it finds a safe nop for patching, it sets ...

Sure, and "[PATCH 2/4] Identify which executable object the userspace address belongs to" is independent of the lock tracing part too. Perhaps I should send these 2 patches as 3 separate patches: - introduce save_stack_trace_user in arch/ - the ftrace parts for user stack tracing (userstacktrace >iter_ctrl) - the sym-userobj part (which is useful if you got ASLR, otherwise you don't have a chance to resolve the symbols later after the app is gone) I promised the lock contention tracepoints ...

should be this one: f66af45: tracepoint: check if the probe has been registered Ingo --

There ya go, happy benchmarking is when they tell you what you want to hear. Successful is when you learn something. -Mike (not happy, but learning) --

How many clients? dbench 160 -t 60 2.6.28-smp (git.today) Throughput 331.718 MB/sec 160 procs (no logjam) Throughput 309.85 MB/sec 160 procs (contains logjam) Throughput 392.746 MB/sec 160 procs (contains logjam) -Mike --

We'll need to look into this a little bit more I think. I have sent out some numbers too, and these indicate very clearly that there is more than 50% performance drop (measured by dbench) just after the very merge of CFS in 2.6.23-rc1 merge window. -- Jiri Kosina SUSE Labs --

From: Ingo Molnar <mingo@elte.hu> This I heavily disagree with. The scheduler should be so cheap that you cannot possibly notice that it is even there for a benchmark like tbench. If we now think it's ok that picking which task to run is more expensive than writing 64 bytes over a TCP socket and then blocking on a read, I'd like to stop using Linux. :-) That's "real work" and if the scheduler is more expensive than "real work" we lose. I do want to remind you of a thread you participated ...

From: Evgeniy Polyakov <zbr@ioremap.net> Yes, this situation was in my opinion a complete fucking joke. Someone like me shouldn't have to do all of the hard work for the scheduler folks in order for a bug like this to get seriously looked at. Evgeniy's difficult work was effectively ignored except by other testers who could also see and reproduce the problem. No scheduler developer looked seriously into these reports other than to say "please try to reproduce with tip" (?!?!?!) I guess ...

My test system has 8gb for 8 clients and its performance dropped by 30%. There is no IO load since tbech uses only network part while dbench itself uses only disk IO. What we see right now is that usual network server which handles mixed set of essentially small reads and writes from the socket from multiple (8) clients suddenly lost one third of Right now there is no disk IO at all. Only quite usual network and process load. -- Evgeniy Polyakov --

http://www.netperf.org/svn/netperf2/trunk/src/netsec_linux.c Pointers to programtatic detection of AppArmour and a couple salient details about firewall (enabled, perhaps number of rules) from any Plot thickening, seems that autotest knows about some version of netperf2 already... i'll be trying to see if there is some benefit to autotest to netperf2's top of trunk having the keyval output format, and then I guess I'll close with successful benchmarking, if not necessarily ...

From: Evgeniy Polyakov <zbr@ioremap.net> I think the hope is that by saying there isn't a problem enough times, it will become truth. :-) More seriously, Ingo, what in the world do we need to do in order to get you to start doing tbench runs and optimizing things (read as: fixing the regression you added)? I'm personally working on a test fibonacci heap implementation for the fair sched code, and I already did all of the cost analysis all the way back to the 2.6.22 pre-CFS days. But I'm ...

On Sun, 26 Oct 2008 19:41:09 +0100 -- ~Randy --

nice! No fundamental objections - Len, do you concur? We could carry this in the ftrace tree, the impact on the rest of the kernel is minimal. the defines should be an enum and please put a newline after the enum this should be HAVE_POWER_TRACER defined in arch/x86/Kconfig, instead s/analyize/analyse __read_mostly ? Ingo --

Unless Britsh English is different, which I do not know. s/analyse/analyze/ ;-) --

On Mon, 27 Oct 2008 16:59:21 +0100 there's other tracers that have a similar depends other than that, updated patch below: From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] ftrace: Add a C/P state tracer to help power optimization This patch adds a C/P-state ftrace plugin that will generate detailed statistics about the C/P-states that are being used, so that we can look at detailed decisions that the C/P-state code is making, rather than the too high level ...

Yeah, this should be converted to a trace_point. See include/trace/sched.h for examples. The users are in kernel/sched.c. Just add "trace_" in front of the names to find the users. Then you can look at kernel/trace/trace_sched_switch.c to see an example on how to hook into it. -- Steve --

So it does seem to operate correctly. I combined it with my patch and applied against 2.6.27 for ease of testing. One question -- why the multi-line format? This would be a bit awkward on a 128-CPU system, let alone on a 4,096-CPU system. --

i've picked up your fixes into tip/x86/corruption-check: b43d196: x86: corruption-check: some post-move cleanups 304e629: x86: corruption check: run the corruption checks from a work queue 6784f7d: x86: corruption check: move the corruption checks into their own file 04d2aac: x86: corruption-check: fix some style issues thanks Arjan! Ingo --

Why does the caller have a reference count? I don't see we increase the reference count after the 'dev' is returned by following in pci_get_dev_by_id(): dev = bus_find_device(&pci_bus_type, dev_start, (void *)id, match_pci_dev_by_id); And this 'dev' becomes the 'from' in the next loop, but it may be --

The 'dev' returned by pci_get_device() may be destroyed by PCI hotplug. I suppose that passing this 'dev' to pci_get_device() in the next loop would crash the system, right? --

Erm, no, the 'dev' cannot be destroyed because the caller has a refcount on it. The physical device backing it might have gone away. The dev won't be destroyed until its reference count reaches zero, which could be any time someone calls pci_dev_put() on it. In the scenario you're postulating, it would happen in pci_get_dev_by_id(): if (from) pci_dev_put(from); which is the last time that 'from' is referred to in that callchain. -- Matthew Wilcox Intel ...

How about pci_get_bus_and_slot()? People would meet the problem with it anyway. Thanks, Yu --

In OpenVZ we are creating first task and namespaces from sys_restart. --

Well, AFAICS from Oren's patch set his approach is oriented on process creation in user space. I think we should choose right now what approach will be used for process creation. We have two options here: fork processes in kernel or fork them in user space. If process will be forked in user space, then there will be a gap when process will be in user space and can be killed with received signal before entering kernel. Also we will need a functionolity to create processes with predefined ...

Hello Tejun! After my short reply I had a 2.6.27 running with [-- Attachment #2: sata_nv-nf2-hrst-debug-take2.patch --] fine so far. It bootet immediately at any time I powercycled the machine. Hot, cold and reboot seems to be no problem, no /var/log/messages flooding also. I just wanted to inform you, whatever the investigations result into, on _my_ machine this incarnation is just fine. Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 ...

As a paravirt front-end driver, virtio_blk is not a rotational device so we want do avoid idling in AS/CFQ. Tell the block layer about this. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> --- diff -urNp linux-2.6.28-rc2-orig/drivers/block/virtio_blk.c linux-2.6.28-rc2/drivers/block/virtio_blk.c --- linux-2.6.28-rc2-orig/drivers/block/virtio_blk.c 2008-10-27 17:41:53.000000000 +0900 +++ linux-2.6.28-rc2/drivers/block/virtio_blk.c 2008-10-27 17:34:32.000000000 +0900 @@ -237,6 ...

All three patches look fine, although we could just reuse QUEUE_FLAG_NONROT directly. But I agree it makes sense to make the distinction, so I've just applied 1-3. -- Jens Axboe --

Agreed. Perhaps a good change to make while introducing stall detection to preemptable RCU -- there would then be three examples, which should allow good generalization. Thanx, Paul --

In keeping with my reputation as a "conservative programmer", I would suggest that rcuclassic.c remain for a year or so. Distros branching off during this time should continue making rcuclassic.c be the default. Other uses should have rcutree.c as the default. At the end of the year, we remove rcuclassic.c. All that said, one attractive aspect of your suggestion is immediately removing rcuclassic.c would eliminate the need to do further work on it. ;-) Your benchmarking proposal for ...

My interest in SAS/SATA RAID controllers (e.g. cciss and megaraid) is to get to the physical drives and let smartmontools query them. The first difficulty is addressing physical drives within the logical drive presented to the OS. Then there are SATA drives: I have yet to see a SAT implementation good enough to fetch useful SMART data using "pure" SCSI commands; that leaves the SAT ATA PASS-THROUGH commands. Testing I did today on a HP E200 controller with version 1.80 firmware and the cciss ...