Hello! Will talk about 2.6.25 kernel. I had recently a problem with marvell pata controllers. Exactly speaking of "IDE interface: Marvell Technology Group Ltd. 88SE6145 SATA II PCI-E controller", pci-id 11ab:6145. There is a (pseudo) driver in the kernel for handling that controller, called pata_marvell, but it doesn't claim the device. Instead, ahci driver claims that device, and then just does nothing. Devices connected to the marvell are not seen by kernel. After looking into the ...

Yinghai, I believe I have applied those patches correctly -- but I have only been using git since Aug. 4, so please verify that I have done what you asked. My git tree was originally created by cloning Linus' linux-2.6 tree. I ran into some difficulty applying the patches, but I found a way to allow them to apply: ===== SHELL SESSION ============= $ git apply --verbose --check ../split_e820_reserve.patch Checking patch arch/x86/kernel/e820.c... Checking patch ...

While 2.6.26 made my x61t work with the x6ultrabase, I find that once I have docked the x61t, I can only resume after a suspend2ram if the x61t is docked. That is: Never have been docked: suspend & resume works fine. Docked: suspend & resume works fine. Docked, undocked, re-docked: suspend & resume works fine. Docked, then undocked: never finishes resuming (the disk seems to spin up and the sleep led goes off, but the system doesnt seem to get any further). Any suggestions? attached ...

Hi! While running RIPLinux* 6.3, I got the below oops. What I did was boot up riplinux from USB key, start X, the run "reboot -f" on VT2. * - http://www.tux.org/pub/people/kent-robotti/looplinux/rip/ After the oops I run "reboot" again and got the same oops again. Note: I am not sure if I ran the 32 or 64 bit kernel. For kernel config and (3 smallish) patches see: http://www.tux.org/pub/people/kent-robotti/looplinux/rip/docs/kernel.txt (or ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11279 Subject : 2.6.27-rc0 Power Bugs with HP/Compaq Laptops Submitter : Matt Parnell <mparnell@gmail.com> Date : 2008-08-07 14:57 (24 days old) References : ...

This has been isolated (to disparate buggy BIOSes), patches written and tested. It's more policy decisions now; mainly whether the workaround (which wastes 64k) should be applied by default. So I think you should add Patch : http://marc.info/?l=linux-kernel&m=122001615314700&w=2 Regards Alan --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11438 Subject : Upcoming oops in lockdep Submitter : Arjan van de Ven <arjan@infradead.org> Date : 2008-08-23 20:49 (8 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11191 Subject : 2.6.26-git8: spinlock lockup in c1e_idle() Submitter : Mikhail Kshevetskiy <mikhail.kshevetskiy@gmail.com> Date : 2008-07-24 03:22 (38 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11410 Subject : SLUB list_lock vs obj_hash.lock... Submitter : Daniel J Blueman <daniel.blueman@gmail.com> Date : 2008-08-22 21:48 (9 days old) References : ...

Yes. I'm trying to bisect it but came across a bug/problem in git doing bisects. (see message subject "setlocalversion wasn't producing git labels for bisect") David --

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

From: "Rafael J. Wysocki" <rjw@sisk.pl> Should be fixed by: commit d3d7b53d1ae46534cd73e1073a5c29e3b61a0552 Author: Alan Cox <alan@lxorguk.ukuu.org.uk> Date: Fri Aug 22 19:24:15 2008 +0100 [netdrvr] fix build issue: undefined reference to `NS8390p_init' Signed-off-by: Alan 'pass the paper bags' Cox <alan@redhat.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> --

this should be closed commit 38cc1c3df77c1bb739a4766788eb9fa49f16ffdf x86: work around MTRR mask setting fixed it. YH --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404 Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr Submitter : rdunlap <randy.dunlap@oracle.com> Date : 2008-08-21 5:52 (10 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11460 Subject : 2.6.27-rc3 to -rc4 regression: init 0 hangs in halt Submitter : David Greaves <david@dgreaves.com> Date : 2008-08-30 04:07 (1 days old) --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11357 Subject : Can not boot up with zd1211rw USB-Wlan Stick Submitter : uwe <kender@freenet.de> Date : 2008-08-16 14:17 (15 days old) --

Not fixed yet. Larry --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11237 Subject : corrupt PMD after resume Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk> Date : 2008-08-02 9:51 (29 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11209 Subject : 2.6.27-rc1 process time accounting Submitter : Lukas Hejtmanek <xhejtman@ics.muni.cz> Date : 2008-07-31 10:43 (31 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11452 Subject : md (regression): reboot/shutdown hangs Submitter : Alistair John Strachan <alistair@devzero.co.uk> Date : 2008-08-28 19:05 (3 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11308 Subject : tbench regression on each kernel release from 2.6.22 -> 2.6.28 Submitter : Christoph Lameter <cl@linux-foundation.org> Date : 2008-08-11 18:36 (20 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11361 Subject : my servers with nvidia mcp55 nic don't work with msi in second kernel by kexec Submitter : Yinghai Lu <yhlu.kernel@gmail.com> Date : 2008-08-17 6:25 (14 days ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11335 Subject : 2.6.27-rc2-git5 BUG: unable to handle kernel paging request Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-08-12 4:18 (19 days old) References : ...

as far as I'm concerned this has nothing to do with lockdep --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11276 Subject : build error: CONFIG_OPTIMIZE_INLINING=y causes gcc 4.2 to do stupid things Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-08-06 17:18 (25 days ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11272 Subject : BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835 Submitter : Jaswinder Singh <jaswinderlinux@gmail.com> Date : 2008-08-05 15:12 (26 days old) References : ...

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

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11141 Subject : no battery or DC status - Dell i1501 Submitter : Gu Rui <chaos.proton@gmail.com> Date : 2008-07-21 19:43 (41 days old) Handled-By : Zhao Yakui <yakui.zhao@intel.com> --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11441 Subject : lots of 'in_atomic():1, irqs_disabled():0' with software-raid1 Submitter : jurriaan <thunder7@xs4all.nl> Date : 2008-08-27 17:05 (4 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11464 Subject : BUG: kernel-2.6.27-rc5: soft lockup - CPU#X stuck for 61s! Submitter : Thomas Backlund <tmb@mandriva.org> Date : 2008-08-30 12:46 (1 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11461 Subject : build breakage Submitter : Helge Deller <deller@gmx.de> Date : 2008-08-30 10:34 (1 days old) References : http://marc.info/?l=linux-kernel&m=122009254918593&w=4 Handled-By : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (10 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11271 Subject : BUG: fealnx in 2.6.27-rc1 Submitter : Jaswinder Singh <jaswinderlinux@gmail.com> Date : 2008-08-05 14:58 (26 days old) References : ...

Linus said we should register some entries in e820 later, so could let BAR res register at first, or even pnp? this one replace | commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd | Author: Yinghai Lu <yhlu.kernel@gmail.com> | Date: Mon Aug 25 00:56:08 2008 -0700 | | x86: fix HPET regression in 2.6.26 versus 2.6.25, check hpet against BAR, v3 v2: insert e820 reserve resources before pnp_system_init v3: fix merging problem in tip/x86/core please drop the one in tip/x86/core use this ...

You don't necessarily need control over the values that are written past the end of the buffer to exploit a buffer overrun bug. If those values are semi-random but predictable, it may still be possible to exploit the vulnerability by arranging to stash malicious code at the address that the return address will be overwritten with. Even if those values are random and not predictable, it may still be able to fill a large fraction of the address space with malicious code and thus have a ...

Trying to do a bisect with git version 1.5.6.3 didn't work with the setlocalversion script Running git name-rev --tags HEAD gives the output HEAD tags/v2.6.27-rc4~44^2 This isn't matched by setlocalversion regexp so it makes it harder to make deb-pkg/install/grub/reboot/remove Of course if this patch is accepted it is going to make life complicated when bisecting around it. Maybe git should behave as the man page suggests and have the ^X before the ~nnn? (maybe it has been fixed ...

On Sat, 30 Aug 2008 14:52:04 -0400 since half this sort of driver is in userspace it helps if you also add the version of the userspace driver you are using (and if you changed it recently) -- 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 --

Greetings all; A re-repeat of a previous posting which has not drawn a comment. With added content, added CC to a patch author, and some new questions. Machine is an F8 install, Athlon xp-2800 on an nforce2 motherboard, running an older radeon 9200SE (RV280 based) video card. No problems if I reboot to 2.6.27-rc4. I'm drowning in these errors: Aug 30 13:21:05 coyote kernel: [14927.850078] [drm] wait for fifo failed status : 0x80076100 0x00000000 Aug 30 13:21:05 coyote kernel: ...

[Cyrill Gorcunov - Sat, Aug 30, 2008 at 11:21:12PM +0400] | [Vegard Nossum - Sat, Aug 30, 2008 at 09:15:16PM +0200] | | On Sat, Aug 30, 2008 at 9:06 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | | > [Vegard Nossum - Sat, Aug 30, 2008 at 08:44:22PM +0200] | | > | Hi, | | > | | | > | I noticed that something weird is going on with /proc/sys/sunrpc/transports. | | > | This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When | | > | I "cat" this file, I get the expected ...

BTW, look at this: $ od -A x -t x1z /proc/sys/sunrpc/transports 000000 74 63 70 20 31 30 34 38 35 37 36 0a 75 64 70 20 >tcp 1048576.udp < 000010 33 32 37 36 38 0a 00 00 00 00 00 00 00 00 00 00 >32768...........< 000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 0003e0 00 00 00 00 00 00 00 00 00 00 >..........< 0003ea ...and: $ strace -e trace=read cat /proc/sys/sunrpc/transports > /dev/null read(3, ...

[Vegard Nossum - Sat, Aug 30, 2008 at 08:44:22PM +0200] | Hi, | | I noticed that something weird is going on with /proc/sys/sunrpc/transports. | This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When | I "cat" this file, I get the expected output: | | $ cat /proc/sys/sunrpc/transports | tcp 1048576 | udp 32768 | | But I think that it does not check the length of the buffer supplied by | userspace to read(). With my original program, I found that the ...

[Vegard Nossum - Sat, Aug 30, 2008 at 09:34:21PM +0200] | On Sat, Aug 30, 2008 at 9:21 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | > | Hm. I think this is wrong. Shouldn't we copy as many bytes as the user | > | indicated? | > | > Well, hard to say what user-space programmer is expecting from us. | > I mean - maybe he (reader) wants only part of results not the whole | > contents BUT by this way he never know what the whole conetnts would be | > until trying to read more (ie to check if ...

Sorry, I did it now :-) $ uname -a Linux grianne 2.6.27-rc5-00006-gbef69ea-dirty #4 SMP PREEMPT Sat Aug 30 22:07:18 CEST 2008 i686 i686 i386 GNU/Linux $ strace -e trace=read cat /proc/sys/sunrpc/transports > /dev/null read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320 \265\0004\0\0\0"..., 512) = 512 read(3, "tcp 1048576\nudp 32768\n\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4074 read(3, "", 4096) = 0 So that problem seems to ...

[Vegard Nossum - Sat, Aug 30, 2008 at 09:42:30PM +0200] | On Sat, Aug 30, 2008 at 9:06 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | > [Vegard Nossum - Sat, Aug 30, 2008 at 08:44:22PM +0200] | > | Hi, | > | | > | I noticed that something weird is going on with /proc/sys/sunrpc/transports. | > | This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When | > | I "cat" this file, I get the expected output: | > | | > | $ cat /proc/sys/sunrpc/transports | > | tcp ...

[Vegard Nossum - Sat, Aug 30, 2008 at 10:13:23PM +0200] | On Sat, Aug 30, 2008 at 10:04 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | > [Vegard Nossum - Sat, Aug 30, 2008 at 09:59:38PM +0200] | > | On Sat, Aug 30, 2008 at 9:56 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: | > | > | BTW, look at this: | > | > | | > | > | $ od -A x -t x1z /proc/sys/sunrpc/transports | > | > | 000000 74 63 70 20 31 30 34 38 35 37 36 0a 75 64 70 20 >tcp 1048576.udp < | > | > | 000010 33 32 37 36 ...

Greetings all; A repeat of a previous posting which has not drawn a comment. Machine is an F8 install, Athlon xp-2800 on an nforce2 motherboard, running an older radeon 9200SE video card. No problems if I reboot to 2.6.27-rc4. I'm drowning in these errors: Aug 30 13:21:05 coyote kernel: [14927.850078] [drm] wait for fifo failed status : 0x80076100 0x00000000 Aug 30 13:21:05 coyote kernel: [14927.861335] [drm] wait for fifo failed status : 0x80076100 0x00000000 Aug 30 13:21:05 coyote ...

Greg KH writes: > > --- linux-2.6.27-rc4-git6/block/cmd-filter.c.~1~ 2008-08-30 17:08:58.000000000 +0200 > > +++ linux-2.6.27-rc4-git6/block/cmd-filter.c 2008-08-30 17:36:36.000000000 +0200 > > @@ -215,6 +215,13 @@ int blk_register_filter(struct gendisk * > > if (!parent) > > return -ENODEV; > > > > + printk("%s: disk %p queue %p filter %p &filter->kobj %p\n", > > + __func__, disk, disk->queue, filter, &filter->kobj); > > + if (filter->kobj.state_initialized) { > > ...

Mikael Pettersson writes: > David Woodhouse writes: > > On Sat, 2008-08-30 at 19:04 +0200, Mikael Pettersson wrote: > > > I'll leave it to you guys to decide what the proper fix for this mess > > > should be. > > > > I believe it's already been sent to Linus. > > I can't find any mention of this in the post 2.6.27-rc5 commit log in > Linus' git tree as of right now. Care to provide a pointer to the fix? Never mind, found ...

Ick, no, don't go poking into the internals of a kobject like this to fix this kind of problem. If you really don't know if you have initialized this kobject or not, then you will have reference counting problems, which need to be fixed for real. thanks, greg k-h --

The recent commit 16d9679f33caf7e683471647d1472bfe133d858 changed check_hung_task() to filter out the TASK_KILLABLE tasks. We can move this check to the caller which has to test t->state anyway. Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> --- 2.6.27-rc4/kernel/softlockup.c~SOFTLOCKUP 2008-08-30 18:24:40.000000000 +0400 +++ 2.6.27-rc4/kernel/softlockup.c 2008-08-30 21:06:51.000000000 +0400 @@ -180,10 +180,6 @@ static void check_hung_task(struct task_ if (t->flags & PF_FROZEN) ...

DEAR: EMAIL ACCOUNT OWNER. We wish to inform you that we are undergoing account data upgrading, in order for your email account to be verify and remain active,you are to reply this message and enter your email ID and password in the space provide (.........).You are required to do this before the next 72hrs of receipt of this e-mail, Your email Account will be de-activated and erased fromour database. Send Your account upgrading information. Thank you for using our Webmail ...

I was looking at this code recently because it looks really bizarre when you create a half-petabyte filesystem: $ sudo insmod drivers/ata/ata_ram.ko capacity=1099511627776 preallocate=0 [12095.028093] ata7.00: 1099511627776 sectors, multi 0: LBA48 NCQ (depth 31/32) [12095.028093] ata7.00: configured for UDMA/133 [12095.041915] scsi 7:0:0:0: Direct-Access ATA Linux RAM Drive 0.01 PQ: 0 ANSI: 5 [12095.041915] sd 7:0:0:0: [sdc] Very big device. Trying to use READ ...

The capacity printk'd in bytes is divided by 1000000, whereas 1048576 would be more consistent with the rest of the OS and disk-related utilities ('df' etc.). This change replaces the (sz - (sz/625 - 974))/1950 calculation with a simple right shift by 11 bits (/2048). Signed-off-by: Simon Arlott <simon@fire.lp0.eu> --- drivers/scsi/sd.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index e5e7d78..e6fd6fd 100644 --- ...

Does MMC have the 10^3 requirement like SCSI/ATA disks do, or can you use 2^10 like standard computer stuff for capacities? James --

On Sat, 30 Aug 2008 11:45:16 -0600 I've been looking at doing something like this for the mmc_block driver, so a generic helper is welcome. :) --=20 -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

I think the most compelling reason for ensuring they're the same is that you can plug these devices into both an MMC slot directly and a card-reader and have them show up over USB. You don't want the reported capacity to change when you do that. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

On Sat, 30 Aug 2008 16:45:49 -0500 Some do, some don't. I prefer the 2^10 and MiB variants as it avoids ambiguity. Rgds --=20 -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.

/proc/partitions didn't use to write out the header if there was no partition. However, recent commit 66c64afe changed the behavior. This is nothing major but there's no reason to change user visible behavior without a good rationale. Restore the original behavior. Note that 2.6.28 has clean up changes scheduled which will replace this rather hacky implementation. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> --- ...

Thanks Balbir! --

Nevermind this "BUG: kernel-2.6.27-rc5: soft lockup - CPU#X stuck for 61s!." part ... It was caused by a Tomoyo patch that was not correct... This issue is still a real one, but I need to get some oops on it... I'll report back when I know more -- Thomas --

Hi, I tried your recipe. Well, not exactly. But I also got this during a kernel build. Notice that the kernel version is a clean v2.6.27-rc5 (i.e. latest Linus -git): BUG: soft lockup - CPU#1 stuck for 61s! [swapper:0] irq event stamp: 3585444 hardirqs last enabled at (3585443): [<c015927b>] trace_hardirqs_on+0xb/0x10 hardirqs last disabled at (3585444): [<c0290614>] trace_hardirqs_off_thunk+0xc/8 softirqs last enabled at (3585438): [<c0139fb1>] __do_softirq+0xe1/0x100 softirqs last ...

[Empty message]

This must absolutely be the least informative pull request ever! --

nice catch I have only an older version here, in that n is constant. maybe you can do a s/n/ctx->major/g ? removing the need for the whole variable ?! re, wh --

commit da574983de9f9283ba35662c8723627096e160de Author: Al Viro <viro@zeniv.linux.org.uk> [PATCH] fix hpux_getdents() - Missing checks for -EFAULT, broken handling of overflow. introduced a build breakage: CC arch/parisc/hpux/fs.o arch/parisc/hpux/fs.c: In function `filldir': arch/parisc/hpux/fs.c:107: error: `buffer' undeclared (first use in this function) make[1]: *** [arch/parisc/hpux/fs.o] Error 1 This patch fixes it. Signed-off-by: Helge Deller <deller@gmx.de> diff ...

On Sat, 30 Aug 2008 12:20:12 +0200 but... the leave_mm won't flush the global tlbs, while __flush_tlb_all() does, right? sounds like we do need the behavior --

This patch adds a PERL script that can be used to manipulate the sysfs attribute provided by pll_if. It can query the current state, change the state of the inactive PLL, and switch PLLs (assumming that the inactive PLL is locked to a valid frequency). My name is Kevin Diggs and I approve this patch. Signed-off-by: Kevin Diggs <kevdig@hypersurf.com> Index: Documentation/cpu-freq/pll.pl =================================================================== --- /dev/null 2004-08-10 ...

This patch includes various changes necessary to support the cpufreq driver for the PowerPC 750GX. Highlights include adding entries to recognize the 750GX to the cputable (This includes the ... unfortunate pvr that the 750GX used in the PowerLogix PowerForce 750GX => 0x0008 0203). The PLL switch in idle_6xx.S during sleep (or nap) was also removed (I tried to add ability to disable this but the result would not boot?). My name is Kevin Diggs and I approve this patch. Signed-off-by: Kevin ...

This adds a small module to handle the low level details of dealing with the PLL config register (HID1) found in the IBM 750GX. It provides 2 possible interfaces, both selectable via kernel config options. One is a sysfs attribute and the other is a normal function API. It is called pll_if. The determination of the bus frequency is what worked on a PowerMac 8600. Any suggestions on a more general solution are welcome. After receiving comments, I added an argument for the data item to ...

Hi, This patch set adds a cpufreq driver for the IBM PowerPC 750GX processor. It "should" also work for the 750FX. The patches are: 1) Add low level PLL config register interface module 2) Add cpufreq driver for the 750GX 3) Other PowerPC kernel changes necessary to support the above 4) Add kernel doc for the completion feature, fix split-man.pl in kernel-doc-nano-HOWTO.txt 5) Add pll script to interface with pll_if sysfs attribute These changes are against 2.6.26. Thanks for ...

Please do `echo w > /proc/sysrq-trigger', send the resulting trace. --

Remove stop_machine during module load v2 module loading currently does a stop_machine on each module load to insert the module into the global module lists. Especially on larger systems this can be quite expensive. It does that to handle concurrent lock lessmodule list readers like kallsyms. I don't think stop_machine() is actually needed to insert something into a list though. There are no concurrent writers because the module mutex is taken. And the RCU list functions know how to ...

even with known_bridge insert them late too. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/pci/mmconfig-shared.c =================================================================== --- linux-2.6.orig/arch/x86/pci/mmconfig-shared.c +++ linux-2.6/arch/x86/pci/mmconfig-shared.c @@ -209,7 +209,7 @@ static int __init pci_mmcfg_check_hostbr return name != NULL; } -static void __init pci_mmcfg_insert_resources(unsigned long resource_flags) +static void __init ...

print out for Device BAR address before kernel try to update them. also change it to KERN_DEBUG instead... Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index cce2f4c..4ee06c3 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -304,6 +304,8 @@ static int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, } else { res->start = l64; res->end = l64 + sz64; + printk(KERN_DEBUG "PCI: %s reg %x 64bit ...

Hi all, The lines 522-523 in function do_acct_process in file kernel/acct.c in version 2.6.26.3 are: file->f_op->write(file, (char *)&ac,sizeof(acct_t), &file->f_pos); What are the full set of targets of this function pointer invocation and how can one be sure, by examining the code, that this is in fact the complete set? Thanks. SKB --

Not sure if you wanted ME to test this, but I've been watching this argument with Yinghai and became curious... I updated my git tree so that I have the insert_resource_expand_to_fit() changes, and the kernel builds fine. Unfortunately, it hangs like all 2.6.2[67] kernels without reverting 3def3d6d... and 1e934dda... (or without the later patches provided by Ingo and Yinghai). Sorry if I am interfering... just wanted to inject this data, in case it's meaningful! Dave W. --

Do you know of any reasonably cheap USB TMC devices out there that I could buy to help test this driver here? I looked at the device that thanks, greg k-h --

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- drivers/char/sysrq.c | 30 ++++++++++++++++++++++++++++++ fs/proc/proc_misc.c | 26 -------------------------- 2 files changed, 30 insertions(+), 26 deletions(-) --- a/drivers/char/sysrq.c +++ b/drivers/char/sysrq.c @@ -23,6 +23,7 @@ #include <linux/reboot.h> #include <linux/sysrq.h> #include <linux/kbd_kern.h> +#include <linux/proc_fs.h> #include <linux/quotaops.h> #include <linux/kernel.h> #include ...

size-32: 3511 kvasprintf+0x57/0x90 size-64: 3059 kobject_create+0x1c/0x40 These two buddies increase after every "modprobe; rmmod" sequence. --

mdelay(10) replaced by msleep(10) to give up the CPU, it's just waiting for an interrupt, so timing isn't critical. Signed-off-by: David Fries <david@fries.net> Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> --- drivers/net/ne.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ne.c b/drivers/net/ne.c index b0bf47e..bcbeff7 100644 --- a/drivers/net/ne.c +++ b/drivers/net/ne.c @@ -529,7 +529,7 @@ static int __init ...

There are already some msleep() in probe_irq_on() which is called just before here. And this part is not protected by any spinlock or preempt_disable. So, if rescheduling was dangerous here, we already have potential problems, no? --- Atsushi Nemoto --

There is a probing_active mutex. probe_irq_off has the comment "nothing prevents two IRQ probe callers from overlapping." Looks to me I was just going to make the argument that any task that could be run during msleep, could just as easily run on the other cpu in mdelay (if there was one). -- David Fries <david@fries.net> http://fries.net/~david/ (PGP encryption key available) --

The res->name might be NULL. You should check it first. if (res->name && !strcmp(res->name, BAD_STR)) dev->mem_end = BAD; --- Atsushi Nemoto --

Based on Christoph Hellwig's TPM internal kernel interface locking question, the following TPM changes were made: - removal of the BKL calls from the TPM driver, which were added in the overall misc-char-dev-BKL-pushdown.patch - continue to protect the tpm_chip_list using the driver_lock, and add an rcu to protect readers. The TPM internal kernel interface patch will be posted as part of the integrity patchset. drivers/char/tpm/tpm.c | 285 ...

This patch removes the BKL calls from the TPM driver, which were added in the overall misc-char-dev-BKL-pushdown.patch, as they are not needed. In addition, renames num_open to is_open, as only one process can open the file at a time. Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com> --- drivers/char/tpm/tpm.c | 35 ++++++++++++++++++----------------- drivers/char/tpm/tpm.h | 2 +- 2 files changed, 19 insertions(+), 18 ...

Hello again I dug a little more and found out some new info. Unsolved bugreport with same symptoms: http://marc.info/?l=linux-kernel&m=119613299024398&w=2 Problems appear if I start br0 interface, as context switch rate increases 200 times. If I start eth0 instead everything looks ok. The bugreport above had bridging enabled too. When using eth0 I get: vmstat -n 1 10 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si ...

[Empty message]

On Fri, 29 Aug 2008 16:34:26 -0700 sure. The code looks rather miserable in an 80-col display. there's also WARNING: braces {} are not necessary for single statement blocks #119: FILE: dyn_array.c:119: + if (da->init_work) { + da->init_work(da); + } and checkpatch should have detected the misplaced semicolon here: + for (daa = __per_cpu_dyn_array_start ; daa < __per_cpu_dyn_array_end; daa++) { but didn't. --

Sorry, I don't quite understand that last sentence. But we definitely have compile time errors here because the compiler doesn't even know of ide_proc_entry_t when CONFIG_IDE_PROC_FS is not set. Therefore the forward declarations appear to be syntactically incorrect, regardless whether extern or not. Regards, Elias --

Ah, you probably mean to turn the possible link time errors if the do get referenced into the compile time errors... MBR, Sergei --

I think it says "supported" where the feature can't be disabled and "enabled" where it can. Otherwise, this would make a little sense indeed. Hm, I even found a quote in ATA/PI-7 rev. 4b backing this claim (should've pasted it into previous mail): 6.17.43 Words (87:85): Features/command sets enabled Words (87:85) shall indicate features/command sets enabled. If a defined bit is cleared to zero, the indicated features/command set is not enabled. If a supported features/command set is ...

Yes, I tend to agree with you and, in fact, I have been leaning in this direction myself. However, there is something that really bothers me. Both entries describing bit 13 of word 87 and 84 are worded alike. In particular, it says *supported* in both places, whereas in the case of the other features it would say enabled in one and supported in the other place. Well, I'm willing to drop the check for word 87 since I don't like it myself. Due to my lack of personal experience with ...

Yeah, you have a point. I still think this patch will solve the deadlock thing, so please consider it in the interim. I will whip up a full PI solution next week. -Greg

Since we're talking -rt here, determinism rules, so bite the bullet and do full PI. The only reason we made all that stuff preemptable is to gain determinism, that also means we have to do the PI thing. --

Why? A full rwlock will still be much slower since the readers will always need an atomic op. This construct only uses atomic ops in the slow path under contention, which should be rare, and is thus still Ouch. While I admit that you can still get into inversion scenarios once the reader leaves the seqbegin, this is the nature of seqlocks.=20 The only ways I can think of to get around this involve atomic ops in the fast path, which I think should be avoided. What would you ...

Thank you for taking interest. The files are attached. The card is a nvidia card, but I use it in VESA mode because the binary driver hangs the machine once or twice a week. Helge Hafting

gcc indeed knows about memset(), and will generate just two stores. No worries, Linus --

Of course :-) dmesg is attached with patch applied. At the end of the patch it (of course) continues, but only with: ata1: EH complete ata1: EH complete ata1: EH complete Hmn, to take my pants down entirely: What is this "EH"? And how does the change of the .reset function affect this? May be, I You are right, it started immediately without a hitch this morning after sleeping entirely for a couple of hours. Kind Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B ...

On Fri, 29 Aug 2008 16:28:24 +0200 Really sorry about that. A fix was queued in Jens' tree: Right, the problem is that MTD uses the same queue for multiple gendisks. It would be great if a MTD developer could fix it. Thanks, --

The main thing that's missing for JFFS2 is "Compress as much of this as you can into X bytes" -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --

* Peter Zijlstra <peterz@infradead.org> [2008-08-30 13:26:53]: The above code helps a quad-core CPU to be treated as two dual core for performance when sched_mc_power_savings=0 and they will be treated as one quad core package if sched_mc_power_savings=1 since the power control (voltage control) is per quad core socket. On a dual socket machine with two quad core cpus, sched_mc_power_savings=0 will build: CPU0 attaching sched-domain: domain 0: span 0,2 level MC groups: 0 2 ...

Same for my dual-core Opteron 12xx, due to this code it normally I realized what its good for, I'm just not sure I agree with it. I'm feeling there is something wrong with this, just can't quite put my finger on it. I'm just feeling the domain structure should be invariant to such things - its the same hardware after all, whether we schedule to optimize for power or performance. --

Hi, All these ticket lock patches look pretty good to me. Thanks for going over it so thoroughly. --

Can this git send-email thing sanely thread these days? It used to be that each next email was threaded to the next, creating these insanely deep threads. quilt mail threads all subsequent emails from the first mail, not from the previous - a mode I much prefer. --

What kernel should I apply those to and in what order? Rafael --

cat /proc/iomem please. YH --

On Sat, Aug 30, 2008 at 10:39 AM, Linus Torvalds again, should use MCFG end as the res _end YH --

Could you please rebase them on top of current -git? Rafael --

Are you really really sure? Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI BAR's to work with the e820 resources, then BUSY really is simply not right any more. Not that I think it should matter either.. The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones that cover RAM), but the others we now expect to nest with PCI BARs. But since we add them after we have parsed the BAR's, I don't even see why the BUSY bit should even matter - we've ...

00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part Subsystem: ATI Technologies Inc RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Region 3: Memory at <ignored> (64-bit, non-prefetchable) Capabilities: [c4] HyperTransport: Slave ...

http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-tv.txt http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/lspci-vvxxx.txt http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/proc_iomem.txt Thanks, Rafael --

Btw, looking at that bogus BAR#3 some more: I don't actually think it's even an MCFG resource. I think it's literally the resource that describes the HT window for the host bridge. So it's literally like the "root" resource - all external MMIO resources that go over HT have to be in that window. IOW, I'm starting to think that it's not even broken. It is probably perfectly real. It's not a "PCI bridge" in the sense that it doesn't bridge one PCI bus to another, but it's a host ...

On Fri, Aug 29, 2008 at 6:11 PM, Linus Torvalds we reverted the commit , David's problem still happen. the root cause is: before 2.6.26, call init_apic_mapping and will insert_resource for lapic address. and then call e820_resource_resouce (with request_resource) to register e820 entries. so the lapic entry in the resource tree will prevent some entry in e820 to be registered. later request_resource for BAR res (==hpet) will succeed. from 2.6.26. we move lapic address registering to ...

On Sat, Aug 30, 2008 at 12:41 PM, Linus Torvalds Those BIOS porting guide need extra NDA... they don't want to everyone know that there is lots workaround for their silicon bugs. YH --

On Fri, Aug 29, 2008 at 5:45 PM, Linus Torvalds the quirk work at the first point for David' system. [PATCH] x86: protect hpet in BAR for one ATI chipset v3 so avoid kernel don't allocate nre resource for it because it can not allocate the old address from BIOS. the same way like some IO APIC address in BAR handling v3: device id should be 0x4385 Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- drivers/pci/quirks.c | 16 ++++++++++++++++ 1 file changed, 16 ...

On Fri, Aug 29, 2008 at 5:08 PM, Linus Torvalds the BAR is from pci_read_bases..., so that chipset is broken... they are even supposed to to hide that BAR to os. YH --

Now, this is probably fine too in theory, but - you didn't check if the BAR is even enabled, afaik - the other patch - to move the reserved e820 range later - should make No, I think this is worth doing, BUT IT MUST NOT BE MERGED BY JUST SENDING IT TO INGO. It's not an "x86 patch". It's about the PCI resources. And those kinds of patches need to be acked by people who know and understand the PCI resource issues and have some memory of just how broken machines can ...

Btw, what was the original regression that commit was a2bd7274b47124d2fc4dfdb8c0591f545ba749dd trying to fix? It's not listed in that commit, even though the commit has a "Bisected-by: David Witbrodt <dawitbro@sbcglobal.net>". In fact, I can find it with google by searching for David Witbrodt bisect and I see that it is 3def3d6ddf43dbe20c00c3cbc38dfacc8586998f. I'm wondering why that commit wasn't just reverted? Because now that I see it, I notice that _that_ is the real bug to ...

Ok, and here's the patch to do insert_resource_expand_to_fit(root, new); and while I still haven't actually tested it, it looks sane and compiles to code that also looks sane. I'll happily commit this as basic infrastructure as soon as somebody ack's it and tests that it works (and I'll try it myself soon enough, just for fun) Linus --- include/linux/ioport.h | 1 + kernel/resource.c | 88 ++++++++++++++++++++++++++++++++++------------- 2 files changed, 64 ...

On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds not all. some are MMCONF, some are for GART, and some for fixed lapic, if we don't add the IORESOURCE_BUSY, why bother to add these entries... good layout from BIOS, it should only reserve mmio range is not showing in BAR. for example: 0xdc000000 - 0xdd000000 for GART ( some offset BAR 0x94) 0xdd000000 - 0xde000000 is for bus 0x80 0xde000000 - 0xdf000000 is for bus 0x00 0xe0000000 - 0xf0000000 is for mmconfig ( CPU set it in MSR for amd fam ...

please check fix v3 [PATCH] x86: split e820 reserved entries record to late v4 - fix v3 try to insert_resource second time, by expand the resource... for case: e820 reserved entry is partially overlapped with bar res... hope it will never happen v3: use reserve_region_with_split() instead to hand overlapping with test case by extend 0xe0000000 - 0xeffffff to 0xdd800000 - get e0000000-efffffff : PCI MMCONFIG 0 e0000000-efffffff : ...

On Fri, Aug 29, 2008 at 7:33 PM, Linus Torvalds orginally it works, because lapic address entry open the big hole for if update res->end according mmconfig end, before insert it forcibly, BTW, insert_resource_expand_to_fit need to be replaced with insert_resource_split_to_fit.... test stub reveal expand will make __request_region not working for some devices...because reserved_entries from e820 take IORESOUCE_BUSY... YH --

there is some problem with fix -v4...on one test machine. please don't use it now YH --

dmesg -s 262144 http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/dmesg-test.log cat /proc/iomem http://www.sisk.pl/kernel/debug/mainline/2.6.27-rc5/iomem-test.txt Thanks, Rafael --

Ok, the more I look at this, the more interesting it gets. In particular, this: ... ACPI: bus type pnp registered pnp 00:08: mem resource (0xfec00000-0xfec00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling pnp 00:08: mem resource (0xfee00000-0xfee00fff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling pnp 00:09: mem resource (0xffb80000-0xffbfffff) overlaps 0000:00:00.0 BAR 3 (0xe0000000-0xffffffff), disabling pnp 00:09: mem resource ...

On Sat, Aug 30, 2008 at 11:43 AM, Linus Torvalds do you agree to use quirk to make the BAR res to have correct end between pci_probe and pci_resource_survey? YH --

On Sat, Aug 30, 2008 at 12:31 PM, Linus Torvalds wonder: in old kernel, after BAR3 request_filed, pci_assigned_unassigned should get update resource for that... but it could find that big space for it. that is interesting... YH --

I've just tested these two patches on top of the current Linus' tree and the system works normally. Thanks, Rafael --

On Sat, Aug 30, 2008 at 3:41 PM, Linus Torvalds wait, THAT BAR is 64BIT capable, So kernel should assign 64bit range to it... not touch it at this time... except Jordan could find some clue with the DOC. YH --

On Sat, Aug 30, 2008 at 4:28 PM, Linus Torvalds would be some corner case... didn't see anything there. calling pcibios_assign_resources+0x0/0x90 request_resource: root: (PCI Bus 0000:01) [fe700000, fe7fffff], new: (0000:01:00.0) [fe7c0000, fe7dffff] conflict 0 request_resource: root: (PCI Bus 0000:03) [fe900000, fe9fffff], new: (0000:03:00.0) [fe9c0000, fe9dffff] conflict 0 pci 0000:00:02.0: PCI bridge, secondary bus 0000:01 pci 0000:00:02.0: IO window: 0x9000-0x9fff pci ...

Ok, so it's similar to the local APIC in that respect (and presumably IO APIC too, I haven't checked). But that still just implies that the BAR probably means something else totally, and the fact that it happens to have the same value as the MCFG Yeah, I'm not finding anything either. The 690G databook that Rafael pointed to does mention the config registers in passing, but it's really just about electricals (pin setup etc). No BIOS writers guide indeed.. Linus --

I will indeed continue to work on getting rid of the checkpatch.pl warnings/errors during the upcoming weeks. I already eliminated the ones I could figure out without too much effort; I am sure the remaining ones are trivial to many of you out there, so I welcome Thanks, Brian G. Merrell --

I think there will have to be at least one more pass at this. The current design assumes that all debug registers support an identical set of the I, R, and W bits and Mask. However sections 8.23 and 8.24 of my MIPS32® Architecture For Programmers Volume III: The MIPS32® Privileged Resource Architecture indicate that they do not have to uniform. I will have to augment the ptrace structures to report the values for each register instead of a single global value. David Daney --

Hm, and this is exactly the case for the "do_not_encrypt" field of skbuff: #ifdef CONFIG_IPV6_NDISC_NODETYPE __u8 ndisc_nodetype:2; #endif #if defined(CONFIG_MAC80211) || defined(CONFIG_MAC80211_MODULE) __u8 do_not_encrypt:1; #endif So we have no way to know where or how big the filler should be. This is why the simple patch above is not sufficient. Alexey: I have a modified proposal with slightly different syntax ...

Well, NBD is the bird in hand, but that doesn't mean it's the best way to do things generically for all block device emulation applications. I'd even argue that NBD should be removed from the kernel and replaced by BUSE plus a user-land daemon. A BUSE interface could be a lot more general, and simpler. Not to mention that converting all block reads and writes to TCP operations that talk to another process on the same machine via the loopback interface seems awfully ...

My gutt feeling is that it would have less overhead when done via FUSE than through nbd, but that could be wrong. Mike --

I guess this isn't code pages. So, Can you observe /proc/{pid}/smaps file? it tell you detail of these pages. Thanks. --

The name "cleanup_module" is special. I think this should not be used outside #ifdef MODULE. Please rename it something like Thanks. You killed two .name and there are still two .name in ne_probe. --- Atsushi Nemoto --

ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

I wrote and used the patch once, as I wanted to know which program in a lengthy multiple-program test suite was triggering the problem. That made it easier coming up with a shortened test that would replicate the problem. However I only needed it that one time so this patch can be considered to be exceptionally optional :) Joe --

I have no objection... Joe --

Of course it's useful. If you're working on performance or latency in a disk, network or USB driver, microsecond resolution is about right. --

Hello, Yeap, in retrospect, enabling BLOCK_EXT_DEVT by default seems too disruptive. There also are people running off static /dev. I hope distros enable it during their alphas and betas tho so that they can Maybe we can add a warning there if BLOCK_EXT_DEVT is enabled or do you have something else on mind? Thanks. -- tejun --

I don't like this patch in it's current form. Having two different ways to do ptrace is a rather awkward thing and not very good for testing coverage. This should not be an option but required. I'm not even sure keeping a non-utrace version at all is a good idea. I'd rather set a deadline for arch maintainers to convert everything to the generic ptrace bits + regsets + tracehook and if they don't manage to do it by then ptrace will be disabled for those who can't keep up. Of course this ...

Yes, I've also said this went the old monolithic utrace was first posted (probably over a year ago) and it was conveniently ignored.. --

No. Admittedly, we have not yet started to take care of the 2.6.26 RT tree. Finishing the 2.6.24 RT tree was quite difficult and took somewhat longer than earlier trees so we now really need to use it and to integrate it into the various industrial projects that waited long enough for it. This will certainly keep us busy during the next weeks or so. Unfortunately, the "Bad page state" is not the only regression. Currently, we know of the following problems in 2.6.26.3-rt3: - Bad page state - ...

I know, I'm David Balažic (the last commenter on bug, besides you) ;-) Regards, David --

I just had a fast review. so my comments is nothing but cleanup. Thanks, Lai. I tried a mask like qsmaskinit before. The system came to deadlock when I did on/offline cpus. I didn't find out the whys for I bethought of these two problem: problem 1: ----race condition 1: <cpu_down> synchronize_rcu <called from offline handler in other subsystem> rcu_offline_cpu -----race condition 2: rcu_online_cpu synchronize_rcu <called from online handler in other ...

Very cool!!! I see one of his patches at http://lkml.org/lkml/2008/4/17/342, but how do I find out which branch of -tip this is on? (I am learning git, but it is a slow process...) This would also simplify preemptable RCU's dyntick interface, removing the need for proofs. Thanx, Paul --

Hello! Still experimental, not for inclusion. But getting better! Updates from v2: o Fixed a number of bugs uncovered by running rcutorture in parallel with onlining and offlining CPUs. Many of these were due to the fact that there can be a multiple-grace-period window during which RCU and the process scheduler disagree about whether a given CPU is offline. The solution was to make force_quiescent_state() check for RCU waiting on offlined CPUs, and then cleaning up all the ...

That works -- thank you!!! --

Not sure - my git-foo isn't good enough either :-( All I can offer is that its available in tip/master (the collective merge of all of tip's branches) as commit: 0d84b78a606f1562532cd576ee8733caf5a4aed3, which I found using git-annotate include/linux/hardirq.h How to find from which particular topic branch it came from, I too am clueless. --- commit 0d84b78a606f1562532cd576ee8733caf5a4aed3 Author: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Date: Mon May 12 21:21:07 2008 ...

It's been so for a while, guess since 2.5. I meant to say the pci_remove_bus_device(), not pci_remove_bus(), is used by pci hotplug code. If a device is being plugged off, and some drivers are calling pci_get_dev_by_id() to search something, then the warning might be fired through bus_find_device -> klist_iter_init_node ->kref_get. Thanks, --

Debugging code can be added to apic_write() and io_apic_{write,modify}() so that a warning is output into the kernel log whenever a suspicious value is written to one of the vector registers. Similarly for MSI/HT interrupts, although I do not know names of the functions involved off the head. Due to performance considerations it is unfortunately infeasible to have such debugging enabled in production kernels. Maciej --

Could you please provide some more specific debugging instructions? I'm at a complete loss what I should do here. I just re-read the rest of the thread, but I'm afraid most of it is Greek to me :-/ TIA, FJP --

There is a difference. You *have* to pick some value for those things. The settings can't necessarily be called correct or incorrect. The default rt sched policy is definitely "broken" in that it very clearly changes our previous behaviour, documentation, and what other systems do. You could say that "realtime" in general is not really a single accepted definition, but *SCHED_FIFO* and *SCHED_RR* in particular do have a well defined, simple, and widely accepted definition that is undeniably ...

It appears to be working again as of ee096f75b69913dbad0e6f7f2572513de5c90002. -- Simon Arlott --

The patch seems to do exactly what I was looking for! Details further down, but first some other comments. My first boot with your patch was with brltty still enabled. The log showed the right result, but I wanted to get a cleaner log without all the USB suspend/resume noise caused by brltty. So I disabled brltty's init script and rebooted. This gave a totally unexpected result: ehci now got loaded and initialized _before_ uhci which of course avoids the problem altogether (see ...

I got lucky on the second boot with -rc5 and USB_DEBUG enabled. Attached the output of dmesg. After this boot the keyboard was dead and the telltale "reset low speed USB device" message is present. Cheers, FJP

Not really. It provides approximately no complexity for Linux drivers, and makes it easier for vendors to provide Windows support. WMI has not been the hard bit of the drivers I've written. I don't see any reason to ask vendors not to use it, as long as they're willing to document their implementation. -- Matthew Garrett | mjg59@srcf.ucam.org --