Replace the COPY_UNALIGNED_WORD helper. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- arch/sh/kernel/module.c | 39 +++++---------------------------------- 1 files changed, 5 insertions(+), 34 deletions(-) diff --git a/arch/sh/kernel/module.c b/arch/sh/kernel/module.c index b3d0a03..5482e65 100644 --- a/arch/sh/kernel/module.c +++ b/arch/sh/kernel/module.c @@ -30,6 +30,7 @@ #include <linux/fs.h> #include <linux/string.h> #include <linux/kernel.h> +#include ...

On Thu, 29 May 2008 00:13:35 +0100 (BST) hm. This version: static ssize_t shmem_file_aio_read(struct kiocb *iocb, const struct iovec *iov, unsigned long nr_segs, loff_t pos) { struct file *filp = iocb->ki_filp; ssize_t retval; unsigned long seg; size_t count; loff_t *ppos = &iocb->ki_pos; count = 0; retval = generic_segment_checks(iov, &nr_segs, &count, VERIFY_WRITE); if (retval) return retval; if (count == 0) return 0; retval = 0; for (seg = 0; seg < nr_segs; ...

Hello All, I have recently found an instance in the drivers/usb/gadget/fsl_usb2_udc.c file that causes the udc->lock spinlock to be taken twice. The problem arises when you disconnect from the DR port and then reconnect. The interrupt routine for the driver receives a 'reset' event which takes the lock and calls reset_queues() which in turn calls udc->driver->disconnect(). Eventually, that disconnect() call comes back up to the fsl_usb2_udc driver and calls fsl_ep_disable() which ...

I am wondering wether someone can explain how hpet behaves. The bellow is a short program that reads from a mmaped /dev/hpet the time. I am running it and it looks that afer ~296 seconds the counter resets . I AM RUNNING 64bi KERNEL(2.6.18-8.el5) and reading a 64BIT VARIABLE. my hpet is 14MHZ, so I am guessing a 32bit wraparound ( ~296 * 14Mhz ) = MAX_INT . but why ? thank you raz #include <stdint.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>ing 6 #include ...

The following used to work: ARCH=ia64 KBUILD_DEFCONFIG=bigsur_defconfig make defconfig Now 2.6.25 makes you do: ARCH=ia64 make KBUILD_DEFCONFIG=bigsur_defconfig defconfig Is this my intent? It seems like the arch/<xxxx>/Makefile files should be: KBUILD_DEFCONFIG ?= generic_defconfig Instead of KBUILD_DEFCONFIG := generic_defconfig --

David, Another round of fixes for 2.6.26 follows... Please let me know if there are problems! Thanks, John --- Individual patches are available here: http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/ --- The following changes since commit 289c79a4bd350e8a25065102563ad1a183d1b402: Patrick McHardy (1): vlan: Use bitmask of feature flags instead of seperate feature bits are available in the git repository at: ...

When underlying block device becomes unavailable (e.g. someone pulling an USB stick from under us), kernel produces warning about non-uptodate buffer (superblock) being marked dirty. Silence these warnings by making buffer uptodate before marking it dirty. Signed-off-by: Jan Kara <jack@suse.cz> --- fs/jbd/journal.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c index b99c3b3..9303608 100644 --- a/fs/jbd/journal.c +++ ...

When underlying block device becomes unavailable (e.g. someone pulling an USB stick from under us), kernel produces warning about non-uptodate buffer (superblock) being marked dirty. Silence these warnings by making buffer uptodate before marking it dirty. Signed-off-by: Jan Kara <jack@suse.cz> --- fs/jbd2/journal.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index 2e24567..55de8f7 100644 --- a/fs/jbd2/journal.c +++ ...

And just for reference a similar patch for UDF which I'll merge through my git tree. Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --- From 756bc361a065b65df9977c2632472f587659a6f7 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Wed, 28 May 2008 23:39:19 +0200 Subject: [PATCH] udf: Silence warnings about non-uptodate buffers When underlying block device becomes unavailable (e.g. someone pulling an USB stick from under us), kernel produces warning about ...

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide-lib.c | 17 ----------------- include/linux/ide.h | 8 -------- 2 files changed, 25 deletions(-) Index: b/drivers/ide/ide-lib.c =================================================================== --- a/drivers/ide/ide-lib.c +++ b/drivers/ide/ide-lib.c @@ -76,23 +76,6 @@ static u8 ide_rate_filter(ide_drive_t *d } /* - * Standard (generic) timings for PIO modes, from ATA2 specification. - * These ...

There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/Kconfig | 1 + drivers/ide/legacy/ali14xx.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) Index: b/drivers/ide/Kconfig =================================================================== --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -988,6 +988,7 @@ config BLK_DEV_4DRIVES config BLK_DEV_ALI14XX tristate "ALI ...

There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/Kconfig | 1 + drivers/ide/legacy/qd65xx.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) Index: b/drivers/ide/Kconfig =================================================================== --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -1018,6 +1018,7 @@ config BLK_DEV_HT6560B config BLK_DEV_QD65XX tristate "QDI ...

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide-lib.c | 15 --------------- 1 file changed, 15 deletions(-) Index: b/drivers/ide/ide-lib.c =================================================================== --- a/drivers/ide/ide-lib.c +++ b/drivers/ide/ide-lib.c @@ -1,26 +1,11 @@ -#include <linux/module.h> #include <linux/types.h> #include <linux/string.h> #include <linux/kernel.h> -#include <linux/timer.h> -#include <linux/mm.h> #include ...

Move PIO blacklist to ide-pio-blacklist.c. While at it: - fix comment - fix whitespace damage There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/Makefile | 3 - drivers/ide/ide-lib.c | 96 ---------------------------------------- drivers/ide/ide-pio-blacklist.c | 94 +++++++++++++++++++++++++++++++++++++++ include/linux/ide.h | 2 4 files changed, 98 ...

Also fix placement of comments in ide_timing_compute() while at it. There should be no functional changes caused by this patch (md5sum was verified to be the same before/after the patch). Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide-timing.h | 93 ++++++++++++++++++++++++----------------------- 1 file changed, 48 insertions(+), 45 deletions(-) Index: b/drivers/ide/ide-timing.h =================================================================== --- ...

There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/Kconfig | 1 + drivers/ide/pci/opti621.c | 10 +++++----- 2 files changed, 6 insertions(+), 5 deletions(-) Index: b/drivers/ide/Kconfig =================================================================== --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -426,6 +426,7 @@ config BLK_DEV_GENERIC config BLK_DEV_OPTI621 tristate "OPTi ...

There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ide-timing.h | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) Index: b/drivers/ide/ide-timing.h =================================================================== --- a/drivers/ide/ide-timing.h +++ b/drivers/ide/ide-timing.h @@ -29,7 +29,7 @@ #include <linux/hdreg.h> struct ide_timing { - short mode; + u8 mode; short ...

Also fix (disabled) debugging code while at it. There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/ppc/mpc8xx.c | 33 +++++++++++++-------------------- 1 file changed, 13 insertions(+), 20 deletions(-) Index: b/drivers/ide/ppc/mpc8xx.c =================================================================== --- a/drivers/ide/ppc/mpc8xx.c +++ b/drivers/ide/ppc/mpc8xx.c @@ -89,7 +89,7 @@ ide_ioport_desc_t ...

There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/Kconfig | 1 + drivers/ide/pci/cmd64x.c | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) Index: b/drivers/ide/Kconfig =================================================================== --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -495,6 +495,7 @@ config BLK_DEV_ATIIXP config BLK_DEV_CMD64X tristate ...

There should be no functional changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/Kconfig | 1 + drivers/ide/pci/cy82c693.c | 9 ++++----- 2 files changed, 5 insertions(+), 5 deletions(-) Index: b/drivers/ide/Kconfig =================================================================== --- a/drivers/ide/Kconfig +++ b/drivers/ide/Kconfig @@ -510,6 +510,7 @@ config BLK_DEV_TRIFLEX config BLK_DEV_CY82C693 tristate ...

On Wed, May 28, 2008 at 05:34:58PM -0400, Theodore Ts'o wrote: > > [ This is the last message concerning the kernel summit that will be sent > to LKML; discussion should take place from henceforth on 2008 Kernel > Summit discuss list, and folks can subcribe by going to the URL: > https://lists.linux-foundation.org/mailman/listinfo/ksummit-2008-pc ] That should be https://lists.linux-foundation.org/mailman/listinfo/ksummit-2008-discuss of course. the -pc list is the list used for ...

linux-next-20080528/drivers/xen/manage.c: In function 'xen_suspend': linux-next-20080528/drivers/xen/manage.c:43: error: implicit declaration of function 'device_power_down' linux-next-20080528/drivers/xen/manage.c:65: error: implicit declaration of function 'device_power_up' linux-next-20080528/drivers/xen/manage.c: In function 'do_suspend': linux-next-20080528/drivers/xen/manage.c:114: error: implicit declaration of function 'device_resume' make[3]: *** [drivers/xen/manage.o] Error ...

On Thu, 29 May 2008 00:09:36 +0200 Looks like this is BUG_ON(inode->i_state == I_CLEAR); Please do enable CONFIG_DEBUG_BUGVERBOSE. Turning off this stuff Beats me. Somehow the swap device's blockdev inode got I_CLEAR set while swsusp_write() was playing with it. Or during. I guess we could add I_CLEAR checks on resume_bdev into kernel/power/swap.c in various places. Had there been any swapoffs before or during this suspend? Does the above BUG only occur when swsusp encountered ...

Hello, I'm using hibernation on my desktop machine every day instead of power off. It mostly works but sometimes aborts with "no space left on device" error. Closing some programs and trying again usually fixes it - but recently, I got two oopses instead. I'm sending them because they're the same, only some details are different. Does anyone know what might be wrong? ------------[ cut here ]------------ Kernel BUG at c015610b [verbose debug info unavailable] invalid opcode: 0000 ...

I think you did not receive it so I'm sending again.... On Mon, May 26, 2008 at 2:43 PM, Fausto Richetti Blanco --

rtnl, in fact, I suspect. Actually, please apply the patch "=EF=BB=BFrt2x00: Use atomic interface iteration in irq context" before trying anything more, that'll fix it. I'm not sure where Linville is hiding ;) (http://article.gmane.org/gmane.linux.kernel.wireless.general/15268) johannes

.. again, please give the full oops, without that we just know that "an I assume it's related to the oops above - the oops probably happened while holding some mutex or other lock, which is why network-related stuff then blocks on that lock (which will never be released, since the oops killed the process that held it). I suspect the oops is also why the bootup breaks, so it's likely all the same issue. Please save the dmesg into a file, reboot into a working setup, and send ...

(cc'ing linux-kernel) We use kobjsize() for pointers returned from do_mmap() which is why I kept the page->index case. Are we using PageCompound for those as well? Hmm... --

What does do_mmap have to do with page->index? --

With reference to a recent thread about kconfig I would prefer: static inline void some_debug_function(var1) { if (KCONFIG_DEBUG_SOMETHING) { something = var1; printk(some debug text); } } But we do not have KCONFIG_DEBUG_SOMETHING available so the second best is to use an empty function to keep the typechecking in place. IIRC gcc optimize both away. Sam --

This patch modifies the permission checks for sysctl's from being based on uid=0 (root) to use the capability system. This matches the behavior of other OS's using sysctl's and capabilities. Linux has tried to get away from using uid=0 for security overrides and use capabilities instead. I was working on Quagga enhancement that involved enabling a sysctl, and it didn't work because is a safe daemon and drops privileges and resets its real/effective uid after initialization; it then re-enables ...

The commit commit 4b82b277707a39b97271439c475f186f63ec4692 Author: Cyrill Gorcunov <gorcunov@gmail.com> Date: Sat May 24 19:36:35 2008 +0400 set nmi_watchdog to NMI_IO_APIC as by default. This causes hangs on some machines with buggy watchdogs. Fix it - i.e. restore old behaviour. Thanks to Sitsofe Wheeler and Adrian Bunk for catching the problem and Maciej W. Rozycki for explanation what is going on there. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> CC: Maciej W. Rozycki ...

On Wed, 28 May 2008 19:15:41 +0100 (BST) Acked-by: Rik van Riel <riel@redhat.com> -- All rights reversed. --

powertec.c : add code to print an error message while device_create_file() called from powertecscsi_probe() fail Signed-off-by: Qinghuang Feng <s3c24xx@gmail.com> --- diff --git a/drivers/scsi/arm/powertec.c b/drivers/scsi/arm/powertec.c index d9a546d..14e25a6 100644 --- a/drivers/scsi/arm/powertec.c +++ b/drivers/scsi/arm/powertec.c @@ -315,6 +315,7 @@ powertecscsi_probe(struct expansion_card struct powertec_info *info; void __iomem *base; int ret; + int ferr; ret = ...

Hi James, On Thu, May 29, 2008 at 12:01 AM, James Bottomley I'm not sure what you expect to happen if we "shut down" the Janitors project. The important janitorial work doesn't just magically disappear. For example, we still need people for: - Fixing API misuse - Converting code from old APIs to new ones - Consolidating duplicate code - Fixing error handling code - Removing unused code - De-obfuscating code (e.g. removing bad macro magic, etc.) And, quite frankly, I don't ...

Yes, the median age of the MAINTAINERS is rising. Not quite at the rate of a year per year which would show we have practically no turn over, but it is rising. However, even if there were no recruitment problem at all, getting more people involved is always better because it means more contributions. And contributions (useful ones) are the lifeblood that moves the kernel I don't think so. But that's not really what I'm saying. I'm saying we need to make the process of encouraging useful ...

Do we really have a problem recruiting people to work in the kernel? On what do you base that observation? On a similar note, do we have any real data on the question of whether those who are volunteering the patches which raise so much ire would _ever_ become productive members of the team, even if we were to nurture them properly? -- dwmw2 --

The example that sums it up for me is this one: http://lkml.org/lkml/2008/5/18/20 We have people making minor cosmetic changes, and not paying even the _slightest_ attention to what they're doing. This one's a particularly scary example because it's something even the most non-technical person should have spotted; there's _no_ excuse. It's the cosmetic equivalent of a naïve warning fix that leaves the actual bug in place. I think you're right that the status quo is damaging, and I don't ...

I'm just outlining the possible solutions; shutting it down wasn't the one I advocated. One can argue that janitorial changes with enough intrinsic value tend to get done anyway regardless of whether we have The problem is that there's something in the way all of this is working that's causing politeness to get short shrift. In turn that's giving lkml a larger than normal reputation for being a free for all dog fight and discouraging potential contributors from coming forwards. Appeals to ...

On Wed, 28 May 2008 12:20:12 -0500 I've had some limited success with: http://kernelnewbies.org/KernelProjects One problem is that people end up beginning with a project but for some reason stop working on it later - with no indication as to whether the project ended up being too difficult, or they ran out of time, or something else happened... -- All rights reversed. --

I think our mistake is the assumption that everyone who wants to contribute to the kernel wants to code, or that everyone wants to end up at the top of the major feature contributors list. For lots of people, we're going to be that experiment from college they never quite want to admit to later on in life. Looking at the KernelProjects link, bugzilla is at the buttom and janitors is at the top. I've always thought the janitors project was important, but maybe we want to change the ...

LOL. Merged. -hpa --

Pardon my ignorance -- is there anything special about the number 801586? It might be fun to display the family in hexadecimal though -- if86 or 80F86. ;) Maciej --

Actually, I have seen some Intel literature talking about the 786. This was back when the 486 was new, and they wanted to impress how advanced their roadmap was. Needless to say, it was completely bogus. -hpa --

On Wed, May 28, 2008 at 07:48:03PM +0200, Jan Engelhardt wrote: > > On Wednesday 2008-05-28 18:57, Dave Jones wrote: > > >Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets > >you an amusing message along the lines of. > >"you need an x86-64, but you only have an i1586" > >due to the P4 being family F. Munge it to be 686. > > What is wrong with it? If i386, 486, 586 and 686 are valid names, > why should not 786 (or rather 1586... since someone thought it > would be cool ...

What is wrong with it? If i386, 486, 586 and 686 are valid names, why should not 786 (or rather 1586... since someone thought it would be cool to jump the number^1) be? [^1 Which also is interesting because the original number had an 80 prepended, i.e. 80286, 80586,... and you'd guess what number 1586 would map to.] --

By bad, drivers/power/Makefile is ok. I thought I reproduced the issue there. --

We use find to delete all .o files. So the content of your Kbuild file should not matter here. Can you describe the setup where you see the issue? Sam --

The patch "make page-aligned data and bss less fragile" introduces __page_aligned_data and __page_aligned_bss to make sure that page aligned things remain so, even if there are non-page-sized page-aligned things. This paragraph converts an instance of an explicit section attribute to __page_aligned_data. It's purely decorative. (It should be noted that powerpc already defines __page_aligned to have the same meaning as __page_aligned_data in non-MODULE code. Also this particular case looks ...

From: David Howells <dhowells@redhat.com> Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a crash when SLOB is selected as the memory allocator. The FRV arch needs this so that it can use the load- and store-double instructions without faulting. By default SLOB sets the minimum to be 4 bytes. Signed-off-by: David Howells <dhowells@redhat.com> --- include/asm-frv/mem-layout.h | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git ...

This is the exact situation cdrecord's -immed option was designed for. "wodim"/cdrkit should have inherited it. It sets a flag in the commands to avoid blocking, though the documentation I read said it was slightly experimental. --

From: David Howells <dhowells@redhat.com> Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a crash when SLOB is selected as the memory allocator. The FRV arch needs this so that it can use the load- and store-double instructions without faulting. By default SLOB sets the minimum to be 4 bytes. Signed-off-by: David Howells <dhowells@redhat.com> --- include/asm-frv/mem-layout.h | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git ...

On Wed, 28 May 2008 16:49:01 +0100 So.. like this? From: David Howells <dhowells@redhat.com> Specify the minimum slab/kmalloc alignment to be 8 bytes. This fixes a crash when SLOB is selected as the memory allocator. The FRV arch needs this so that it can use the load- and store-double instructions without faulting. By default SLOB sets the minimum to be 4 bytes. We need to use literal constants here as slab evaluates these within cpp. Signed-off-by: David Howells ...

* Differentiate between bay devices in dock stations and others: - When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to userspace (that is when the optional eject button on a bay device is pressed/pulled) giving the possibility to unmount file systems and to clean up. Also, only send uevent in case we get an EJECT_REQUEST without doing anything else. In other cases, you'll get an add/remove event because libata attaches/detaches the device. - In case of a dock ...

As I have a notebook, I think I can't do that, can I? --

I would like to personally invite you to attend this historic event for our industry. The contacts you will make will be priceless. Where? The Rio Hotel, Las Vegas - Nevada When? June 20th 2008 for addional information go to http://friendlyseminar.com/ or call today: 858.736.7788 to be taken of our list please: http://friendlyseminar.com/del/ or, send us a letter to: PBMSII, 5451 Weuery Ave., La JoIIa, CA 92037 -------------------------------------------- . --

I sent this to the list with other mail address and it didn't reach it afaics. apologies if someone sees this twice i cced wireless becouse of the first oops First boot into 2.6.26-rc4 Compiled and booting into 2.6.26-rc4 1) With splash quiet on grub line it doesn't boot (or i didin't wait long enough) 2) without quiet and splash I get into VT X filas becouse i use the evil nvidia driver that's expected. But ubuntu failsafe mode (xserver with vesa in low res) doesn't ...

This is another instance of a problem being caused by semaphore to mutex conversion in struct class; There's another thread on this here: http://marc.info/?t=121074904600001 James --

looks like device_add() recursing - most likely with a different device --

The RAID1 is correct. As has been discussed on this list before, you will= =20 only see raid speed > 1 disk if you run 2(?, or 3 minimal) threads=20 from the same device (raid1). Justin.

The RAID 1 read speed metrics do not depict multithreaded processes reading from the array simutaneouly. I would suspect that the read performance metrics would look better if 2 bonnie simulations were ran together (for RAID 1 that is). Bryan --

Since the performance of bonnie++ deals with single threads/a raid1 would p= Not in particular, just I could never find this information provided anywhe= re that showed all of the raid variation/types in one location that was easy t= o Yes, after the creation of each array, mkfs.xfs -f /dev/md3 was run to ensu= re > keld

Results are meaningless without a crucial detail - what was the chunk size used during array creation time? Otherwise interesting test :) Cheers Peter --

Only/usually on multi-threaded jobs/tasks, yes? Also, I turn off NCQ on all of my hosts that has it enabled by default because there are many bugs that occur when NCQ is on, they are working on it in the libata layer but IMO it is not safe at all for running SATA disks w/NCQ as with it on I have seen drives drop out of the array (with it off, no problems). --

Indeed, the chunk size used was 256 KiB for all tests. Justin. --

I have done NCQ measurements in the past, for single threaded apps NCQ off is the way to go, check this out from earlier (10 raptors raid5): http://home.comcast.net/~jpiszcz/ncq_vs_noncq/ --

I see--however, as I understood it there were bugs utilizing NCQ in libata? But FYI-- In this test, they were regular SATA drives, not special raid-ones (RE2,etc). Thanks for the info! Justin. --

(Now, for all people, sorry) ---------- Forwarded message ---------- From: Néstor Amigo Cairo <nestorac@gmail.com> Date: 2008/5/27 Subject: Re: QUESTION: How can I make a driver for a special serial keyboard which also supports output (maybe via serio_raw)? To: Benoit Boissinot <bboissin@gmail.com> Thanks!! You are awesome, guys, I wouldn't been able to find this if it was "Googling". I have to take a look now, but it looks cool. If I can just use this X11 hack now, then I have plenty ...

Hi all, Changes since next-20080527: New tree: ubifs The pci tree had a conflict with the pci-current tree. The hid tree was fixed. The semaphore-removal tree still needed three patches reverted because simi= lar patches were merged into upstream and the scsi-rc-fixes trees. I have applied the following temporary patch for known build problems: "Fix various 8390 builds" - the net tree broke builds on various architectures - hopefully this patch will go into the net tree ...

I would like to personally invite you to attend this historic event for our industry. The contacts you will make will be priceless. Where? The Rio Hotel, Las Vegas - Nevada When? June 20th 2008 for addional information go to http://industryseminar.com/ or call today: 858.736.7788 to be taken of our list please: http://industryseminar.com/del/ or, send us a letter to: PBMSII, 5451 Weuery Ave., La JoIIa, CA 92037 -------------------------------------------- . --

ah, thanks, that's me trying to pick up patches which aren't in linux-next yet. I normally don't bother doing that unless there's a lot of material involved. I'll zap the erroneously-included rusty-misc-doc_add_a_chapter_about_trylock_functions_bug_9011.patch --

All the relevant stuff is now upstream (2.6.26-rc4) except: - the userspace sysfs interface (which is in MM, and ISTR you were cc'd on that) - an avr32 patch, appended (no response on the avr32 list) Nothing else touches core code; if you're using AVR32, then you won't care about at91 gpiolib and inlining support, or the patch sent this AM on LKML (which I've not yet reviewed). - Dave ====== CUT HERE From: David Brownell <dbrownell@users.sourceforge.net> Subject: AVR32: ...

Sorry about the lack of response. But then we need to keep track of whether pullups used to be enabled so that we can re-enable it in gpio_direction_input(), don't we? I can't see the harm of keeping the pullup enabled while the port is configured as output. For consistency, I'd rather honor the pullup flag Hmm. I guess that makes sense, though I would be lying if I said I care all that much. I think gpiolib is going pretty far to accommodate buggy drivers that don't call gpio_request() ...

Righteo, thanks. --

On Tue, 27 May 2008 23:01:01 -0300 909090 is asm for "nop nop nop", a pattern often used in rootkits to deal with slightly unknown memory locations I would REALLY REALLY strongly suggest that you check for rootkits and the like on your system... -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --

I'm hardly the right person to answer on this, but I believe that because the 0x90 NOP is particularly appropriate in .text (and prevents stalls even where it cannot be reached?), it gets used as the default alignment filler all over. (It's even specified for the arch-independent default _ALIGN in linux/linkage.h.) Hugh --

Thanks a lot for re-reporting this: it was fun to work it out. It's not a rootkit, it's harmless, but we ought to fix the noise. Simple patch below, but let me explain more verbosely first. What was really interesting in your report was that the address is so close to that in OGAWA-San's report. I had a look at that page on my x86_64 boxes, and they have lots of 0x90s there too. It's just some page alignment filler that x86_64 kernel startup has missed cleaning up - patch below fixes that. ...

OK, I did not understand from Hugh's explanation that it was all about alignment within functions. Of course, 0x90 is fine there (though there are multi-byte NOPs available). Cheers, Willy --

"All about alignment within functions" -- I am not sure about that, you just happened to ask about 0x90 :) And if you have a 1-byte NOP (which fits perfectly everywhere), which is also a real NOP (and not just a filler byte that could possibly be an opcode doing something very different), you've got an ideal candidate for padding, no? There is probably nothing wrong with padding .data sections with 0xAF or even 0xDB and ud2 to catch execute-readonly-data cases. To that end, I think something ...

Hi Steven, The following series are patches that have been accepted by Ingo in sched-devel post 2.6.25. They probably should be considered for the next RT release as well. The series applies to 25.4-rt3. Regards, -Greg --

We currently use an optimization to skip the overhead of wake-idle processing if more than one task is assigned to a run-queue. The assumption is that the system must already be load-balanced or we wouldnt be overloaded to begin with. The problem is that we are looking at rq->nr_running, which may include RT tasks in addition to CFS tasks. Since the presence of RT tasks really has no bearing on the balance status of CFS tasks, this throws the calculation off. This patch changes the logic ...

In dynamic ftrace, the mcount function starts off pointing to a stub function that just returns. On start up, the call to the stub is modified to point to a "record_ip" function. The job of the record_ip function is to add the function to a pre-allocated hash list. If the function is already there, it simply is ignored, otherwise it is added to the list. Later, a ftraced daemon wakes up and calls kstop_machine if any functions have been recorded, and changes the calls to the recorded ...

On the matter of EFI, Linus do have a point. EFI is complex enough that it is more like DOS than a BIOS. And it is funny to compare hardware complexity to human evolution. Yuhong Bao _________________________________________________________________ If you like crossword puzzles, then you'll love Flexicon, a game which combines four overlapping crossword puzzles into one! http://g.msn.ca/ca55/208--

If this approach goes forward, I'd expect those platforms Best done by #ifdef HAVE_CLK in <linux/clk.h> support, and putting the stubs there. However, since those platforms don't actually have clocks, I'd make them all report errors of whichever kind. That's kind of a second-order question to "should we create a HAVE_CLK in Kconfig". Since Certain People have objected to patches touching <linux/clk.h> I avoided doing that the first time around ... it'd be a better solution, yes. - ...

On Wed, May 28, 2008 at 2:14 AM, David Brownell <david-b@pacbell.net> wrote: Sorry, another comment. Instead of making the driver dependant on HAVE_CLK (which would be true for virtually any driver comming from linux-omap), you could make clk_enable a nop in case arch doesn't HAVE_CLK. How does that sound? -- Best Regards, Felipe Balbi felipebalbi@users.sourceforge.net --

I'm just a software development major in college who follows kernel development (it's kind of like following a sport that's played 24/7, and I can participate in!) fairly closely. But, for what it's worth, Chris, I really appreciated your comment. It's really refreshing to actually see a positive outlook with a call to action these days (especially where thousands of introverts are concerned). Thank you for a humble, well thought out reply to a slightly hostile post. I've always ...

Hi, I've tried it on -nmw and it seems to run ok, and I'm currently running it on the current upstream kernel and its done 1/2 hour so far with no sign of a problem. Can you give a few more details, such as the block size of the fs, the exact command line for fsx (I was just running with defaults) and perhaps check all the info into a Red Hat bugzilla? I know this is upstream, but I tend to use "Fedora/rawhide" to keep tabs on such things just so as all the bugs are in the same ...

Acked-by: Adam Litke <agl@us.ibm.com> -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center --

[PATCH 4/3] Fix prio tree lookup I spoke too soon. This is a fix to patch 3/3. If a child unmaps the start of the VMA, the start address is different and that is perfectly legimite making the BUG_ON check bogus and should be removed. While page cache lookups are in HPAGE_SIZE, the vma->vm_pgoff is in PAGE_SIZE units, not HPAGE_SIZE. The offset calculation needs to be in PAGE_SIZE units to find other VMAs that are mapping the same range of pages. This patch fixes the offset calculation and ...

Acked-by: Adam Litke <agl@us.ibm.com> -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center --

Try that patch at: http://patchwork.ozlabs.org/linuxppc/patch?id=18710 Fixes it for me. Yours Tony linux.conf.au http://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! --

I'd like to counter with this patch. This goes for proper VMAs and doesn't make use of compound pages. This makes things more similar to MMU-mode. Note that this patch unconditionally trims allocations, whereas on yours this is optional. That can be easily remedied, if, in fact, the ability to request untrimmed allocations is worth doing. David --- [PATCH] NOMMU: Make VMAs per MM as for MMU-mode linux From: David Howells <dhowells@redhat.com> Make VMAs per mm_struct as for MMU-mode ...

I'm not "the maintainer" of MadWifi, just one of the guys working on the project. I agree with Arjan that this report is off-topic on lkml, since MadWifi is not part of the Linux kernel. Please report this either via our bugtracker or via one of the MadWifi-related mailing lists (see http://madwifi.org/wiki/Resources). Bye, Mike --

The complexity is the same imho, both versions are fairly trivial. I wasn't out to optimize this in a memory copy sense. To me the most precious resource is the data stream to the app, and 128 bytes is probably 6 times larger than the normal message would be. With the actual trace structure, we are down to about 3 times the byte size. So it was just an idea, I don't care much either way. With 128 bytes, we could just put the buffer on the stack (and still do the copy to the relay buffer). ...

Given your prioritizing of relay-copying over kernel-copying, I think you're solution is better (and more flexible going forward). Alan --

I looked into something like this, but thought the added complexity wasn't worth it. Besides the extra per-cpu stuff, you also have an extra memcopy involved - in my patch you print directly into the relay buffer. I figure that /if/ copying (128-msg_size) extra bytes is too much, one could always shrink the 128 down further. [I would think 64 bytes is probably ok.] I'd bet that the reduced complexity, and skipping the extra memcopy more than offsets having to copy a few extra ...

Hello David, I think s3c2443 is similar. For them just using the input mode for a gpio isn't enough to get an irq, too. (At least if I believe my IMHO pinmux and GPIO are not orthogonal. The GPIO API just choosed not OK. (But then a general driver cannot make use of this function. IMHO There isn't "the pin". E.g. IRQ_NS9XXX_EXT0 can trigger on gpios 1, 9, 16 and 105 on ns9215. These are four different pins. What should I do when two of them are in input mode? (I can remember for which ...

Yes, looks good. --

On Tue, 27 May 2008 15:23:06 +0400 So is everyone happy with this now? It got lost from the changelog but IIRC this fixes a small sort-of regression which was added in 2.6.25(?) because Stas switched drivers. I assume that the incompatibility was unintentional. So it might be 2.6.26 material, and possibly even 2.6.25.x? --

On Wed, 28 May 2008 08:49:43 -0600 Feel free to identify the cessful patches so they can be fixed or dropped. From: Dave Young <hidave.darkstar@gmail.com> The class_device is already removed, so do the class->sem to mutex conversion. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- drivers/base/class.c | 22 +++++++++++----------- ...

--

Hi Artem, On Tue, 27 May 2008 09:18:07 +0300 Artem Bityutskiy <Artem.Bityutskiy@nokia= OK, my requirements are that you intend for it to be integrated in the next merge window, that it be reviewed and that it be unit tested (i.e. tested as well as you can in isolation). You seem to have done all that, so I will add it. I will put it at the end of the merge today. Andrew, does that make sense to you? --=20 Cheers, Stephen Rothwell ...

We have not got too much review, just because there are not so many people involved into the area. But we have got some review. The best one was Yes, we do this on regular basis. We have our own tests [1] ans we use older JFFS2 tests [2]. We also use it in Nokia and we have several users Thanks. [1] git://git.infradead.org/~dedekind/ubifs-userspace.git or http://git.infradead.org/users/dedekind/ubifs-userspace.git [2] git://git.infradead.org/mtd-utils.git or ...

When the 16MB zone overflows (which can be common in some workloads) calling the OOM killer is pretty useless because it has barely any real user data [only exception would be the "only 16MB" case Alan mentioned]. Killing random processes in this case is bad. I think for 16MB __GFP_NORETRY is ok because there should be nothing freeable in there so looping is useless. Only exception would be the "only 16MB total" case again but I'm not sure 2.6 supports that at all on x86. On the other ...

Then the allocator could still be stuck in ZONE_DMA32 on 64bit. Also d_a_c() does one "speculative" allocation, as in an allocation where it knows the zone is too large for the mask but it tries anyways because it often works. In that case too much trying is also not good. -Andi --

The case I'm discussing now is in hvm domains - ie, fully virtualized PC platform. I'm adding a driver to poke a hole through all the emulated hardware to get directly to the underlying Xen layer so that we can run paravirtual drivers to get better performance. Only the irqs associated In this case the sharing is between fully paravirtualized paravirt_ops Xen and pv-on-hvm drivers. In general I want those drivers to look as Something along the lines of passing -1 as the irq, and it ...

- I think using create_irq is a good step. - I think all vectors are wasted in the case of Xen. - I think we want a individual irq for each xen irq source. Sparc already does a demux in similar circumstances with a queue of received MSI messages an a single cpu irq that these get demuxed from. If we don't have individual irqs per drivers it will be hard to share a source base with native drivers. - I think it would be very nice if we could get irqs allocated in request_irq instead ...

Unless I misread the thread, akpm had a raft of issues with the first one, all of which were spelling except one initialization which he thought was not needed. All of those could be fixed in less effort that it takes to mention them, perhaps, but even so I think the patch could be ready in a short time. The problem looks worth fixing to me, but probably not a must have at the rc4 level. Maybe in 2.6.27 we could get rid of the potential race? -- Bill Davidsen <davidsen@tmr.com> ...

And here is a just-now hacked up patch. Untested, probably fails to compile. Just kicked off a light test run, will let you know how it goes. Thanx, Paul Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- include/linux/rcupreempt.h | 15 ++++++++- kernel/Kconfig.preempt | 15 +++++++++ kernel/rcupreempt.c | 71 ++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 99 insertions(+), 2 deletions(-) diff -urpNa -X dontdiff ...

Not that it makes much sense to have both included in the same kernel, but for the purpose of purity: Acked-by: Maciej W. Rozycki <macro@linux-mips.org> Maciej --

On Mon, 26 May 2008 12:53:18 -0400 We could but we use bsg_mutex to protect bsg_device_list and idr. So I think that we don't need hold bsg_mutex during bsg_complete_all_commands. How about this? diff --git a/block/bsg.c b/block/bsg.c index f0b7cd3..d81104e 100644 --- a/block/bsg.c +++ b/block/bsg.c @@ -721,8 +721,6 @@ static int bsg_put_device(struct bsg_device *bd) int ret = 0, do_free; struct request_queue *q = bd->queue; - mutex_lock(&bsg_mutex); - do_free = ...

I had wondered that, since data structures will grow w/ CONFIG_SECURITY set (like inode, for example). I haven't encountered a Kbuild dependency bug in quite a while though. thanks, -chris --

The sequence you write above is actually incorrect I think. Noone guarantees that the cookie returned by telldir() is valid after closedir(). What is a bigger (and quite common) problem is, if somebody uses readdir/telldir/seekdir while someone else creates/deletes files in the directory. The standard implies in this case that subsequent readdir should return all the files which were not touched (or all files after position set by seekdir if used...). Honza -- Jan Kara ...

Ok, thanks for suggestion. Will be done. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) --

On Tue, 27 May 2008 16:48:58 -0400 The patch does fix a race, by extending console_sem coverage to provide exclusion between the sysfs creation and teardown operations. I assume - no race was identified in the changelog. Can we actually simultaneously run con_open() and con_close() against the same device? I guess it might be possible if userspace tried hard enough. I renamed the patch to the much more accurate "vt: hold console_sem across sysfs operations" - "atomic" in the kernel ...

On Mon, May 26, 2008 at 10:06:44AM +0200, Jiri Slaby wrote: > On 05/26/2008 05:39 AM, S K wrote: > > and Fedora 9 with kernel 2.6.25.3-18.fc9.i686. > [...] > > I see this in dmesg: > > CPU 1 irqstacks, hard=c07ba000 soft=c079a000 > > Not responding. > > Inquiring remote APIC #1... > > ... APIC #1 ID: failed > > ... APIC #1 VERSION: failed > > ... APIC #1 SPIV: failed > > CPU #1 not responding - cannot use it. > > Booting processor 1/2 ip 4000 > > Not responding. > > Inquiring ...

I'd prefer not to kill the driver if device_create_file fails. Just arrange to print a warning instead (and remember not to unregister the file if it wasn't created.) --

It's not even protected with the old code. inline void __const_udelay(unsigned long xloops) { __delay(((xloops * HZ * cpu_data(raw_smp_processor_id()).loops_per_jiffy) >> 32) + 1); } Here it calculates the loops_per_jiffy for the CPU and calls into __delay. But it can easily be preempted here and the delay could run on another CPU. -- Steve --

[Maciej W. Rozycki - Wed, May 28, 2008 at 04:35:14PM +0100] | On Sat, 24 May 2008, Cyrill Gorcunov wrote: | | > apic_write_around will be expanded to apic_write in 64bit mode | > anyway. Only a few CPUs (well, old CPUs to be precise) requires | > such an action. In general it should not hurt and could be cleaned | > up for apic_write (just in case) | > | > Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> | > --- | | Acked-by: Maciej W. Rozycki <macro@linux-mips.org> | | Almost all ...

Well, nmi_watchdog=1 is the I/O APIC watchdog and if no watchdog has been specified at the command line, the piece of code you have moved selects between the local and the I/O APIC watchdog based on availability of the former. So in this case the local watchdog must have been unavailable as it works if requested explicitly. No piece of code in nmi_watchdog_default() touches peripheral hardware and native_smp_prepare_cpus() is called early enough the system is still running UP and no APIC ...

[Maciej W. Rozycki - Wed, May 28, 2008 at 06:47:56PM +0100] | On Wed, 28 May 2008, Cyrill Gorcunov wrote: | | > Thanks a lot, Maciej!!! Could you please explain me how did you find | > that? 'cause reporter said that with nmi_watchdog=2 it works and with | > nmi_watchdog=1 it stalls? Maybe I should better make this function | > the same as 64bit version has? I.e. set nmi_watchdog = NMI_NONE by default? | | Well, nmi_watchdog=1 is the I/O APIC watchdog and if no watchdog has been | specified ...

[Maciej W. Rozycki - Wed, May 28, 2008 at 06:09:38PM +0100] | On Wed, 28 May 2008, Cyrill Gorcunov wrote: | | > So I've moved a part of code (32bit) from proc_nmi_enabled() to | > nmi_watchdog_default() BUT this nmi_watchdog_default() also called | > from smpboot.c:native_smp_prepare_cpus() and before this patch | > this call was just an empty call (and eliminated by gcc I think) | > now it's not empy. But how it leads to hang I can't understand. | > The only thing is done - nmi_watchdog is set ...

That would be a huge improvement, but I'm afraid it would need someone far more familiar with floppy.c than I. I am beginning to figure out how to make it work though. The sequence goes something like this: 1. insert disk in drive, wait 5 minutes just in case, didn't help. 2. setfdprm /dev/fd0 COCO7203.5 3. getfdprm /dev/fd0 (fails, no such device) 4. dd if=/dev/fd0 bs=256 count=1 5. wait 20 to 40 secs for it to fail with an i/o error 6. setfdprm /dev/fd0 COCO7203.5 7. getfdprm ...

Yeah, the Amiga trick wouldn't work. The Amiga had no interleave. It didn't even have sector gaps. Just 11 consequtive sectors worth of data per track and one gap at the end of the track. I really doubt any other system could emulate that floppy access method without extra hardware. -- Len Sorensen --

Just do what the Amiga did: Read the entire track into a buffer in memory, then deal with the sectors, and write the entire track back. :) -- Len Sorensen --

On Wed, 28 May 2008 14:36:56 +0900 It is zeroed 2 statements down. if (!file) zone->recent_rotated_anon += pgmoved; /* * Now put the pages back on the appropriate [file or anon] inactive * and active lists. */ pagevec_init(&pvec, 1); pgmoved = 0; -- All rights reversed. --

On Wed, 28 May 2008 20:03:11 +0900 Good catch, I have applied your patch to my tree. -- All rights reversed. --

On Thu, 29 May 2008 00:42:52 +0900 You are right, of course. Looks like that code got mangled a little during one of the forward merges :) -- All rights reversed. --

On Wed, May 28, 2008 at 7:38 AM, Andrew Morton http://lkml.org/lkml/2007/1/2/238 Hope that helps :-) -- Guillaume --

ho hum, I've forgotten why I didn't like this. Let's give it a run. --

OIC. This, I guess... --- a/fs/fs-writeback.c~fs-writeback-handle-errors-in-sync_sb_inodes-fix +++ a/fs/fs-writeback.c @@ -500,7 +500,8 @@ void generic_sync_sb_inodes(struct super __iget(inode); pages_skipped = wbc->pages_skipped; err = __writeback_single_inode(inode, wbc); - mapping_set_error(mapping, err); + if (err == -EIO || err == -ENOSPC) /* xfs can return -EAGAIN */ + mapping_set_error(mapping, err); if (wbc->sync_mode == WB_SYNC_HOLD) { inode->dirtied_when = ...

Yes, I just saw it after I sent out my email. Let me try those patches. I'll revert back -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

Rik, I've run into a case where with the splitvm patches the memory controller immediately OOMs a task in the cgroup on exceeding it's limit. I am going to try and find the root cause for it. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

On Tue, 27 May 2008 11:54:02 -0400 In my understanding, 2 checks we have to do. 1. When memcg finds PG_noreclaim page in its LRU, move it to noreclaim list of memcg. 2. When PG_noreclaim page is moved back to generic LRU, memcg should move it on its list. (we have to add a hook somewhere.) But this may break current 'loose' synchronization between global LRU and memcg's LRU. When PG_noreclaim page is put back into active/inactive LRU ? concerns are A. how to implement '2' B. race ...

Yeah, Greg has added it to his series for tomorrow and I have added it to the end of linux-next for today. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

This is a fix against commit ce8568d9535b4756ea304a97ea803314ce895d3c Author: Greg Kroah-Hartman <gregkh@suse.de> Date: Thu May 22 17:21:08 2008 -0400 block: make proc files seq_start use the class_find_device() Use the proper class iterator function instead of mucking around in the internals of the class structures. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --

This driver adds support for reading and configuring certain information on modern HP laptops with WMI BIOS interfaces. It supports enabling and disabling the ambient light sensor, querying attached displays and hard drive temperature, sending events on docking and querying the state of the dock and toggling the state of the wifi, bluetooth and wwan hardware via rfkill. It also makes the little "(i)" button work on machines that send that via WMI rather than via the keyboard ...

- I see lots of user file I/O being done from within the kernel. This makes eyebrows raise. Also some other eyebrow-raising file-related things in there. - A complicated-looking in-kernel string parser which is implementing an new and apparently-undocumented user->kernel ABI. - Some GFP_ATOMICs which can hopefully become GFP_KERNEL. - timespec_set() is unneeeded - just use struct assignment (ie: "=") - timespec_recent() looks a bit hacky. The problems which are being solved ...

For robustness purposes it would be good to have a check that sizeof(pcrread) does not exceed READ_PCR_RESULT_SIZE. One way of doing that would be to add if (sizeof(pcrread) > READ_PCR_RESULT_SIZE) function_which_does_not_exist(); under the assumption that gcc will not emit the call. Or a plain old BUG_ON() in the init code somewhere. Or, better, implement all of this in a typesafe manner, using the C An unaligned access. What architectures is this hardware available ...

David, do you have any comments on this? I paste the example below for convenience. static void obj_list_add(struct obj *obj) { obj->active = 1; list_add(&obj->list); } static void obj_list_del(struct obj *obj) { list_del(&obj->list); obj->active = 0; } static void obj_destroy(struct obj *obj) { BUG_ON(obj->active); kfree(obj); } struct obj *obj_list_peek(struct list_head *head) { if (!list_empty(head)) { ...

-tip tree auto-testing found the following early bootup hang: --------------> get_memcfg_from_srat: assigning address to rsdp RSD PTR v0 [Nvidia] BUG: Int 14: CR2 ffd00040 EDI 8092fbfe ESI ffd00040 EBP 80b0aee8 ESP 80b0aed0 EBX 000f76f0 EDX 0000000e ECX 00000003 EAX ffd00040 err 00000000 EIP 802c055a CS 00000060 flg 00010006 Stack: ffd00040 80bc78d0 80b0af6c 80b1dbfe 8093d8ba 00000008 80b42810 80b4ddb4 80b42842 00000000 80b0af1c 801079c8 808e724e 00000000 ...

On Mon, 3 Sep 2007 10:17:39 +0200 Robert Richter <robert.richter@amd.com> wrote: Hi, As said before, I like the general approach. I have two comments below Comment 1: Can we make the 256/4096 thing conditional on actually having the feature somehow? (while not making the code TOO ugly) Comment 2: The cpu_has_XXX is a bit dubious; while it's dependent on your cpu model right now, I'm a bit hesitant to consider a PCI feature something that belongs in the cpu_has_XXX namespace. (Yes I ...

That sounds reasonable. We should also put #if defined(CONFIG_X86) around all the existing entries in the acpi_osi_dmi_table[]. -Tony --

The posix spec doesn't limit the errors returnable this way - it says if the error is one of the ones listed it must return the error code stated so Agreed - especially if it is opened with O_NDELAY --

Actually, it depends on how the card was defined. There are cards that only utilize the analog part of the cx23418, cards that can do both digital and analog at the same time and cards that can do either digital or analog. The cx18 driver supports the first two cases but not yet the last. Regards, Hans --

I don't think a lock would be good for MythTV or any other app that open()s multiple nodes at once. How can an app know that it's dead-locking or barring itself via the kernel driver? Maybe return an EBUSY or E-something else for these cases when Myth tries to open() the second device node, when there's an underlying factor that requires things to be mutually exclusive. Allowing things like read() to allow hardware mode switching between analog and digital seems like it could result in ...

On Wed, 28 May 2008 19:34:34 +0400 Most of the 36 bytes that the kobject take up are useless. The fields that _are_ useful are often useful to the hardware driver too, e.g. Right...I forgot about that restriction. Maybe static platform_devices Why not? Because a clock provider may decide to remove a clock I don't think BUG()ing is appropriate since the module providing the clock has no way of knowing whether it's ok to unregister the clock. Maybe we can do the ...

clk_get_rate() returns unsigned long, so we're screwed. I think we need You forgot to audit all drivers to make sure they handle bogus return I have to say I'm glad the "clk function" stuff is gone as I never Yes, I think it's less acceptable than the previous patchset. But if other people like this patchset better, I can always stay with my own "private" fields for a mid-layer that doesn't actually do anything No, I really wish I could, but I can't think of any way to remove ...

Acked-by: David Howells <dhowells@redhat.com> --

Okay, I've fixed things so that it gets things aligned properly with SLOB. This patch doesn't work for SLOB because SLOB doesn't set PG_slab on its pages. This causes: kernel BUG at mm/nommu.c:129! Or, as gdb sees it: Break 00000002 Program received signal SIGABRT, Aborted. 0xc0055498 in kobjsize (objp=<value optimized out>) at mm/nommu.c:129 (gdb) list 124 125 if (PageCompound(page)) 126 return PAGE_SIZE << compound_order(page); 127 128 BUG_ON(page->index < ...

Works for SLAB and SLUB. SLOB breaks well before getting to anything these patches affect. Acked-by: David Howells <dhowells@redhat.com> --

what was the change exactly ? we were seeing alignment problems on Blackfin and we fixed it with: http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=commitdiff;h=50... -mike --

Okay... The problem with SLOB is that it can return large objects (8Kb in this case) that aren't 8-byte aligned. This screws up FRV as it expects to be able to use load and store-double instructions, which fault if they don't get 8-byte (double register) alignment. David --

"deprecated", please. "depreciated" is where you don't want your investments to be. --- a/include/linux/capability.h~capabilities-remain-source-compatible-with-32-bit-raw-legacy-capability-support-fix +++ a/include/linux/capability.h @@ -31,7 +31,7 @@ struct task_struct; #define _LINUX_CAPABILITY_VERSION_1 0x19980330 #define _LINUX_CAPABILITY_U32S_1 1 -#define _LINUX_CAPABILITY_VERSION_2 0x20071026 /* depreciated - use v3 */ +#define _LINUX_CAPABILITY_VERSION_2 0x20071026 /* ...

Some correction about the test case hang, the ps output should looks like the following: 13925 S+ strace -f ./test1 13926 S+ ./test1 13927 T+ /bin/bash ./test2 I'm trying upstream kdump to get more detailed data for help analysis the scenario.. But unfortunately upstream kernel just hang when I echo c to sysrq-trigger. Downgrade the kernel to 2.6.22, 'echo c' doesn't hang, but I just got "zero" dump file... Will try F9 later... But from the symptom shouldn't we ask this question: why ...

Thanks for trying this combination. I discovered a task-leak in this loop (__load_balance_iterator): /* Skip over entities that are not tasks */ do { se = list_entry(next, struct sched_entity, group_node); next = next->next; } while (next != &cfs_rq->tasks && !entity_is_task(se)); if (next == &cfs_rq->tasks) return NULL; We seem to be skipping the last element in the task list always. In your case, the lone ...

Consider it tested too. David --

Hello all, AFAIK IPV6CP/PPP only allows to negotiate link local addresses. So I guess the global address and default route is assigned by another mechanism, maybe stateless autoconfiguration using router advertisement, although I was not aware it could be used on a PPP link because of the absence of MAC address. Enabling global forwarding (net.ipv6.conf.all.forwarding=1) disables stateless autoconfiguration (see ip-sysctl.txt in kernel documentation) on all interfaces. I believe I ...

On Tue, 27 May 2008 18:34:02 +0900 OK, thanks, let's give it a try. It would be excellent if we had some benchmark numbers which justify this change. It also would be good if we can think up some workload which might be slowed down by the change, and then demonstrate that this is not a significant problem. After all, it _is_ a performance patch... --

Done. --- Introduce IRQx_VECTOR on 32-bit, so that #ifdef noise is kept down. There should be no object code change. Signed-off-by: Pavel Machek <pavel@suse.cz> diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c index 7a0fda8..dc92b49 100644 --- a/arch/x86/kernel/i8259.c +++ b/arch/x86/kernel/i8259.c @@ -297,34 +297,28 @@ void init_8259A(int auto_eoi) * outb_pic - this has to work on a wide range of PC hardware. */ outb_pic(0x11, PIC_MASTER_CMD); /* ICW1: ...

Sorry, this will not work properly, as class_create() is now more commonly called, and it calls class_register() from within the driver core. So there would be a lot of classes with the same "key" because of this. So try changing class_create also. thanks, greg k-h --

Sorry, it's old and out dated. If you wish to refresh it and add it back, I'll gladly accept that patch. thanks, greg k-h --

But I think this document is still very useful and informative especially to those who are not quite familiar with UHCI HCDs. It is not necessary to remove this one at the moment. Regards Jason --

On Tue, 27 May 2008 11:24:08 +0530 I'm not sure what you mean exactly, but there might be other people who want to use the dma_ops stacking though I'm not sure yet how they use it: Andrew already put this patchset in -mm. Unless someone comes with a new reason against this patchset, it will be merged, I think. BTW, Andrew, really sorry about several compile bugs due to the first patch (changing dma_mapping_error) in this patchset. And thanks a lot for fixing them. --

Hi Andrew, Given that "trace_*" consists of wrapper functions around "relay" (relay + debugfs filesystem), I'm sending out the following patches which rename lib/trace.[ch] to kernel/relay_debugfs.[ch]. The "trace_*" functions are renamed to "relay_*" functions without any name-space clashes with existing "relay" functions. Now the new functions relay_printk() and relay_dump() will provide an easy-to-use interface for "relay" and will also reduce the amount of Along with the above ...

Sorry for the delays. I have revised this patch according to Maciej & Clemens suggestions. The modifications include: 1. Assign a irq to the timer when we open the timer device. I think it's better than do it in platform code. So we will have little impact on other device. 2. Set IRQ routing entry for the irq we select. 3. If we in PIC mode, we skip all the well known legacy IRQ. And in io apic we skip all the legacy IRQ. 4. Use level triggered mode by default. BTW, Maciej. I am ...

Good grief - you're right. I had only looked back nine months in my archives, as you can tell, from my last message, in which I recite some of that history. This saga has dragged on for two years now. Summary of what's transpired in the last two years: A] In the summer of 2006, Edgar Hucek submitted a patch that after some back and forth ended up doing pretty much what my latest patch does -- enabling the kernel to extract any EFI memory map entries and add them to the ...

We can do that later. For now it's better to give them distinct names. J --

commit 7f676fb7cf34dd2982d0cf79aeea7e5b06ad91eb Author: Jan Engelhardt <jengelh@medozas.de> Date: Wed May 28 10:00:41 2008 +0200 vt: fix background color on line feed, DEC invert Original report: """I used to force my console to black-on-white by the command `setterm -inversescreen on`. In 2.6.26-rc4, I get lots of black background characters.""" Another addendum to commit c9e587ab. This was previously missed out since I was not aware of what ...

I believe the kgdb tests should pass for this configuration, and the tests have been adjusted to support boards that do and don't have working hardware breakpoints. I queued the patch below into the for_linus branch for the 2.6.26 tree. Jason. --- From: Jason Wessel <jason.wessel@windriver.com> Subject: kgdbts: Use HW breakpoints with CONFIG_DEBUG_RODATA Whenever CONFIG_DEBUG_RODATA is set in the kernel config many kernel text sections become read-only, and the use of software ...

Dave, Considering that fixing the HW would take considerable time, I was wondering if the scheme we use in the nxge driver could be considered as a workaround. Since the niu driver is already doing skb_orphan as a work around, what if already transmitted TX buffers are reclaimed periodically, within dev->hard_start_xmit() ? Then TX_DESC_MARK would be set if/when available TX descriptor count falls below some watermark. Disable device TX queue about the time TX_DESC_MARK is set and ...

Ah nah.. for some reason I forgot to delete that line from the mail. But then it seems to be running for half an hour with 2.6.23.17 so far, so that may be a bisection helping point. Will report bisect findings as The voulme control for 'Headphones' is 0, but I do hear things, so I do use the "Master Front" mixer. (There is just one green (have not booted into 2.6.25 again yet, but will do) --

So the call from cfq_get_io_context() needs an rcu_read_lock()? Not seeing this in the patch below, but maybe you have it up a Looks much improved! Very interested to hear how it does with the testing. --

So that one was also OK, as Fabio pointed out. If you follow the ioc_gone and user tracking, the: if (elv_ioc_count_read(ioc_count)) wait_for_completion(ioc_gone); also has the side effect of waiting for RCU callbacks calling It's in there, it now does: rcu_read_lock(); cic = rcu_dereference(ioc->ioc_data); if (cic && cic->key == cfqd) { rcu_read_unlock(); return cic; } ... OK? ...

OK, looks good. --

--=-RJYjmwQH4n3IEhz6MAzZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Regenerated agains git HEAD, attached. Regards, Michael Karcher --=-RJYjmwQH4n3IEhz6MAzZ Content-Disposition: attachment; filename=huawei-id.diff Content-Type: text/x-patch; name=huawei-id.diff; charset=utf-8 Content-Transfer-Encoding: ...

Yeah it was a rwrite from scratch and it lived with the rd.c code for a while (although maybe never in mainline). I guess it might be good idea to rename it back to rd? --

I think Andrew prefered this test to be expanded but otherwise the patch is fine now. You can add: Acked-by: Jan Kara <jack@suse.cz> Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

Nope... but Andi Kleen sent a patch to put the warning on the irq stack rather than the main process stack, so it avoids the original problem It depends, I guess; if you have 8k stacks it'd probably fit ok in I don't actually know if systemtap can do what you want (not saying it can't; just saying I don't know...) -Eric --