Gidday, I just released man-pages-2.51. This release is now available for download at: http://www.kernel.org/pub/linux/docs/manpages or ftp://ftp.kernel.org/pub/linux/docs/manpages or mirrors: ftp://ftp.XX.kernel.org/pub/linux/docs/manpages and soon at: ftp://ftp.win.tue.nl/pub/linux-local/manpages This release consists mostly of formatting fixes, in part aimed at allowing man2html to produce better output. Cheers, Michael -- Michael Kerrisk maintainer of...

Replacing pci_find_device with pci_get_device in the drivers/isdn subtree. Signed-off-by: Karsten Keil <kkeil@suse.de> Signed-off-by: Surya Prabhakar <surya.prabhakar@wipro.com> --- drivers/isdn/hisax/avm_pci.c | 19 ++++++---- drivers/isdn/hisax/bkm_a4t.c | 15 +++++--- drivers/isdn/hisax/bkm_a8.c | 28 +++++++++------ drivers/isdn/hisax/diva.c | 69 +++++++++++++++++++------------------ drivers/isdn/hisax/elsa.c | 54 ++++++++++++++++-...

From: Rafael J. Wysocki <rjw@sisk.pl> Use a hibernation and suspend notifier to disable the firmware requesting mechanism before a hibernation/suspend and enable it after the operation. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> drivers/base/firmware_class.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) Index: linux-2.6.22-rc3/drivers/base/firmware_class.c =================================================================== --- linux-2.6.22-rc3...

What exactly is the problem we see here? The timeout of the firmware loader? What goes wrong with frozen userspace, usually there is only a netlink message sent from the kernel, which should be received and handled just fine when userspace is running again. Thanks, Kay -

Seems, that's just the broken synchronous firmware loading interface with the useless timeout handling. The nowait version of the same loader doesn't time out, and should not have that problem. The sync version should be removed from the kernel, it just causes all sorts of problems since it exists. Userspace should handle the async request just fine when it comes back running, regardless of the time it was submitted. Kay -

Well, this was acutally invented before you've decided to remove the freezing of tasks from the suspend code path (which I think is a mistake, but that's only my personal opinion, so it doesn't matter very much ;-)) and I regard it Under the (optimistic, IMO) assumption that the relevant user space task won't block on I/O with a suspended device involved or something like this. BTW, I know of two subsystems that want their kernel threads to be frozen for synchronization purposes. Please see the...

I don't like this approach, as I feel that the firmware loading interface should be able to detect if a firmware load request is not being handled, due to absence of userspace / hotplug handler presence. Other circumstances in which this can be a problem is during bootup when request_firmware() calls can be made before userspace is up and init has run (even in the presence of an initramfs). (Slightly OT: A particularly nasty race is when an initramfs userspace is present, but firmware...

From: Rafael J. Wysocki <rjw@sisk.pl> Make it possible to register hibernation and suspend notifiers, so that subsystems can perform hibernation-related or suspend-related operations that should not be carried out by device drivers' .suspend() and .resume() routines. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Documentation/power/notifiers.txt | 76 ++++++++++++++++++++++++++++++++++++++ include/linux/notifier.h | 13 ++++++ include/linux/suspend.h | 25 ...

Linus, Please pull the hwmon subsystem fixes for Linux 2.6.22 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 hwmon-for-linus drivers/hwmon/Kconfig | 2 +- drivers/hwmon/applesmc.c | 7 ++++++- drivers/hwmon/coretemp.c | 32 +++++++++++++++++++++++++++++--- drivers/hwmon/ds1621.c | 8 ++++---- drivers/hwmon/hwmon-vid.c | 4 +++- drivers/hwmon/w83627hf.c | 4 +++- 6 files changed, 46 insertions(+), 11 deletions(-) --------------- Jean Delvare (4): hwmon...

This is the diff between these two kernels. I'm not sure why you see a much better TX throughput here. Can you re-check to make sure it's not just some test-jitter? --- linux-2.6.21.1/drivers/net/b44.c 2007-05-27 22:58:01.000000000 +0200 +++ linux-2.6.22-rc3/drivers/net/b44.c 2007-05-27 23:01:44.000000000 +0200 @@ -825,12 +825,11 @@ if (copy_skb == NULL) goto drop_it_no_recycle; - copy_skb->dev = bp->d...

Oh, eh, and what I forgot to ask: Do you know an old kernel that works perfectly well for you, so I can look at a diff between this one and anything >=2.6.21.1. -- Greetings Michael. -

Why do we have two different measurements here? Is one TX and one RX? So with -mm (with ssb) you actually get better performace then with plain 2.6.22-rc3? Can you elaborate a bit more about what you get an what you expect on which kernel? -- Greetings Michael. -

Ok. I guess (Yes I do :D) that there is an IRQ storm or something like that, because you say that your system is becoming very slow and unresponsive. It sounds like an IRQ is not ACKed correctly and so keeps triggering and stalling the system. I'll take a look at a few diffs... Do you see significant differences in the "hi" and/or "si" times in top? Do you see a significant difference in the /proc/interrupts count. For example that the kernel that works worse generates 10 times the IRQ count for th...

f5f72b46c349fefcfd4421b2213c6ffb324c5e56 appears to break the userspace interface to the CMOS alarm. This could previously be accessed via /proc/acpi/alarm, but if RTC_DRV_CMOS is enabled that vanishes. The help text for the module doesn't mention this, which makes tracking it down a touch irritating. I'm not actually sure why this is the case. It doesn't look like the two interfaces are fundamentally incompatible. I agree that removing the proc code is a good long-term aim, but it'd be nice ...

Remove a clearly useless reference to the obsolete MODULE_PARM macro. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> --- given that that macro call is enclosed within an obsolete "__MODULE__" check, i have to assume that snippet of code can be safely removed. diff --git a/drivers/input/mouse/atarimouse.c b/drivers/input/mouse/atarimouse.c index 43ab656..f779cb6 100644 --- a/drivers/input/mouse/atarimouse.c +++ b/drivers/input/mouse/atarimouse.c @@ -59,9 +59,6 @@ MODULE_L...

We are seeing increasing levels of minor patch style violations in submissions to the mailing lists as well as making it into the tree. These detract from the quality of the submission and cause unnessary work for reviewers. As a first step package up the current state of the patch style checker and include it in the kernel tree. Add instructions suggesting running it on submissions. This adds version v0.01 of the patch-trivia-detector. Signed-off-by: Andy Whitcroft <apw@shadowen.org> ...

That's step #7 now. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -

Just why did no one get a kernel oops? After all, the code tried to write to constant memory. This is the first patch of two. There is yet another section of Linux code that runs in 9600-only, and I need to figure out which. --- The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in my case). This was because mode_prop remained "ttyX-mode" (expected: "ttya-mode") due to the constness of string literals when used with "char *". Since there is no "ttyX-mode" property in the P...

From: David Miller <davem@davemloft.net> I just stared at the drivers/serial/suncore.s assembler a little bit and this is indeed what appears to be happening, the compiler is optimizing the stores away completely yet not doing so much as emitting a warning, how rude :-) Perhaps there is some warning option that isn't enabled which would have caught this... Thanks a lot for your patch, I'll apply it. -

Use list_for_each_entry() instead of list_for_each() in the block device elevator Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com> -- diff --git a/block/elevator.c b/block/elevator.c index ce866eb..4769a25 100644 --- a/block/elevator.c +++ b/block/elevator.c @@ -112,12 +112,8 @@ static inline int elv_try_merge(struct request *__rq, struct bio *bio) static struct elevator_type *elevator_find(const char *name) { struct elevator_type *e; - struct list_head *entry; - ...

From: Kay Sievers <kay.sievers@vrfy.org> Subject: USB: set default y for CONFIG_USB_DEVICE_CLASS Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> --- diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index f493fb1..346fc03 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -40,21 +40,25 @@ config USB_DEVICEFS config USB_DEVICE_CLASS bool "USB device class-devices (DEPRECATED)" depends on USB - default n + default y ---help--- Use...

Because usb_device class devices are kind of broken regarding the event timing, and should not be used anymore. They are replaced by device-nodes created by the real usb-device, but some systems still depend on the class devices: http://lkml.org/lkml/2007/5/27/56 We better default to y for a while until the users have switched over. Kay -

This patchset presents the path to PCI API support in the initio driver. But the first patch really begs the question: Has this driver really been broken since Oct 2003? If so, let's just delete it. drivers/scsi/initio.c | 206 +++++++++++++++++++++++++++++--------------------- drivers/scsi/initio.h | 10 +- 2 files changed, 127 insertions(+), 89 deletions(-) -

Prior simplifications in this patchset now permit a minimal conversion to the new PCI API. Further improvements and simplifications are certainly possible; those should be presented in a separate patchset. DO NOT APPLY (yet). For feedback (and testers?) only. 3f42ce6a28b81cb057b2304e3aca6e873618a6fd diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c index 702dcf5..e54449f 100644 --- a/drivers/scsi/initio.c +++ b/drivers/scsi/initio.c @@ -242,6 +242,7 @@ static void tul_read_eepr...

On Sun, 27 May 2007 11:03:53 -0400 NAK all five. There is a complete overhaul already done. Alan -