This is a documentation followup to 2e591bbc0d563e12f5a260fbbca0df7d5810910e Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- Documentation/initrd.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt index d3dc505..0c48110 100644 --- a/Documentation/initrd.txt +++ b/Documentation/initrd.txt @@ -85,7 +85,7 @@ involve special block devices or loopbacks, you merely create a directory on disk with ...

Added module parameter "poll_mode_io" to support for "polling" (reduced interrupt operation). In this mode, IO completion interrupts are delayed. At the end of initiating IOs, the driver schedules for cmd completion if there are pending cmds. A timer-based interrupt has also been added to prevent IO completion from being delayed indefinitely in the case that no new IOs are initiated. The user is expected to tune the interrupt throttling parameters using MegaRAID utility and then set p...

MegaRAID utilities expect sense_buff to be of type unsigned long. Signed-off-by: Bo Yang <bo.yang@lsi.com> --- drivers/scsi/megaraid/megaraid_sas.c | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c --- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01 05:20:03.000000000 -0700 +++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c ...

Adding module parameters to configure max sectors per request & # of cmds per lun. Signed-off-by: Bo Yang <bo.yang@lsi.com> --- drivers/scsi/megaraid/megaraid_sas.c | 68 ++++++++++++++++++++++++- drivers/scsi/megaraid/megaraid_sas.h | 2 2 files changed, 68 insertions(+), 2 deletions(-) diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c --- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01 00:1...

Adding hibernation support. suspend, resume routine implemented. Signed-off-by: Bo Yang <bo.yang@lsi.com> --- drivers/scsi/megaraid/megaraid_sas.c | 302 +++++++++++++++++++------ drivers/scsi/megaraid/megaraid_sas.h | 1 2 files changed, 233 insertions(+), 70 deletions(-) diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c --- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-10-01 00:03:59.000000000 -0700...

I said I was hoping that -rc8 was the last -rc, and I hate doing this, but we've had more changes since -rc8 than we had in -rc8. And while most of them are pretty trivial, I really couldn't face doing a 2.6.23 release and take the risk of some really stupid brown-paper-bag thing. So there's a final -rc out there, and right now my plan is to make this series really short, and release 2.6.23 in a few days. So please do give it a last good testing, and holler about any issues you find! This ...

The following is the cleaned up patch implementing the power management quality of service infrastructure discussed at the pm summit last June. It is a genralization of the latency code put into the kernel last year by Arjan. I would like to get this code included in the MM tree and to get some milage on it. One thing to note about this implementation is that it exposes an interface to user space for registering pm_qos constraints in addition to the kernel exports. Its a file based interface ...

Currently, the set_lazy_mode pv_op is overloaded with 5 functions: 1. enter lazy cpu mode 2. leave lazy cpu mode 3. enter lazy mmu mode 4. leave lazy mmu mode 5. flush pending batched operations This complicates each paravirt backend, since it needs to deal with all the possible state transitions, handling flushing, etc. In particular, flushing is quite distinct from the other 4 functions, and seems to just cause complication. This patch removes the set_lazy_mode operation, and adds "ente...

I've been trying to track down some unexpected realtime latencies and believe one source is a bug in the wakeup code. Specifically, this is within the try_to_wake_up() routine. Within this routine there is the following code segment: /* * If a newly woken up RT task cannot preempt the * current (RT) task (on a target runqueue) then try * to find another CPU it can preempt: */ if (rt_task(p) && !TASK_PREEMPTS_CURR(p, rq)) { struct rq *this_rq = cpu_rq(this_cpu); /* * ...

The update was tested extensively on 6042. I have a 7042, but haven't The IOMMU data point is certainly interesting. Nothing jumps out on a re-review of the patch, so keep digging and let us know ;-) Jeff -

Pliant 'FastSem' semaphore implementation (as oppsed to 'Sem') uses 'yield' http://old.fullpliant.org/ Basically, if the ressource you are protecting with the semaphore will be held for a significant time, then a full semaphore might be better, but if the ressource will be held just a fiew cycles, then light aquiering might bring best result because the most significant cost is in aquiering/releasing. So the aquiering algorithm for fast semaphores might be: try to aquire with a hardware atomic ...

On Mon, 1 Oct 2007 16:35:11 -0500 Since you are using a vendor supplied kernel, you need to talk to them. 2.6.9 is almost 3 years old. -

The calculation of CONFIG_STUB_CODE and CONFIG_STUB_DATA didn't take into account anything but 3G/1G and 2G/2G, leaving the other vmsplits out in the cold. I'd rather not duplicate the four known host vmsplit cases for each of these symbols. I'd also like to calculate them based on the highest userspace address. The Kconfig language seems not to allow calculation of hex constants, so I moved this to as-layout.h. CONFIG_STUB_CODE, CONFIG_STUB_DATA, and CONFIG_STUB_START are now gone. In their ...

Oh dear ... after looking at the following to figure out what a wibble is, I wonder which one Andrew had in mind: http://www.urbandictionary.com/define.php?term=wibble The insanity, the rubbish, being overwhelmed, ... ? <grin> If one of Nick or I can knock some sense into the others head, then this saga should come to a close soon. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi....

Hi all, 2.6.23-rc8 and 2.6.23-rc8-git4 fail to build on one of my test machines, with: The code is allocating sizeof(struct device) so it really shouldn't be a problem. I have no idea what's wrong. That's on i386, very old machine (Pentium 166MMX / Intel TX chipset), with gcc 3.2.3 and binutils 2.14.90.0.6. 2.6.22.9 compiles fine on the same system (but it doesn't include dmi-id so it's not very surprising). .config attached. -- Jean Delvare

is this actually a problem? everybody should be running e100. I'm surprised to see a patch for eepro100, just before it gets removed... Auke -

Simplify some of the resource detection logic in yenta_socket. This patch results in the same run-time behaviour as the current code, but does so with fewer lines of code. This makes the logical flow of the code a bit easier to understand. Signed-off-by: Linas Vepstas <linas@austin.ibm.com> Cc: Dominik Brodowski <linux@brodo.de> ---- drivers/pcmcia/yenta_socket.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) Index: linux-2.6.23-rc8-mm1/drivers...

@#$%^&*. Red-faced, I withdraw the patch. Must be cross-eyed on a Monday morning. Sorry. --linas -

(resend due to mailer issues. Apologies to anyone receiving this twice) This patch series reworks the Xilinx framebuffer driver and then adds an of_platform bus binding. The of_platform bus binding is needed to use the driver in arch/powerpc platforms. Antonino, Assuming there are no major issues, I'd like to get this patch series queued up for inclusion in 2.6.24. Thanks, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. -

From: Grant Likely <grant.likely@secretlab.ca> Split the device setup code away from the platform bus binding. This is in preparation for adding the of_platform bus binding to this driver and most of the setup code is common between the two busses. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/video/xilinxfb.c | 133 ++++++++++++++++++++++++++++------------------ 1 files changed, 80 insertions(+), 53 deletions(-) diff --git a/drivers/video/xilinxfb.c b/dr...

Is it better to add error handling for platform_driver_register()? rc = platform_driver_register(&xilinxfb_platform_driver); if (rc) xilinxfb_of_unregister(); -

From: Grant Likely <grant.likely@secretlab.ca> Labels and gotos are used in xilinxfb_assign to unwind allocations on device registration failures. Rename the labels to reflect the error which occured. This change is being made to make it easier to add new failout paths (which occurs in a subsuquent patch) and to make reviewing the failout path easier. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/video/xilinxfb.c | 18 +++++++++--------- 1 files changed,...

From: Grant Likely <grant.likely@secretlab.ca> Debug support: when DEBUG is defined, output relevant details to the log about the framebuffer registration. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> --- drivers/video/xilinxfb.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c index 4bc67ab..1a5f1e4 100644 --- a/drivers/video/xilinxfb.c +++ b/drivers/video/xilinxfb.c @@ -287,6 +287,11 @...

OOh, 64bit machine. Seems like a good idea to run a 64bit kernel on Seems like it ran out of memory in zone normal. Looks like it all went to SLAB. Could you run your regular workload, and append /proc/slabinfo onto a file every 5 minutes or so? That should tell us who is using all this memory. (assuming it reproduces...) -

Changes from v1: * make the NAMESPACES_EXPERIMENTAL selectable even in !EMBEDDED case There were some questions like "do I need this on my cellphone" in reply to different namespaces patches. Indeed, the namespaces are not useful for most of the embedded systems, but the code creating and releasing them weights a lot. So I propose to add a config option which will help embedded people to reduce the vmlinux size. This option simply compiles out the namespaces cloning and releasing code *only*, bu...