Re: Truecrypt in kernel ?
On Mon, 5 Nov 2007 20:42:39 -0500 "Zurk Tech" <[EMAIL PROTECTED]> wrote: > just wondering why the truecrypt module isnt in the mainline kernel ? > its the only cross platform encrypted disk solution out there and it > should be less of a chore to use it in linux...is there something > wrong with the truecrypt kernel driver ? Two reasons: The author hasn't sent patches. It looks to me the license is incompatible with the GPLv2. Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On Sun, 26 Aug 2007 07:09:02 -0700 Jiri Slaby <[EMAIL PROTECTED]> wrote: > stk11xx, add a new webcam driver > > Adds support for stk1125, stk1135 and stkdcnew webcam built-in some > notebooks. Seem that something in git-dvb (or mainline) broke this driver: drivers/media/video/stk11xx-core.c: In function 'show_contrast': drivers/media/video/stk11xx-core.c:707: warning: initialization from incompatible pointer type drivers/media/video/stk11xx-core.c: In function 'show_whitebalance': drivers/media/video/stk11xx-core.c:714: warning: initialization from incompatible pointer type drivers/media/video/stk11xx-core.c: In function 'stk11xx_create_sysfs_file': drivers/media/video/stk11xx-core.c:727: warning: passing argument 1 of 'class_device_create_file' from incompatible pointer type drivers/media/video/stk11xx-core.c: In function 'stk11xx_usb_disconnect': drivers/media/video/stk11xx-core.c:851: warning: passing argument 1 of 'class_device_remove_file' from incompatible pointer type drivers/media/video/stk11xx-core.c:853: warning: passing argument 1 of 'class_device_remove_file' from incompatible pointer type Also, please ask the v4l/dvb guys to look at this driver - there's not a lot of point in sending it just to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] x86: unification of cfufreq/Kconfig
On Sun, Nov 04, 2007 at 12:51:11AM +0100, Sam Ravnborg wrote: > @@ -26,7 +29,7 @@ config X86_ACPI_CPUFREQ > config ELAN_CPUFREQ > tristate "AMD Elan SC400 and SC410" > select CPU_FREQ_TABLE > -depends on X86_ELAN > +depends on X86_32 && X86_ELAN > ---help--- >This adds the CPUFreq driver for AMD Elan SC400 and SC410 >processors. > @@ -42,7 +45,7 @@ config ELAN_CPUFREQ > config SC520_CPUFREQ > tristate "AMD Elan SC520" > select CPU_FREQ_TABLE > -depends on X86_ELAN > +depends on X86_32 && X86_ELAN > ---help--- >This adds the CPUFreq driver for AMD Elan SC520 processor. X86_ELAN should depend on X86_32 rather than adding this everywhere. > config X86_POWERNOW_K7 > tristate "AMD Mobile Athlon/Duron PowerNow!" > select CPU_FREQ_TABLE > +depends on X86_32 > help >This adds the CPUFreq driver for mobile AMD K7 mobile processors. > > @@ -76,23 +81,27 @@ config X86_POWERNOW_K7_ACPI > bool > depends on X86_POWERNOW_K7 && ACPI_PROCESSOR > depends on !(X86_POWERNOW_K7 = y && ACPI_PROCESSOR = m) > +depends on X86_32 > default y This 2nd hunk shouldn't be necessary, as it depends on X86_POWERNOW_K7 which you just added the 32bit dependancy to. > config X86_SPEEDSTEP_RELAXED_CAP_CHECK > bool "Relaxed speedstep capability checks" > -depends on (X86_SPEEDSTEP_SMI || X86_SPEEDSTEP_ICH) > +depends on X86_32 && (X86_SPEEDSTEP_SMI || X86_SPEEDSTEP_ICH) Should also be unnecessary due to those items now being 32bit dependant. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] md: dm-mpath-hp-sw depends on scsi
With CONFIG_SCSI=n __scsi_print_sense() is never linked in. drivers/built-in.o: In function `hp_sw_end_io': dm-mpath-hp-sw.c:(.text+0x914f8): undefined reference to `__scsi_print_sense' Caught with a randconfig on current git. Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> --- drivers/md/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig index 9b6fbf0..3fa7c77 100644 --- a/drivers/md/Kconfig +++ b/drivers/md/Kconfig @@ -269,7 +269,7 @@ config DM_MULTIPATH_RDAC config DM_MULTIPATH_HP tristate "HP MSA multipath support (EXPERIMENTAL)" -depends on DM_MULTIPATH && BLK_DEV_DM && EXPERIMENTAL +depends on DM_MULTIPATH && BLK_DEV_DM && SCSI && EXPERIMENTAL ---help--- Multipath support for HP MSA (Active/Passive) series hardware. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch1/2] fix wrong proc cpuinfo on x64
in 2.6.24-rc1 kernel, The /proc/cpuinfo display is wrong. One issue is every processor id appears to be 0. That is because smp_store_cpu_info will set cpuinfo_x86->cpu_index to cpu id then call identify_cpu identify_cpu will call early_identify_cpu which set c->cpu_index back to 0. This patch set cpu_index after identify_cpu to fix the issue. Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]> --- linux-2.6.24-rc1/arch/x86/kernel/smpboot_64.c 2007-10-29 22:03:05.0 -0400 +++ b/arch/x86/kernel/smpboot_64.c 2007-11-05 22:12:57.0 -0500 @@ -141,8 +141,8 @@ static void __cpuinit smp_store_cpu_info struct cpuinfo_x86 *c = _data(id); *c = boot_cpu_data; - c->cpu_index = id; identify_cpu(c); + c->cpu_index = id; print_cpu_info(c); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with accessing namespace_sem from LSM.
On 11/6/2007 1:11 PM, Arjan van de Ven wrote: On Tue, 06 Nov 2007 13:00:41 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: Hello. I found that accessing namespace_sem from security_inode_create() causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y . sounds like you have an AB-BA deadlock... sed /you/AppArmor shipped with OpenSuSE 10.1 and 10.2/ :) Though I don't think this deadlock should occur quite often, it occurs when it occurs. Care should be taken promptly. There should be no way around for this problem as its nature. Passing vfsmount parameter to VFS helper functions and LSM hooks seems to be a good choice to me. Cheers, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: irq0 stops working
Thomas Gleixner wrote: > On Tue, 9 Oct 2007, Vasily Averin wrote: >> On one of our servers timer interrupts (i.e irq0) are stops working. As >> result >> any kernel timers do not triggers and tasks waiting some signals from timers >> hangs forever. >> >> Also I've found that disable of irqbalance service on the node helps to >> workaround this issue, however of course it fixes nothing. > > Well, it's at least a hint. Can you try the patch below please ? Patch helps, after 1-month-long testing I could not reproduce this issue again, what are we going to do now? Unfortunately my test node is still unstable, now it reproduces sata timeout issue, details are here: http://bugzilla.kernel.org/show_bug.cgi?id=8650 Thank you, Vasily Averin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] kobject and kset core changes and cleanups
On Fri, 2 Nov 2007 16:57:58 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > So, I go on vacation for a week or so and come back to an overflowing > inbox. Instead of trying to wade through all of that, I decide to > finish up the work Kay and I had started on cleaning up the kset core > code. you killed perfmon. perfmon/perfmon_sysfs.c: In function 'pfm_init_sysfs': perfmon/perfmon_sysfs.c:411: error: 'kernel_subsys' undeclared (first use in this function) perfmon/perfmon_sysfs.c:411: error: (Each undeclared identifier is reported only once perfmon/perfmon_sysfs.c:411: error: for each function it appears in.) I'll drop the perfmon tree and shall soldier on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] x86: arch/x86/Kconfig.cpu unification
Adrian Bunk wrote: > On Tue, Nov 06, 2007 at 03:46:30AM +0100, Sam Ravnborg wrote: >> On Mon, Nov 05, 2007 at 07:53:39PM -0500, Brian Gerst wrote: >>> Sam Ravnborg wrote: Move all CPU definitions to Kconfig.cpu >>> This patch causes build failure on x86_64: >>> >>> lib/rwsem.c: In function ‘__init_rwsem’: >>> lib/rwsem.c:24: error: ‘struct rw_semaphore’ has no member named ‘count’ >>> lib/rwsem.c:24: error: ‘RWSEM_UNLOCKED_VALUE’ undeclared (first use in >>> this function) >>> lib/rwsem.c:24: error: (Each undeclared identifier is reported only once >>> lib/rwsem.c:24: error: for each function it appears in.) >>> lib/rwsem.c: In function ‘__rwsem_do_wake’: >>> lib/rwsem.c:64: error: implicit declaration of function >>> ‘rwsem_atomic_update’ >>> lib/rwsem.c:64: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in this >>> function) >>> lib/rwsem.c:66: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in this >>> function) >>> lib/rwsem.c:115: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in >>> this function) >>> lib/rwsem.c:120: error: implicit declaration of function ‘rwsem_atomic_add’ >>> lib/rwsem.c: In function ‘rwsem_down_failed_common’: >>> lib/rwsem.c:169: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in >>> this function) >>> lib/rwsem.c: In function ‘rwsem_down_read_failed’: >>> lib/rwsem.c:197: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in >>> this function) >>> lib/rwsem.c:197: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in >>> this function) >>> lib/rwsem.c: In function ‘rwsem_down_write_failed’: >>> lib/rwsem.c:210: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in >>> this function) >>> >>> git bisect gives: >>> 55432d383871d127685d78f94e0ad60307dcc0e9 is first bad commit >>> commit 55432d383871d127685d78f94e0ad60307dcc0e9 >>> Author: Sam Ravnborg <[EMAIL PROTECTED]> >>> Date: Thu Nov 1 21:54:39 2007 +0100 >>> >>> x86: arch/x86/Kconfig.cpu unification >> Seems that a default value fail to change value when we shift >> from 32 to 64 bit. I have it reproduced here. >> Will look at it tonight. > > The problem is that you source arch/x86/Kconfig.cpu from > arch/x86/Kconfig.x86_64 but didn't give RWSEM_XCHGADD_ALGORITHM > the required dependency on X86_32. > >> Sam > > cu > Adrian > The quick fix is to move the RWSEM_XCHGADD_ALGORITHM and RWSEM_XCHGADD_ALGORITHM defines from Kconfig.cpu to Kconfig.i386. Looking at this closer, the 64-bit code has been using the generic spinlock-based implementation, while the 32-bit code uses an optimized version on all but true 386 cpus. The 64-bit code should be adapted to use the optimized version at some point. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: writeout stalls in current -git
On 11/6/07, David Chinner <[EMAIL PROTECTED]> wrote: > On Mon, Nov 05, 2007 at 07:27:16PM +0100, Torsten Kaiser wrote: > > On 11/5/07, David Chinner <[EMAIL PROTECTED]> wrote: > > > Ok, so it's probably a side effect of the writeback changes. > > > > > > Attached are two patches (two because one was in a separate patchset as > > > a standalone change) that should prevent async writeback from blocking > > > on locked inode cluster buffers. Apply the xfs-factor-inotobp patch first. > > > Can you see if this fixes the problem? > > > > Now testing v2.6.24-rc1-650-gb55d1b1+ the fix for the missapplied > > raid5-patch > > Applying your two patches ontop of that does not fix the stalls. > > So you are having RAID5 problems as well? The first 2.6.24-rc1-git-kernel that I patched with your patches did not boot for me. (Oops send in one of my previous mails) But given that the stacktrace was not xfs related and I had seen this patch on the lkml, I tried to fix this Oops this way. I did not have troubles with the RAID5 otherwise. > I'm struggling to understand what possible changed in XFS or writeback that > would lead to stalls like this, esp. as you appear to be removing files when > the stalls occur. Rather than vmstat, can you use something like iostat to > show how busy your disks are? i.e. are we seeing RMW cycles in the raid5 or > some such issue. Will do this this evening. > OOC, what is the 'xfs_info ' output for your filesystem? meta-data=/dev/mapper/root isize=256agcount=32, agsize=4731132 blks = sectsz=512 attr=1 data = bsize=4096 blocks=151396224, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 > > vmstat 10 output from unmerging (uninstalling) a kernel: > > 1 0 0 3512188332 19264400 18512 368 735 10 3 85 > > 1 > > -> emerge starts to remove the kernel source files > > 3 0 0 3506624332 1928360015 9825 2458 8307 7 12 81 > > 0 > > 0 0 0 3507212332 19283600 0 554 630 1233 0 1 99 > > 0 > > 0 0 0 3507292332 19283600 0 537 580 1328 0 1 99 > > 0 > > 0 0 0 3507168332 19283600 0 633 626 1380 0 1 99 > > 0 > > 0 0 0 3507116332 19283600 0 1510 768 2030 1 2 97 > > 0 > > 0 0 0 3507596332 19283600 0 524 540 1544 0 0 99 > > 0 > > procs ---memory-- ---swap-- -io -system-- > > cpu > > r b swpd free buff cache si sobibo in cs us sy id > > wa > > 0 0 0 3507540332 19283600 0 489 551 1293 0 0 99 > > 0 > > 0 0 0 3507528332 19283600 0 527 510 1432 1 1 99 > > 0 > > 0 0 0 3508052332 19284000 0 2088 910 2964 2 3 95 > > 0 > > 0 0 0 3507888332 19284000 0 442 565 1383 1 1 99 > > 0 > > 0 0 0 3508704332 19284000 0 497 529 1479 0 0 99 > > 0 > > 0 0 0 3508704332 19284000 0 594 595 1458 0 0 99 > > 0 > > 0 0 0 3511492332 19284000 0 2381 1028 2941 2 3 95 > > 0 > > 0 0 0 3510684332 19284000 0 699 600 1390 0 0 99 > > 0 > > 0 0 0 3511636332 19284000 0 741 661 1641 0 0 > > 100 0 > > 0 0 0 3524020332 19284000 0 2452 1080 3910 2 3 95 > > 0 > > 0 0 0 3524040332 19284400 0 530 617 1297 0 0 99 > > 0 > > 0 0 0 3524128332 19284400 0 812 674 1667 0 1 99 > > 0 > > 0 0 0 3527000332 19367200 339 721 754 1681 3 2 93 > > 1 > > -> emerge is finished, no dirty or writeback data in /proc/meminfo > > At this point, can you run a "sync" and see how long that takes to > complete? Already tried that: http://lkml.org/lkml/2007/11/2/178 See the logs from the second unmerge in the second half of the mail. The sync did not stop this writeout, but returned immediately. > The only thing I can think that woul dbe written out after > this point is inodes, but even then it seems to go on for a long, > long time and it really doesn't seem like XFS is holding up the > inode writes. Yes, I completly agree that this is much to long. Thats why I included the after-emerge-finished parts of the logs. But I still partly suspect xfs, because the xfssyncd shows up when I hip SysRq+W. > Another option is to use blktrace/blkparse to determine which process is > issuing this I/O. > > > 0 0 0 3583780332 19506000 0 494 555 1080 0 1 99 > > 0 > > 0 0
Re: [PATCH 1/5] Small ACPICA extension to be able to store the name of operation regions in osl.c later
this patch introduces a compile error: drivers/acpi/osl.c:1203: error: conflicting types for 'acpi_os_validate_address' include/acpi/acpiosxf.h:243: error: previous declaration of 'acpi_os_validate_address' was here which the next patch fixes. This breaks git-bisection and will cause great gnashing of teeth to those who hit it. Also, please fix this: drivers/acpi/osl.c: In function 'acpi_os_validate_address': drivers/acpi/osl.c:1365: warning: format '%llx' expects type 'long long unsigned int', but argument 4 has type 'long unsigned int' drivers/acpi/osl.c:1365: warning: format '%s' expects type 'char *', but argument 5 has type 'long unsigned int' it's all covered in Documentation/SubmitChecklist but it seems that file was write-only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] prepare kprobes code for x86 unification
On Wed, 24 Oct 2007 15:00:47 -0700 Arjan van de Ven <[EMAIL PROTECTED]> wrote: > This patch is a first step towards unification of the kprobes > infrastructure between 32 and 64 bit x86; the patch is mostly > about removing spurious whitespace changes and about adding > harmless includes and the like to make the 32/64 files more > identical. arch/x86/kernel/kprobes_32.c:94: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:95: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:98: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:99: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:102: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:103: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:106: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:107: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:116: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:117: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:120: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:121: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:124: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:125: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:128: warning: left shift count >= width of type arch/x86/kernel/kprobes_32.c:129: warning: left shift count >= width of type just your basic i386 allmodconfig. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MIPS: Delete now-unreferenced i2c-yosemite.h header file.
Given that the corresponding source file i2c-yosemite.c file was
removed in commit daa4a68f901c4d6491baa1a01f5c869a553c3f6c, and that
no one else includes this file, it seems safe to delete it.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/arch/mips/pmc-sierra/yosemite/i2c-yosemite.h
b/arch/mips/pmc-sierra/yosemite/i2c-yosemite.h
deleted file mode 100644
index 31c5523..000
--- a/arch/mips/pmc-sierra/yosemite/i2c-yosemite.h
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * arch/mips/pmc-sierra/yosemite/i2c-yosemite.h
- *
- * Copyright (C) 2003 PMC-Sierra Inc.
- * Author: Manish Lachwani ([EMAIL PROTECTED])
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#ifndef __I2C_YOSEMITE_H
-#define __I2C_YOSEMITE_H
-
-/* Read and Write operations to the chip */
-
-#define TITAN_I2C_BASE 0xbb00 /* XXX Needs to change
*/
-
-#defineTITAN_I2C_WRITE(offset, data) \
- *(volatile unsigned long
*)(TITAN_I2C_BASE + offset) = data
-
-#defineTITAN_I2C_READ(offset) *(volatile unsigned long
*)(TITAN_I2C_BASE + offset)
-
-
-/* Local constansts*/
-#define TITAN_I2C_MAX_FILTER15
-#define TITAN_I2C_MAX_CLK 1023
-#define TITAN_I2C_MAX_ARBF 15
-#define TITAN_I2C_MAX_NAK 15
-#define TITAN_I2C_MAX_MASTERCODE7
-#define TITAN_I2C_MAX_WORDS_PER_RW 4
-#define TITAN_I2C_MAX_POLL 100
-
-/* Registers used for I2C work */
-#define TITAN_I2C_SCMB_CONTROL 0x0180 /* SCMB Control */
-#define TITAN_I2C_SCMB_CLOCK_A 0x0184 /* SCMB Clock A */
-#define TITAN_I2C_SCMB_CLOCK_B 0x0188 /* SCMB Clock B */
-#defineTITAN_I2C_CONFIG0x01A0 /* I2C Config */
-#define TITAN_I2C_COMMAND 0x01A4 /* I2C Command */
-#defineTITAN_I2C_SLAVE_ADDRESS 0x01A8 /* I2C Slave Address */
-#define TITAN_I2C_DATA 0x01AC /* I2C Data [15:0] */
-#define TITAN_I2C_INTERRUPTS 0x01BC /* I2C Interrupts */
-
-/* Error */
-#defineTITAN_I2C_ERR_ARB_LOST (-9220)
-#defineTITAN_I2C_ERR_NO_RESP (-9221)
-#defineTITAN_I2C_ERR_DATA_COLLISION(-9222)
-#defineTITAN_I2C_ERR_TIMEOUT (-9223)
-#defineTITAN_I2C_ERR_OK0
-
-/* I2C Command Type */
-typedef enum {
- TITAN_I2C_CMD_WRITE = 0,
- TITAN_I2C_CMD_READ = 1,
- TITAN_I2C_CMD_READ_WRITE = 2
-} titan_i2c_cmd_type;
-
-/* I2C structures */
-typedef struct {
- int filtera;/* Register 0x0184, bits 15 - 12 */
- int clka; /* Register 0x0184, bits 9 - 0 */
- int filterb;/* Register 0x0188, bits 15 - 12 */
- int clkb; /* Register 0x0188, bits 9 - 0 */
-} titan_i2c_config;
-
-/* I2C command type */
-typedef struct {
- titan_i2c_cmd_type type;/* Type of command */
- int num_arb;/* Register 0x01a0, bits 15 - 12 */
- int num_nak;/* Register 0x01a0, bits 11 - 8 */
- int addr_size; /* Register 0x01a0, bit 7 */
- int mst_code; /* Register 0x01a0, bits 6 - 4 */
- int arb_en; /* Register 0x01a0, bit 1 */
- int speed; /* Register 0x01a0, bit 0 */
- int slave_addr; /* Register 0x01a8 */
- int write_size; /* Register 0x01a4, bits 10 - 8 */
- unsigned int *data; /* Register 0x01ac */
-} titan_i2c_command;
-
-#endif /* __I2C_YOSEMITE_H */
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
Re: [PATCH 3/4] Blackfin SPI driver: move hard coded pin_req to board file
On 11/6/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Thursday 01 November 2007, Bryan Wu wrote:
> > --- a/include/asm-blackfin/bfin5xx_spi.h
> > +++ b/include/asm-blackfin/bfin5xx_spi.h
> > @@ -152,6 +152,7 @@
> > struct bfin5xx_spi_master {
> > u16 num_chipselect;
> > u8 enable_dma;
> > +u16 pin_req[4];
> > };
> >
> > /* spi_board_info.controller_data for SPI slave devices,
>
> I take it there's a patch some where -- outside of this set
> of four -- to initialize that new field so drivers will get
> valid pin setup data? (That name doesn't sound like it's
> platform data, by the way.)
>
> That's going to need to merge in sync with this patch, else
> I'd think the resulting kernel won't run ...
>
Yes, I have another patch to add this pin_req field in arch/blackfin
board files.
It is in my blackfin patch queue and will be submitted to upstream later.
Thanks a lot
-Bryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 - Regularly getting processes stuck in D state on startup
On Mon, 05 Nov 2007 18:23:07 + David <[EMAIL PROTECTED]> wrote: > > I've been testing rc1 for a week or so, and about 25% of the time I'm > seeing Firefox and Thunderbird getting stuck in 'D' state as they startup. > > I've attached the output of Sysrq-T to this mail... system is a > dual-core AMD64, and files are on a RAID-1 root partition connected two > SATA disks on the on-board NVidia controller. I've had no problems > before .24 rc1 I am seeing something very similar on a PowerPC machine where copying a file from an LVM volume with ext3 on it to a simple scsi partition (again ext3) on the same disk will hang in congestion_wait. If I am patient enough, the copy makes very slow progress. A kill -9 will kill it eventually, but a simple control-C will not. This hang occurs more often than not (and usually when I am trying to install a new kernel into /boot for testing :-)). I don't have access to the machine today, but if more information would be useful, I could boot into 2.6.24-rc1- again tomorrow. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpB04JWvI2Bs.pgp Description: PGP signature
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
On Sat, Nov 03, 2007 at 06:43:06PM +0200, Ahmed S. Darwish wrote:
> On Fri, Nov 02, 2007 at 01:50:55PM -0700, Casey Schaufler wrote:
> >
> > Still to come:
> >
> > - Final cleanup of smack_load_write and smack_cipso_write.
>
> Hi All,
>
> After agreeing with Casey on the "load" input grammar yesterday, here's
> the final grammar and its parser (which needs more testing):
>
> A Smack Rule in an "egrep" format is:
>
> "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
>
> where Subject/Object strings are in the form:
>
> "^[^/[:space:][:cntrl:]]{1,SMK_MAXLEN}$"
>...
Can you limit this to 7bit ASCII and use isascii() somewhere?
Otherwise I'd expect funny things to happen when you e.g. use isspace()
on the UTF-8 encoded character à.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Defense in depth: LSM *modules*, not a static interface
Crispin Cowan wrote: Simon Arlott wrote: On Tue, October 30, 2007 07:14, Cliffe wrote: And while I acknowledge that many of these layers are currently buried within the kernel (netfilter...) they are security layers which in many cases would probably make sense as stackable security modules. Making the interface static forces mammoth solutions which then must attempt to solve all of the above in one ls*m*. What happened to dividing tasks into easy to manage chunks? ... Alternatively the M in LSM can be restored and modules can be stacked. It should be possible for the primary LSM to check the security_ops of the secondary LSM(s) and complain if it considers there to be an incompatiblity. That is what I advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FUD threats). Crispin Security can (and should) be implemented in a layered approach. Not allowing stacking means that, rather than creating modules which complement each other, certain layers need to be migrated into the mainline kernel code. This would be ok if every situation had the same security requirements; however, they do not. For example small LSMs that provide hooks for Malware scanners (like dazuko), certain security improvements (such as RaceGuard, PaX ...) and POSIX capabilities could be stacked with other larger lsms (traditional access control, IDS, firewalls) rather than copying these techniques into all the large lsms (such as SELinux and AppArmor) or putting them into the mainline kernel. Obviously it would be easier to maintain one capability lsm which stacks, than capabilities being implemented in every access control lsm. It may be possible to compile stacked LSMs together (I don't know), but modules provide greater flexibility and either way stacking should be pursued. I agree with Crispin, restore modules. Then discussions of suitable ways of providing stacking can occur / continue. Cliffe wrote: Al Viro wrote: On Tue, Oct 30, 2007 at 03:14:33PM +0800, Cliffe wrote: Defense in depth has long been recognised as an important secure design principle. Security is best achieved using a layered approach. "Layered approach" is not a magic incantation to excuse any bit of snake oil. Homeopathic remedies might not harm (pure water is pure water), but that's not an excuse for quackery. And frankly, most of the "security improvement" crowd sound exactly like woo-peddlers. I agree completely; but layers that provide actual security improvements are important. Just to clarify, I was agreeing with Al that layers for the sake of layers does not improve security if the layers are flawed. I was not implying that the specific LSMs that are being proposed currently (AppArmor etc) are flawed. I personally think that AppArmor provides security improvements which are particularly suitable in some situations. However, if you do have defense in depth then a flaw in one layer may be compensated by another layer. For example if you have a system wide firewall that does not allow any incoming traffic to enter a system, and an AppArmor profile denies all network traffic to a specific application, then a flaw in the firewall which would ordinarily result in a compromise of the systems policy would not cause that specific application to be exposed. Granted this may be a poor example, but it does illustrate that layers provide security improvements. Of course this kind of setup does provide management and usability challenges but that is an area for improvement. Anyway I hope that my opinion is helpful, Cliffe. -- Z. Cliffe Schreuders BSc Comp Sci (Hons) & Int Comp PhD Candidate, Casual Tutor School of IT Murdoch University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] kobject and kset core changes and cleanups
On Fri, 2 Nov 2007 16:57:58 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > So, I go on vacation for a week or so and come back to an overflowing > inbox. Instead of trying to wade through all of that, I decide to > finish up the work Kay and I had started on cleaning up the kset core > code. Now I'm rather screwed. I still need to revert gregkh-driver-block-device.patch so that the G5 will boot, but doing that restores the decl_subsys(block, _uevent_ops) in genhd.c, and that no longer compiles. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] slub: fix leakage
On Nov 6, 2007 2:45 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote: > 1. We can avoid going back to the page allocator for awhile since we will > find the almost free slab if the current slab is exhausted. Does this impact SLAB as well? I'm getting out of memory with kernel 2.6.21, 2.6.22 and 2.6.23, so I'm stuck with 2.6.20-15 for systems running Oracle. It only happens with lots of activities. Jeff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] Blackfin SPI driver: move hard coded pin_req to board file
On Thursday 01 November 2007, Bryan Wu wrote:
> --- a/include/asm-blackfin/bfin5xx_spi.h
> +++ b/include/asm-blackfin/bfin5xx_spi.h
> @@ -152,6 +152,7 @@
> struct bfin5xx_spi_master {
> u16 num_chipselect;
> u8 enable_dma;
> + u16 pin_req[4];
> };
>
> /* spi_board_info.controller_data for SPI slave devices,
I take it there's a patch some where -- outside of this set
of four -- to initialize that new field so drivers will get
valid pin setup data? (That name doesn't sound like it's
platform data, by the way.)
That's going to need to merge in sync with this patch, else
I'd think the resulting kernel won't run ...
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]bluetooth rfcomm_dev refcount bug fix
Hi marcel,
I'm afraid to be considered as spam ;)
(Due to timezone offset, I have to mail again and cann't wait for your
reply, sorry for the annoying)
I think the rfcomm_dev_put could be seperated from the rfcomm_dev_put,
it will be more straitforward then.
please consider below patch, tested on my side. thanks.
diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
--- linux/net/bluetooth/rfcomm/tty.c2007-11-05 11:28:49.0 +0800
+++ linux.new/net/bluetooth/rfcomm/tty.c2007-11-06 13:40:44.0
+0800
@@ -109,9 +109,6 @@ static void rfcomm_dev_destruct(struct r
tty_unregister_device(rfcomm_tty_driver, dev->id);
- /* Refcount should only hit zero when called from rfcomm_dev_del()
- which will have taken us off the list. Everything else are
- refcounting bugs. */
BUG_ON(!list_empty(>list));
kfree(dev);
@@ -128,13 +125,6 @@ static inline void rfcomm_dev_hold(struc
static inline void rfcomm_dev_put(struct rfcomm_dev *dev)
{
- /* The reason this isn't actually a race, as you no
- doubt have a little voice screaming at you in your
- head, is that the refcount should never actually
- reach zero unless the device has already been taken
- off the list, in rfcomm_dev_del(). And if that's not
- true, we'll hit the BUG() in rfcomm_dev_destruct()
- anyway. */
if (atomic_dec_and_test(>refcnt))
rfcomm_dev_destruct(dev);
}
@@ -309,12 +299,11 @@ out:
return dev->id;
}
-static void rfcomm_dev_del(struct rfcomm_dev *dev)
+static void rfcomm_dev_set_del(struct rfcomm_dev *dev)
{
BT_DBG("dev %p", dev);
set_bit(RFCOMM_TTY_RELEASED, >flags);
- rfcomm_dev_put(dev);
}
/* Send buffer */
@@ -425,7 +414,7 @@ static int rfcomm_release_dev(void __use
if (dev->tty)
tty_vhangup(dev->tty);
- rfcomm_dev_del(dev);
+ rfcomm_dev_set_del(dev);
rfcomm_dev_put(dev);
return 0;
}
@@ -564,7 +553,8 @@ static void rfcomm_dev_state_change(stru
if (rfcomm_dev_get(dev->id) == NULL)
return;
- rfcomm_dev_del(dev);
+ rfcomm_dev_set_del(dev);
+ rfcomm_dev_put(dev);
/* We have to drop DLC lock here, otherwise
rfcomm_dev_put() will dead lock if it's
the last reference. */
@@ -1022,7 +1012,8 @@ static void rfcomm_tty_hangup(struct tty
if (test_bit(RFCOMM_RELEASE_ONHUP, >flags)) {
if (rfcomm_dev_get(dev->id) == NULL)
return;
- rfcomm_dev_del(dev);
+ rfcomm_dev_set_del(dev);
+ rfcomm_dev_put(dev);
rfcomm_dev_put(dev);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] [BUG] rfcomm]
On 11/6/07, Dave Young <[EMAIL PROTECTED]> wrote: > Hi, > sorry for reply again, this seems a diffrent issue ... All that I do is running pppd over the rfcomm, suspending the system and resume. I don't load any binary module. Alon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a list of non-existent but included include/linux header files
On Mon, Nov 05, 2007 at 11:31:39PM -0500, Robert P. J. Day wrote: > > this list is short enough that i'll just post it here -- attempts to > include header files under include/linux when those header files > simply don't exist. obviously, there might be false positives for one > reason or another. (the only manual culling i did of the list was to > remove inclusions of autoconf.h and utsrelease.h -- i assumed those > weren't an issue for anyone.) >... > === Missing: include/linux/compile.h === > arch/x86/boot/version.c:#include > init/version.c:#include >... That's a generated header. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NFS: Stop sillyname renames and unmounts from racing
On Mon, Nov 05, 2007 at 09:06:36PM -0800, Andrew Morton wrote: > > Any objections to exporting the inode_lock spin lock? > > If so, how should modules _safely_ access the s_inode list? > That's going to make hch unhappy. That's going to make me just as unhappy, especially since it's pointless; instead of the entire sorry mess we should just bump sb->s_active to pin the superblock down (we know that it's active at that point, so it's just an atomic_inc(); no games with locking, etc., are needed) and call deactivate_super() on the way out. And deactivate_super() is exported already. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a list of non-existent but included include/linux header files
On 11/5/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > arch/blackfin/mm/blackfin_sram.c:#include > arch/blackfin/mach-common/interrupt.S:#include i seem to recall these already getting fixed, but just in case, ive queued up patches for these cheers -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NFS: Stop sillyname renames and unmounts from racing
On Sat, 03 Nov 2007 07:09:25 -0400 Steve Dickson <[EMAIL PROTECTED]> wrote:
> The following patch stops NFS sillyname renames and umounts from racing.
(appropriate cc's added)
> I have a test script does the following:
> 1) start nfs server
> 2) mount loopback
> 3) open file in background
> 4) remove file
> 5) stop nfs server
> 6) kill -9 process which has file open
> 7) restart nfs server
> 8) umount looback mount.
>
> After umount I got the "VFS: Busy inodes after unmount" message
> because the processing of the rename has not finished.
>
> Below is a patch that the uses the new silly_count mechanism to
> synchronize sillyname processing and umounts. The patch introduces a
> nfs_put_super() routine that waits until the nfsi->silly_count count
> is zero.
>
> A side-effect of finding and waiting for all the inode to
> find the sillyname processing, is I need to traverse
> the sb->s_inodes list in the supper block. To do that
> safely the inode_lock spin lock has to be held. So for
> modules to be able to "see" that lock I needed to
> EXPORT_SYMBOL_GPL() it.
>
> Any objections to exporting the inode_lock spin lock?
> If so, how should modules _safely_ access the s_inode list?
>
> steved.
>
>
> Author: Steve Dickson <[EMAIL PROTECTED]>
> Date: Wed Oct 31 12:19:26 2007 -0400
>
> Close a unlink/sillyname rename and umount race by added a
> nfs_put_super routine that will run through all the inode
> currently on the super block, waiting for those that are
> in the middle of a sillyname rename or removal.
>
> This patch stop the infamous "VFS: Busy inodes after unmount... "
> warning during umounts.
>
> Signed-off-by: Steve Dickson <[EMAIL PROTECTED]>
>
> diff --git a/fs/inode.c b/fs/inode.c
> index ed35383..da9034a 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -81,6 +81,7 @@ static struct hlist_head *inode_hashtable __read_mostly;
>* the i_state of an inode while it is in use..
>*/
> DEFINE_SPINLOCK(inode_lock);
> +EXPORT_SYMBOL_GPL(inode_lock);
That's going to make hch unhappy.
Your email client is performing space-stuffing.
See http://mbligh.org/linuxdocs/Email/Clients/Thunderbird
> static struct file_system_type nfs_fs_type = {
> .owner = THIS_MODULE,
> @@ -223,6 +225,7 @@ static const struct super_operations nfs_sops = {
> .alloc_inode= nfs_alloc_inode,
> .destroy_inode = nfs_destroy_inode,
> .write_inode= nfs_write_inode,
> + .put_super = nfs_put_super,
> .statfs = nfs_statfs,
> .clear_inode= nfs_clear_inode,
> .umount_begin = nfs_umount_begin,
> @@ -1767,6 +1770,30 @@ static void nfs4_kill_super(struct super_block *sb)
> nfs_free_server(server);
> }
>
> +void nfs_put_super(struct super_block *sb)
This was (correctly) declared to be static. We should define it that way
too (I didn't know you could do this, actually).
> +{
> + struct inode *inode;
> + struct nfs_inode *nfsi;
> + /*
> + * Make sure there are no outstanding renames
> + */
> +relock:
> + spin_lock(_lock);
> + list_for_each_entry(inode, >s_inodes, i_sb_list) {
> + nfsi = NFS_I(inode);
> + if (atomic_read(>silly_count) > 0) {
> + /* Keep this inode around during the wait */
> + atomic_inc(>i_count);
> + spin_unlock(_lock);
> + wait_event(nfsi->waitqueue,
> + atomic_read(>silly_count) == 1);
> + iput(inode);
> + goto relock;
> + }
> + }
> + spin_unlock(_lock);
> +}
That's an O(n^2) search. If it is at all possible to hit a catastrophic
slowdown in here, you can bet that someone out there will indeed hit it in
real life.
I'm too lazy to look, but we might need to check things like I_FREEING
and I_CLEAR before taking a ref on this inode.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git Patch] mm/util.c: Remove needless code
>Thanks. This was already fixed by > >http://www.mail-archive.com/[EMAIL PROTECTED]/msg28294.html > >(which is somewhere in one of my ever-growing number of for-2.6.24 queues) Thanks, Andrew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fixing usb-midi device support
On Mon, 5 Nov 2007, Andrew Morton wrote: > On Thu, 1 Nov 2007 10:20:24 -0700 (PDT) David Griffith <[EMAIL PROTECTED]> > wrote: > > > On Thu, 1 Nov 2007, Vitaliy Ivanov wrote: > > Lots of cc's added. > > > > David, > > > > > > On 10/31/07, David Griffith <[EMAIL PROTECTED]> wrote: > > > > > > > > I have a MOTU Fastlane and an Emu Xmidi 2x2 USB midi interfaces. The > > > > Emu > > > > unit works fine with current kernels. The MOTU unit won't work with > > > > kernels newer than 2.6.17. > > It's a regression. > > The oops is still present. I was hoping that the patch I found and lost > > would help me understand what was going on. > > > > Are you able to send a copy of the oops output? Yes. To refresh everyone, I got this by doing "amidi -d -p virtual" in one xterm. Then I started MIOS Studio (http://www.midibox.org/mios_studio/) and patched the internal in port to all available out ports including the virtual one just created. Remove the MIDI interface, then quit MIOS Studio. An oops will immediately occur. Aug 20 00:28:34 zaphod kernel: [693764.415579] usb 3-1: new full speed USB device using uhci_hcd and address 8 Aug 20 00:28:34 zaphod kernel: [693764.592629] usb 3-1: configuration #1 chosen from 1 choice Aug 20 00:28:34 zaphod kernel: [693764.596652] usb_submit_urb: -22 Aug 20 00:28:34 zaphod kernel: [693764.596664] usb_submit_urb: -22 Aug 20 00:28:34 zaphod kernel: [693764.597322] kobject_add failed for usbdev3.8_ep81 with -EEXIST, don't try to register things with the same name in the same directory. Aug 20 00:28:34 zaphod kernel: [693764.597370] [kobject_add+281/416] kobject_add+0x119/0x1a0 Aug 20 00:28:34 zaphod kernel: [693764.597396] [device_add+183/1328] device_add+0xb7/0x530 Aug 20 00:28:34 zaphod kernel: [693764.597417] [kobject_get+15/32] kobject_get+0xf/0x20 Aug 20 00:28:34 zaphod kernel: [693764.597424] [kobject_init+43/64] kobject_init+0x2b/0x40 Aug 20 00:28:34 zaphod kernel: [693764.597437] [] usb_create_ep_files+0x17a/0x2f0 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597504] [sysfs_create_group+143/176] sysfs_create_group+0x8f/0xb0 Aug 20 00:28:34 zaphod kernel: [693764.597525] [] usb_create_sysfs_intf_files+0x7c/0x110 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597561] [] usb_set_configuration+0x401/0x4d0 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597608] [] generic_probe+0x164/0x230 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597655] [] usb_probe_device+0x33/0x40 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597678] [really_probe+102/400] really_probe+0x66/0x190 Aug 20 00:28:34 zaphod kernel: [693764.597688] [driver_probe_device+73/192] driver_probe_device+0x49/0xc0 Aug 20 00:28:34 zaphod kernel: [693764.597696] [klist_next+83/160] klist_next+0x53/0xa0 Aug 20 00:28:34 zaphod kernel: [693764.597711] [bus_for_each_drv+68/112] bus_for_each_drv+0x44/0x70 Aug 20 00:28:34 zaphod kernel: [693764.597727] [device_attach+144/160] device_attach+0x90/0xa0 Aug 20 00:28:34 zaphod kernel: [693764.597734] [__device_attach+0/16] __device_attach+0x0/0x10 Aug 20 00:28:34 zaphod kernel: [693764.597743] [bus_attach_device+38/96] bus_attach_device+0x26/0x60 Aug 20 00:28:34 zaphod kernel: [693764.597753] [device_add+1109/1328] device_add+0x455/0x530 Aug 20 00:28:34 zaphod kernel: [693764.597778] [] __usb_new_device+0x92/0x120 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597813] [] hub_thread+0x78e/0xc20 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597864] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 Aug 20 00:28:34 zaphod kernel: [693764.597886] [] hub_thread+0x0/0xc20 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.597909] [kthread+186/240] kthread+0xba/0xf0 Aug 20 00:28:34 zaphod kernel: [693764.597918] [kthread+0/240] kthread+0x0/0xf0 Aug 20 00:28:34 zaphod kernel: [693764.597927] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 Aug 20 00:28:34 zaphod kernel: [693764.597943] === Aug 20 00:28:34 zaphod kernel: [693764.597956] kobject_add failed for usbdev3.8_ep02 with -EEXIST, don't try to register things with the same name in the same directory. Aug 20 00:28:34 zaphod kernel: [693764.597964] [kobject_add+281/416] kobject_add+0x119/0x1a0 Aug 20 00:28:34 zaphod kernel: [693764.597980] [device_add+183/1328] device_add+0xb7/0x530 Aug 20 00:28:34 zaphod kernel: [693764.597994] [kobject_get+15/32] kobject_get+0xf/0x20 Aug 20 00:28:34 zaphod kernel: [693764.598001] [kobject_init+43/64] kobject_init+0x2b/0x40 Aug 20 00:28:34 zaphod kernel: [693764.598013] [] usb_create_ep_files+0x17a/0x2f0 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.598050] [sysfs_create_group+143/176] sysfs_create_group+0x8f/0xb0 Aug 20 00:28:34 zaphod kernel: [693764.598065] [] usb_create_sysfs_intf_files+0x7c/0x110 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.598100] [] usb_set_configuration+0x401/0x4d0 [usbcore] Aug 20 00:28:34 zaphod kernel: [693764.598146] []
Re: a list of non-existent but included include/linux header files
On Mon, 5 Nov 2007, Mike Frysinger wrote: > > (the only manual culling i did of the list was to remove > > inclusions of autoconf.h and utsrelease.h -- i assumed those > > weren't an issue for anyone.) > > should do the opposite ... nobody should be including > linux/autoconf.h ah, good point: $ grep -r "" * arch/blackfin/mm/blackfin_sram.c:#include arch/blackfin/mach-common/interrupt.S:#include arch/mips/au1000/common/gpio.c:#include arch/m68knommu/lib/memcpy.c:#include drivers/char/mxser_new.c:#include drivers/char/mxser.c:#include drivers/ide/pci/delkin_cb.c:#include drivers/firmware/dmi-id.c:#include drivers/spi/spi.c:#include drivers/misc/fujitsu-laptop.c:#include drivers/misc/asus-laptop.c:#include drivers/misc/msi-laptop.c:#include rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
non-existent CONFIG variables referenced from Makefiles
as opposed to the much larger list of non-existent config variables being tested from source or header files, here's a much shorter list of such variables being referenced from within Makefiles (i removed all entries related to the sound/oss directory since that whole thing is going away, anyway, right?): = CPU_ARM946T = ./arch/arm/Makefile:tune-$(CONFIG_CPU_ARM946T) :=$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi) = CPU_R4000 = ./arch/mips/kernel/Makefile:obj-$(CONFIG_CPU_R4000) += r4k_fpu.o r4k_switch.o = ETRAXFS_SIM = ./arch/cris/arch-v32/kernel/Makefile:obj-$(CONFIG_ETRAXFS_SIM) += vcs_hook.o = HARDWARE_PM = ./arch/blackfin/oprofile/Makefile:oprofile-$(CONFIG_HARDWARE_PM) += op_model_bf533.o = L7200_KEYB = ./drivers/acorn/char/Makefile:obj-$(CONFIG_L7200_KEYB) += defkeymap-l7200.o keyb_l7200.o = MACHINE = ./arch/ppc/boot/simple/Makefile:# zimage-$(CONFIG_MACHINE) and zimagerd-$(CONFIG_MACHINE) to the target ./arch/ppc/boot/simple/Makefile:# that produces the desired image and they must set end-$(CONFIG_MACHINE) ./arch/ppc/boot/simple/Makefile:# than 'zImage.elf', set end-$(CONFIG_MACHINE) to be the suffix used for ./arch/ppc/boot/simple/Makefile:# set entrypoint-$(CONFIG_MACHINE) to the location which the image should be ./arch/ppc/boot/simple/Makefile:# loaded at. The optimal setting for entrypoint-$(CONFIG_MACHINE) is the link ./arch/ppc/boot/simple/Makefile:# misc-$(CONFIG_MACHINE) variable. = MSPETH = ./arch/mips/pmc-sierra/msp71xx/Makefile:obj-$(CONFIG_MSPETH) += msp_eth.o = OPROFILE_ARM11_CORE = ./arch/arm/oprofile/Makefile:oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o = OPROFILE_ARMV6 = ./arch/arm/oprofile/Makefile:oprofile-$(CONFIG_OPROFILE_ARMV6) += op_model_v6.o = OPROFILE_CELL = ./arch/powerpc/oprofile/Makefile:oprofile-$(CONFIG_OPROFILE_CELL) += op_model_cell.o \ = OPROFILE_MPCORE = ./arch/arm/oprofile/Makefile:oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o = PCI_HOST_ITE8152 = ./arch/arm/common/Makefile:obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o = RADIO_MIROPCM20 = ./drivers/media/radio/Makefile:obj-$(CONFIG_RADIO_MIROPCM20) += miropcm20.o = RADIO_MIROPCM20_RDS = ./drivers/media/radio/Makefile:obj-$(CONFIG_RADIO_MIROPCM20_RDS) += miropcm20-rds.o = SA1100_USB = ./arch/arm/mach-sa1100/Makefile:#obj-$(CONFIG_SA1100_USB) += usb/ = SOUND_TVMIXER = ./drivers/media/video/Makefile:obj-$(CONFIG_SOUND_TVMIXER) += tvmixer.o = TTY_LOG = ./arch/um/os-Linux/Makefile:obj-$(CONFIG_TTY_LOG) += tty_log.o ./arch/um/os-Linux/Makefile:user-objs-$(CONFIG_TTY_LOG) += tty_log.o = USB_MSP71XX = ./arch/mips/pmc-sierra/msp71xx/Makefile:obj-$(CONFIG_USB_MSP71XX) += msp_usb.o = XTENSA_VARIANT_LINUX_CUSTOM = ./arch/xtensa/Makefile:variant-$(CONFIG_XTENSA_VARIANT_LINUX_CUSTOM):= custom -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a list of non-existent but included include/linux header files
On 11/5/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > this list is short enough that i'll just post it here -- attempts to > include header files under include/linux when those header files > simply don't exist. obviously, there might be false positives for one > reason or another. obviously the kgdb ones can be ignored > (the only manual culling i did of the list was to > remove inclusions of autoconf.h and utsrelease.h -- i assumed those > weren't an issue for anyone.) should do the opposite ... nobody should be including linux/autoconf.h as for the Blackfin ones, the answer is the same last time you ask ... the includes are for drivers we havent pushed to mainline yet -mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git Patch] mm/util.c: Remove needless code
On Tue, 6 Nov 2007 11:12:07 +0800 WANG Cong <[EMAIL PROTECTED]> wrote:
>
> If the code can be executed there, 'new_size' is always larger
> than 'ks'. Thus min() is needless.
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
> Signed-off-by: Dong Pu <[EMAIL PROTECTED]>
> Cc: Christoph Lameter <[EMAIL PROTECTED]>
>
> ---
> mm/util.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/util.c b/mm/util.c
> index 5f64026..295c7aa 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -96,7 +96,7 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags)
>
> ret = kmalloc_track_caller(new_size, flags);
> if (ret) {
> - memcpy(ret, p, min(new_size, ks));
> + memcpy(ret, p, ks);
> kfree(p);
> }
> return ret;
Thanks. This was already fixed by
http://www.mail-archive.com/[EMAIL PROTECTED]/msg28294.html
(which is somewhere in one of my ever-growing number of for-2.6.24 queues)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
a list of non-existent but included include/linux header files
this list is short enough that i'll just post it here -- attempts to include header files under include/linux when those header files simply don't exist. obviously, there might be false positives for one reason or another. (the only manual culling i did of the list was to remove inclusions of autoconf.h and utsrelease.h -- i assumed those weren't an issue for anyone.) === Missing: include/linux/blk.h === arch/frv/kernel/setup.c:#include === Missing: include/linux/cachefs.h === fs/afs/cache.h:#include === Missing: include/linux/compile.h === arch/x86/boot/version.c:#include init/version.c:#include === Missing: include/linux/debugger.h === arch/blackfin/kernel/kgdb.c:#include === Missing: include/linux/ioctl32.h === drivers/video/sis/sis.h:#include === Missing: include/linux/kdb.h === drivers/acpi/osl.c:#include === Missing: include/linux/kgdb.h === arch/blackfin/kernel/kgdb.c:#include arch/blackfin/mach-common/ints-priority-dc.c:#include arch/blackfin/mach-common/ints-priority-sc.c:#include drivers/serial/bfin_5xx.c:#include === Missing: include/linux/l3/l3.h === sound/arm/sa11xx-uda1341.c:#include sound/i2c/l3/uda1341.c:#include === Missing: include/linux/mtd/mtdram.h === arch/cris/arch-v32/drivers/axisflashmap.c:#include arch/cris/arch-v10/drivers/axisflashmap.c:#include === Missing: include/linux/pkthook.h === arch/ppc/8xx_io/fec.c:#include === Missing: include/linux/segment.h === arch/sparc/kernel/sys_sunos.c:#include === Missing: include/linux/serial_ip3106.h === arch/mips/philips/pnx8550/common/gdb_hook.c:#include === Missing: include/linux/spi/tsc2102.h === arch/arm/mach-omap1/board-palmte.c:#include === Missing: include/linux/squashfs_fs.h === arch/mips/pmc-sierra/msp71xx/msp_prom.c:#include === Missing: include/linux/tqueue.h === drivers/pcmcia/au1000_xxs1500.c:#include drivers/pcmcia/au1000_pb1x00.c:#include === Missing: include/linux/usb_gadget.h === drivers/i2c/chips/isp1301_omap.c:#include === Missing: include/linux/usb_isp1362.h === arch/blackfin/mach-bf533/boards/ezkit.c:#include arch/blackfin/mach-bf533/boards/stamp.c:#include arch/blackfin/mach-bf533/boards/cm_bf533.c:#include arch/blackfin/mach-bf533/boards/H8606.c:#include arch/blackfin/mach-bf537/boards/pnav10.c:#include arch/blackfin/mach-bf537/boards/generic_board.c:#include arch/blackfin/mach-bf537/boards/cm_bf537.c:#include arch/blackfin/mach-bf537/boards/stamp.c:#include arch/blackfin/mach-bf527/boards/ezkit.c:#include arch/blackfin/mach-bf561/boards/cm_bf561.c:#include === Missing: include/linux/usb/musb.h === arch/blackfin/mach-bf548/boards/ezkit.c:#include arch/arm/mach-omap2/usb-tusb6010.c:#include === Missing: include/linux/usb_sl811.h === arch/blackfin/mach-bf527/boards/ezkit.c:#include -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: writeout stalls in current -git
On Mon, Nov 05, 2007 at 07:27:16PM +0100, Torsten Kaiser wrote: > On 11/5/07, David Chinner <[EMAIL PROTECTED]> wrote: > > Ok, so it's probably a side effect of the writeback changes. > > > > Attached are two patches (two because one was in a separate patchset as > > a standalone change) that should prevent async writeback from blocking > > on locked inode cluster buffers. Apply the xfs-factor-inotobp patch first. > > Can you see if this fixes the problem? > > Now testing v2.6.24-rc1-650-gb55d1b1+ the fix for the missapplied raid5-patch > Applying your two patches ontop of that does not fix the stalls. So you are having RAID5 problems as well? I'm struggling to understand what possible changed in XFS or writeback that would lead to stalls like this, esp. as you appear to be removing files when the stalls occur. Rather than vmstat, can you use something like iostat to show how busy your disks are? i.e. are we seeing RMW cycles in the raid5 or some such issue. OOC, what is the 'xfs_info ' output for your filesystem? > vmstat 10 output from unmerging (uninstalling) a kernel: > 1 0 0 3512188332 19264400 18512 368 735 10 3 85 1 > -> emerge starts to remove the kernel source files > 3 0 0 3506624332 1928360015 9825 2458 8307 7 12 81 0 > 0 0 0 3507212332 19283600 0 554 630 1233 0 1 99 0 > 0 0 0 3507292332 19283600 0 537 580 1328 0 1 99 0 > 0 0 0 3507168332 19283600 0 633 626 1380 0 1 99 0 > 0 0 0 3507116332 19283600 0 1510 768 2030 1 2 97 0 > 0 0 0 3507596332 19283600 0 524 540 1544 0 0 99 0 > procs ---memory-- ---swap-- -io -system-- cpu > r b swpd free buff cache si sobibo in cs us sy id wa > 0 0 0 3507540332 19283600 0 489 551 1293 0 0 99 0 > 0 0 0 3507528332 19283600 0 527 510 1432 1 1 99 0 > 0 0 0 3508052332 19284000 0 2088 910 2964 2 3 95 0 > 0 0 0 3507888332 19284000 0 442 565 1383 1 1 99 0 > 0 0 0 3508704332 19284000 0 497 529 1479 0 0 99 0 > 0 0 0 3508704332 19284000 0 594 595 1458 0 0 99 0 > 0 0 0 3511492332 19284000 0 2381 1028 2941 2 3 95 0 > 0 0 0 3510684332 19284000 0 699 600 1390 0 0 99 0 > 0 0 0 3511636332 19284000 0 741 661 1641 0 0 100 > 0 > 0 0 0 3524020332 19284000 0 2452 1080 3910 2 3 95 0 > 0 0 0 3524040332 19284400 0 530 617 1297 0 0 99 0 > 0 0 0 3524128332 19284400 0 812 674 1667 0 1 99 0 > 0 0 0 3527000332 19367200 339 721 754 1681 3 2 93 1 > -> emerge is finished, no dirty or writeback data in /proc/meminfo At this point, can you run a "sync" and see how long that takes to complete? The only thing I can think that woul dbe written out after this point is inodes, but even then it seems to go on for a long, long time and it really doesn't seem like XFS is holding up the inode writes. Another option is to use blktrace/blkparse to determine which process is issuing this I/O. > 0 0 0 3583780332 19506000 0 494 555 1080 0 1 99 0 > 0 0 0 3584352332 19506000 099 347 559 0 0 99 0 > 0 0 0 3585232332 19506000 011 301 621 0 0 99 0 > -> disks go idle. > > So these patches do not seem to be the source of these excessive disk > writes... Well, the patches I posted should prevent blocking in the places that it was seen, so if that does not stop the slowdowns then either the writeback code is not feeding us inodes fast enough or the block device below is having some kind of problem Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with accessing namespace_sem from LSM.
On Tue, 06 Nov 2007 13:00:41 +0900 Tetsuo Handa <[EMAIL PROTECTED]> wrote: > Hello. > > I found that accessing namespace_sem from security_inode_create() > causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y . > > sounds like you have an AB-BA deadlock... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git Patch] mm/util.c: Remove needless code
On Tue, 6 Nov 2007, WANG Cong wrote: > If the code can be executed there, 'new_size' is always larger > than 'ks'. Thus min() is needless. Correct. Acked-by: Christoph Lameter <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with accessing namespace_sem from LSM.
Hello.
I found that accessing namespace_sem from security_inode_create()
causes lockdep warning when compiled with CONFIG_PROVE_LOCKING=y .
===
[ INFO: possible circular locking dependency detected ]
---
klogd/1798 is trying to acquire lock:
(_sem){}, at: [] _aa_perm_dentry+0x80/0x184 [apparmor]
but task is already holding lock:
(>i_mutex){--..}, at: [] mutex_lock+0x12/0x15
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (>i_mutex){--..}:
[] lock_acquire+0x4b/0x6a
[] __mutex_lock_slowpath+0xb0/0x1f6
[] mutex_lock+0x12/0x15
[] graft_tree+0x5c/0xd4
[] do_add_mount+0x84/0x100
[] do_mount+0x602/0x659
[] sys_mount+0x64/0x9b
[] sysenter_past_esp+0x56/0x99
-> #0 (_sem){}:
[] lock_acquire+0x4b/0x6a
[] down_read+0x1e/0x31
[] _aa_perm_dentry+0x80/0x184 [apparmor]
[] aa_perm_dentry+0x62/0xa4 [apparmor]
[] apparmor_inode_create+0x40/0x63 [apparmor]
[] vfs_create+0x84/0x13e
[] open_namei+0x169/0x635
[] do_filp_open+0x20/0x36
[] do_sys_open+0x40/0xbb
[] sys_open+0x16/0x18
[] sysenter_past_esp+0x56/0x99
other info that might help us debug this:
1 lock held by klogd/1798:
#0: (>i_mutex){--..}, at: [] mutex_lock+0x12/0x15
stack backtrace:
[] show_trace+0xd/0x10
[] dump_stack+0x19/0x1b
[] print_circular_bug_tail+0x59/0x64
[] __lock_acquire+0x7ea/0x973
[] lock_acquire+0x4b/0x6a
[] down_read+0x1e/0x31
[] _aa_perm_dentry+0x80/0x184 [apparmor]
[] aa_perm_dentry+0x62/0xa4 [apparmor]
[] apparmor_inode_create+0x40/0x63 [apparmor]
[] vfs_create+0x84/0x13e
[] open_namei+0x169/0x635
[] do_filp_open+0x20/0x36
[] do_sys_open+0x40/0xbb
[] sys_open+0x16/0x18
[] sysenter_past_esp+0x56/0x99
If this warning is true,
AppArmor shipped with OpenSuSE 10.1 and 10.2 is affected.
- Kernel 2.6.16.53-0.16 for OpenSuSE 10.1 -
do_add_mount() { /* in fs/namespace.c */
down_write(_sem);
graft_tree() {
mutex_lock(>dentry->d_inode->i_mutex);
...
mutex_unlock(>dentry->d_inode->i_mutex);
}
up_write(_sem);
}
open_namei() { /* in fs/namei.c */
mutex_lock(>d_inode->i_mutex);
vfs_create() {
security_inode_create() {
subdomain_inode_create() { /* in security/apparmor/lsm.c */
sd_perm_dentry() { /* in security/apparmor/main.c */
_sd_perm_dentry() {
sd_path_begin() { /* in security/apparmor/inline.h */
sd_path_begin2() {
down_read(_sem);
}
}
...
sd_path_end() {
up_read(_sem);
}
}
}
}
}
}
mutex_unlock(>d_inode->i_mutex);
}
- Kernel 2.6.18.8-0.7 for OpenSuSE 10.2 -
do_add_mount() { /* in fs/namespace.c */
down_write(_sem);
graft_tree() {
mutex_lock(>dentry->d_inode->i_mutex);
...
mutex_unlock(>dentry->d_inode->i_mutex);
}
up_write(_sem);
}
open_namei() { /* in fs/namei.c */
mutex_lock(>d_inode->i_mutex);
vfs_create() {
security_inode_create() {
apparmor_inode_create() { /* in security/apparmor/lsm.c */
aa_perm_dentry() { /* in security/apparmor/lsm.c */
_aa_perm_dentry() {
aa_path_begin() { /* in security/apparmor/inline.h */
aa_path_begin2() {
down_read(_sem);
}
}
...
aa_path_end() {
up_read(_sem);
}
}
}
}
}
}
mutex_unlock(>d_inode->i_mutex);
}
AppArmor shipped with OpenSuSE 10.3 and Ubuntu 7.10 will not be affected
since kernel was modified to pass vfsmount parameter
to VFS helper functions and LSM hooks.
TOMOYO Linux 2.x (which is implemented using LSM) is also affected
and I'm looking for solution.
http://lkml.org/lkml/2007/11/5/55
Possible solution would be to pass vfsmount parameter
to VFS helper functions and LSM hooks for all kernels.
I do hope that "Pass struct vfsmount to ..." patches
are merged into mainline kernel.
Regards.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the value in exporting unused header files?
as part of the output of yet another cleanup script i have, we notice that: $ grep -r if_wanpipe * Documentation/networking/wan-router.txt:if_wanpipe.hWANPIPE Socket definitions include/linux/Kbuild:unifdef-y += if_wanpipe.h include/linux/if_wanpipe.h:* if_wanpipe.h Header file for the Sangoma AF_WANPIPE Socket $ in other words, a header file that is not included by any other file in the tree is still being exported to user space. is that normal? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove unused header file linux/fd1772.h.
Given that no one seems to be including this header file, remove it. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- diff --git a/include/linux/fd1772.h b/include/linux/fd1772.h deleted file mode 100644 index 871d6e4..000 --- a/include/linux/fd1772.h +++ /dev/null @@ -1,80 +0,0 @@ -#ifndef _LINUX_FD1772REG_H -#define _LINUX_FD1772REG_H - -/* -** WD1772 stuff - originally from the M68K Linux - * Modified for Archimedes by Dave Gilbert ([EMAIL PROTECTED]) - */ - -/* register codes */ - -#define FDC1772SELREG_STP (0x80) /* command/status register */ -#define FDC1772SELREG_TRA (0x82) /* track register */ -#define FDC1772SELREG_SEC (0x84) /* sector register */ -#define FDC1772SELREG_DTA (0x86) /* data register */ - -/* register names for FDC1772_READ/WRITE macros */ - -#define FDC1772REG_CMD 0 -#define FDC1772REG_STATUS 0 -#define FDC1772REG_TRACK 2 -#define FDC1772REG_SECTOR 4 -#define FDC1772REG_DATA6 - -/* command opcodes */ - -#define FDC1772CMD_RESTORE (0x00) /* - */ -#define FDC1772CMD_SEEK (0x10) /* | */ -#define FDC1772CMD_STEP (0x20) /* | TYP 1 Commands */ -#define FDC1772CMD_STIN (0x40) /* | */ -#define FDC1772CMD_STOT (0x60) /* - */ -#define FDC1772CMD_RDSEC(0x80) /* - TYP 2 Commands */ -#define FDC1772CMD_WRSEC(0xa0) /* - "*/ -#define FDC1772CMD_RDADR(0xc0) /* - */ -#define FDC1772CMD_RDTRA(0xe0) /* | TYP 3 Commands */ -#define FDC1772CMD_WRTRA(0xf0) /* - */ -#define FDC1772CMD_FORCI(0xd0) /* - TYP 4 Command */ - -/* command modifier bits */ - -#define FDC1772CMDADD_SR6 (0x00) /* step rate settings */ -#define FDC1772CMDADD_SR12 (0x01) -#define FDC1772CMDADD_SR2 (0x02) -#define FDC1772CMDADD_SR3 (0x03) -#define FDC1772CMDADD_V (0x04) /* verify */ -#define FDC1772CMDADD_H (0x08) /* wait for spin-up */ -#define FDC1772CMDADD_U (0x10) /* update track register */ -#define FDC1772CMDADD_M (0x10) /* multiple sector access */ -#define FDC1772CMDADD_E (0x04) /* head settling flag */ -#define FDC1772CMDADD_P (0x02) /* precompensation */ -#define FDC1772CMDADD_A0(0x01) /* DAM flag */ - -/* status register bits */ - -#defineFDC1772STAT_MOTORON (0x80) /* motor on */ -#defineFDC1772STAT_WPROT (0x40) /* write protected (FDC1772CMD_WR*) */ -#defineFDC1772STAT_SPINUP (0x20) /* motor speed stable (Type I) */ -#defineFDC1772STAT_DELDAM (0x20) /* sector has deleted DAM (Type II+III) */ -#defineFDC1772STAT_RECNF (0x10) /* record not found */ -#defineFDC1772STAT_CRC (0x08) /* CRC error */ -#defineFDC1772STAT_TR00(0x04) /* Track 00 flag (Type I) */ -#defineFDC1772STAT_LOST(0x04) /* Lost Data (Type II+III) */ -#defineFDC1772STAT_IDX (0x02) /* Index status (Type I) */ -#defineFDC1772STAT_DRQ (0x02) /* DRQ status (Type II+III) */ -#defineFDC1772STAT_BUSY(0x01) /* FDC1772 is busy */ - - -/* PSG Port A Bit Nr 0 .. Side Sel .. 0 -> Side 1 1 -> Side 2 */ -#define DSKSIDE (0x01) - -#define DSKDRVNONE (0x06) -#define DSKDRV0 (0x02) -#define DSKDRV1 (0x04) - -/* step rates */ -#defineFDC1772STEP_6 0x00 -#defineFDC1772STEP_12 0x01 -#defineFDC1772STEP_2 0x02 -#defineFDC1772STEP_3 0x03 - -#endif -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Defense in depth: LSM *modules*, not a static interface
Simon Arlott wrote: > On Tue, October 30, 2007 07:14, Cliffe wrote: > >> And while I acknowledge that many of these layers are currently buried >> within the kernel (netfilter...) they are security layers which in many >> cases would probably make sense as stackable security modules. >> >> Making the interface static forces mammoth solutions which then must >> attempt to solve all of the above in one ls*m*. What happened to >> dividing tasks into easy to manage chunks? >> > Would it be possible to have Kconfig select which LSM should handle each > area of security? Selecting LSM A would automatically disable LSM B and > C since they both implement the same security functions, while LSM D > would still be selectable since it implements something else. The default > capabilities code would then turn off parts of itself that another LSM > is handling. > I get what you mean, but the problem is that there is little consensus on what "area" means. Rather the opposite, it could easily be the case that different modules have such a different view of the world that you cannot easily mechanically determine whether they can stack. Some categories that occur to me: * Restrictive vs. Permissive: o LSM is mostly restrictive, but the POSIX.1e Capabilities hooks are permissive. o Some modules like MultiADM and File Capabilities are deliberately permissive, while others like AppArmor and SMACK are purely restrictive. o In any kind of stacking scheme, it would be important to load the permissive modules first, followed by the restrictive modules. o This becomes problematic as soon as you have a module that is both permissive and restrictive. o Note: AppArmor is both permissive and restrictive because it incorporates the Capabilities code rather than trying to stack with it. With a good clean stacker, AA might be able to become purely restrictive. * Access control vs. Intrusion prevention: o An Access control policy is one that specifies what a confined subject can access. o An Intrusion prevention engine specifies classes of things that may never happen, e.g. the Openwall hard and symbolic link restrictions. o An intrusion prevention mechanism might be a blanket effect that prevents the Bad Thing from happening for all processes, or it might be policy driven, and only prevent the Bad Thing for explicitly confined processes, or explicitly allow the Bad Thing for permitted processes. o Access control and Intrusion Prevention modules are naturally complementary, making stacking very attractive. o Note: SELinux already incorporates some intrusion prevention features, and AppArmor plans to incorporate such features. With a good clean stacker, AA might be able to instead use stacking. > Alternatively the M in LSM can be restored and modules can be stacked. > It should be possible for the primary LSM to check the security_ops of the > secondary LSM(s) and complain if it considers there to be an incompatiblity. > That is what I advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FUD threats). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID namespaces break initrd+hibernate combination?
Nigel Cunningham wrote: Hi all. Please excuse me if this has already been answered. I'm not currently subscribed to LKML. I've just been preparing a new tux-on-ice release against Linus' current tree, and encountered a failure to freeze pid 1 when seeking to resume, using an initrd: [ 74.192734] Freezing of tasks failed after 19.99 seconds (1 tasks refusing to freeze): [ 74.193502] taskPC stack pid father [ 74.193504] swapper S 810002023030 4968 1 0 [ 74.193512] 81000203fdb0 0046 810002023040 810003249140 [ 74.194296] 81000203fd80 803150a1 81000203fdb0 810002023180 [ 74.195087] 810002023030 0004 0001 0001 [ 74.195860] Call Trace: [ 74.196123] [] security_task_wait+0x11/0x20 [ 74.196692] [] do_wait+0x51d/0xda0 [ 74.197187] [] default_wake_function+0x0/0x10 [ 74.197772] [] sys_wait4+0x2c/0x30 [ 74.198264] [] initrd_load+0x175/0x370 [ 74.198794] [] prepare_namespace+0x8f/0x1d0 [ 74.199362] [] kernel_init+0x1ad/0x2b0 [ 74.199889] [] _spin_unlock_irq+0x26/0x60 [ 74.200439] [] finish_task_switch+0x67/0xc0 [ 74.201008] [] child_rip+0xa/0x12 [ 74.201494] [] acpi_os_acquire_lock+0x9/0xb [ 74.202063] [] kernel_init+0x0/0x2b0 [ 74.202570] [] child_rip+0x0/0x12 I believe it might be related to pid namespaces, but am not completely sure yet (will do a git bisect if needs be). Hmm. prepare_namespace() seems more about mounting root filesystem and less about pid namespace. but I could be wrong. Do you have any more console messages ? CCing the containers list So, then, I'm writing to ask: Is this a known issue? Is there any fix already available that I've not found in my googling? Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fixing usb-midi device support
On Thu, 1 Nov 2007 10:20:24 -0700 (PDT) David Griffith <[EMAIL PROTECTED]> wrote: > On Thu, 1 Nov 2007, Vitaliy Ivanov wrote: Lots of cc's added. > > David, > > > > On 10/31/07, David Griffith <[EMAIL PROTECTED]> wrote: > > > > > > I have a MOTU Fastlane and an Emu Xmidi 2x2 USB midi interfaces. The Emu > > > unit works fine with current kernels. The MOTU unit won't work with > > > kernels newer than 2.6.17. It's a regression. > I stumbled over a patch that had something to > > > do with a MOTU Fastlane, but I haven't been able to find it again. Could > > > I get some advice on fixing MOTU Fastlane support? > > > > I can see that you already had a discussion on this issue: > > http://lkml.org/lkml/2007/8/10/102 > > > > Any results? Do you still can see the oops? > > The oops is still present. I was hoping that the patch I found and lost > would help me understand what was going on. > Are you able to send a copy of the oops output? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: no more free evdev devices - evdev leak?
On Wed, 31 Oct 2007 16:34:44 + Soeren Sonnenburg <[EMAIL PROTECTED]> wrote: > Dear all, (cc's added) > whenever I do a suspend resume cycle the input device's numbers are > increased until I finally run out of evdev devices. Is this a kernel > problem or some userspace program (udev/...) creating new devices all > the time? > > here is the dmesg: > > Soeren > > input: Power Button (FF) as /devices/virtual/input/input0 > input: Lid Switch as /devices/virtual/input/input1 > input: Power Button (CM) as /devices/virtual/input/input2 > input: Sleep Button (CM) as /devices/virtual/input/input3 > input: Macintosh mouse button emulation as /devices/virtual/input/input4 > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/input/input5 > input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.2/input/input6 > input: USB HID v1.11 Device [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/input/input7 > input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-:00:1d.3-1 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.1/input/input8 > input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-:00:1d.3-1 > input: appletouch as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.1/input/input9 > input: Video Bus as /devices/virtual/input/input10 > input: applesmc as /devices/platform/applesmc.768/input/input11 > input: appletouch disconnected > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/input/input12 > input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: appletouch as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.1/input/input13 > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.2/input/input14 > input: USB HID v1.11 Device [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/input/input15 > input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-:00:1d.3-1 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.1/input/input16 > input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-:00:1d.3-1 > input: appletouch disconnected > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/input/input17 > input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: appletouch as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.1/input/input18 > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.2/input/input19 > input: USB HID v1.11 Device [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/input/input20 > input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-:00:1d.3-1 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.1/input/input21 > input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-:00:1d.3-1 > input: appletouch disconnected > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/input/input22 > input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: appletouch as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.1/input/input23 > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.2/input/input24 > input: USB HID v1.11 Device [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.0/input/input25 > input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-:00:1d.3-1 > input: HID 05ac:1000 as > /devices/pci:00/:00:1d.3/usb5/5-1/5-1:1.1/input/input26 > input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-:00:1d.3-1 > input: appletouch disconnected > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/input/input27 > input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / > Trackpad] on usb-:00:1d.0-2 > input: appletouch as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.1/input/input28 > input: Apple Computer Apple Internal Keyboard / Trackpad as > /devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.2/input/input29 > input: USB HID v1.11 Device [Apple Computer Apple Internal
[git Patch] mm/util.c: Remove needless code
If the code can be executed there, 'new_size' is always larger
than 'ks'. Thus min() is needless.
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Signed-off-by: Dong Pu <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/util.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/util.c b/mm/util.c
index 5f64026..295c7aa 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -96,7 +96,7 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags)
ret = kmalloc_track_caller(new_size, flags);
if (ret) {
- memcpy(ret, p, min(new_size, ks));
+ memcpy(ret, p, ks);
kfree(p);
}
return ret;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]bluetooth rfcomm_dev refcount bug fix
On 11/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later. > > > > If rfcomm_dev is destructed in tty_hangup function, then the later > > tty_close function will oops. > > your patch removes the complete release on hangup logic. That can't be > right. I think the problem is with calling tty_vhangup() and then > decrementing the reference count. In case we call tty_vhangup and we > have release on hangup we should not delete the device here. What about > the attached patch? Does it solve it? > How about this patch (attached), it works for me as well. Regards dave diff.rfcomm.1 Description: Binary data
RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it
The Xframe (S2io) adapter can be programmed dynamically to either,
always strip the vlan tag or not. In this case, if the vlan group is
NULL, it can be programmed at run time to NOT strip the vlan tag.
When a packet with a Vlan id is received that is not added to the group,
should it be dropped or indicated up? Either can be handled by the
hardware. The vlan tag in this particular case will be stripped as the
vlan group is not NULL.
Ram
> -Original Message-
> From: Dave Johnson
[mailto:[EMAIL PROTECTED]
> Sent: Monday, November 05, 2007 9:47 AM
> To: David Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of
keeping
> it
>
>
> This patch changes the following drivers to use vlan_hwaccel_rx()
> and/or vlan_hwaccel_receive_skb() with a NULL vlan group if needed as
> they are not setup to dynamically enable/disable vlan removal in
> their MAC based on the vlan group:
>
> drivers/net/tg3.c Tested on BCM5704, looks good
> drivers/net/bnx2.c Tested on BCM5708, looks good
> drivers/net/acenic.cNot tested, I don't have one of these
> drivers/net/s2io.c Not tested, I don't have one of these
>
> In addition, these drivers might also need changes, but should
> probably be done by the maintainer as it's not clear exactly what
> change is needed:
>
> drivers/net/amd8111e.c
> drivers/net/cxgb3/*
>
> Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
>
> = drivers/net/acenic.c 1.77 vs edited =
> --- 1.77/drivers/net/acenic.c 2007-07-24 16:28:41 -04:00
> +++ edited/drivers/net/acenic.c 2007-11-03 12:27:40 -04:00
> @@ -2036,7 +2036,7 @@
>
> /* send it up */
> #if ACENIC_DO_VLAN
> - if (ap->vlgrp && (bd_flags & BD_FLG_VLAN_TAG)) {
> + if (bd_flags & BD_FLG_VLAN_TAG) {
> vlan_hwaccel_rx(skb, ap->vlgrp, retdesc->vlan);
> } else
> #endif
> = drivers/net/bnx2.c 1.135 vs edited =
> --- 1.135/drivers/net/bnx2.c 2007-09-20 15:14:21 -04:00
> +++ edited/drivers/net/bnx2.c 2007-11-05 09:34:26 -05:00
> @@ -2493,7 +2493,8 @@
> }
>
> #ifdef BCM_VLAN
> - if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && (bp->vlgrp
!= 0))
> {
> + if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) &&
> + (bp->vlgrp || (bp->flags & ASF_ENABLE_FLAG))) {
> vlan_hwaccel_receive_skb(skb, bp->vlgrp,
> rx_hdr->l2_fhdr_vlan_tag);
> }
> = drivers/net/s2io.c 1.124 vs edited =
> --- 1.124/drivers/net/s2io.c 2007-08-03 18:10:44 -04:00
> +++ edited/drivers/net/s2io.c 2007-11-03 12:29:09 -04:00
> @@ -6834,8 +6834,7 @@
> sp->mac_control.stats_info->sw_stat.mem_freed += skb->truesize;
> if (!sp->lro) {
> skb->protocol = eth_type_trans(skb, dev);
> - if ((sp->vlgrp && RXD_GET_VLAN_TAG(rxdp->Control_2) &&
> - vlan_strip_flag)) {
> + if (RXD_GET_VLAN_TAG(rxdp->Control_2) &&
vlan_strip_flag) {
> /* Queueing the vlan frame to the upper layer */
> if (napi)
> vlan_hwaccel_receive_skb(skb, sp->vlgrp,
> = drivers/net/tg3.c 1.523 vs edited =
> --- 1.523/drivers/net/tg3.c 2007-09-11 04:28:44 -04:00
> +++ edited/drivers/net/tg3.c 2007-11-05 09:38:33 -05:00
> @@ -3417,7 +3417,7 @@
>
> skb->protocol = eth_type_trans(skb, tp->dev);
> #if TG3_VLAN_TAG_USED
> - if (tp->vlgrp != NULL &&
> + if ((tp->vlgrp || (tp->tg3_flags & TG3_FLAG_ENABLE_ASF))
&&
> desc->type_flags & RXD_FLAG_VLAN) {
> tg3_vlan_rx(tp, skb,
> desc->err_vlan & RXD_VLAN_MASK);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] x86: arch/x86/Kconfig.cpu unification
On Tue, Nov 06, 2007 at 03:46:30AM +0100, Sam Ravnborg wrote: > On Mon, Nov 05, 2007 at 07:53:39PM -0500, Brian Gerst wrote: > > Sam Ravnborg wrote: > > > Move all CPU definitions to Kconfig.cpu > > > > This patch causes build failure on x86_64: > > > > lib/rwsem.c: In function ‘__init_rwsem’: > > lib/rwsem.c:24: error: ‘struct rw_semaphore’ has no member named ‘count’ > > lib/rwsem.c:24: error: ‘RWSEM_UNLOCKED_VALUE’ undeclared (first use in > > this function) > > lib/rwsem.c:24: error: (Each undeclared identifier is reported only once > > lib/rwsem.c:24: error: for each function it appears in.) > > lib/rwsem.c: In function ‘__rwsem_do_wake’: > > lib/rwsem.c:64: error: implicit declaration of function > > ‘rwsem_atomic_update’ > > lib/rwsem.c:64: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in this > > function) > > lib/rwsem.c:66: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in this > > function) > > lib/rwsem.c:115: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in > > this function) > > lib/rwsem.c:120: error: implicit declaration of function ‘rwsem_atomic_add’ > > lib/rwsem.c: In function ‘rwsem_down_failed_common’: > > lib/rwsem.c:169: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in > > this function) > > lib/rwsem.c: In function ‘rwsem_down_read_failed’: > > lib/rwsem.c:197: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in > > this function) > > lib/rwsem.c:197: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in > > this function) > > lib/rwsem.c: In function ‘rwsem_down_write_failed’: > > lib/rwsem.c:210: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in > > this function) > > > > git bisect gives: > > 55432d383871d127685d78f94e0ad60307dcc0e9 is first bad commit > > commit 55432d383871d127685d78f94e0ad60307dcc0e9 > > Author: Sam Ravnborg <[EMAIL PROTECTED]> > > Date: Thu Nov 1 21:54:39 2007 +0100 > > > > x86: arch/x86/Kconfig.cpu unification > > Seems that a default value fail to change value when we shift > from 32 to 64 bit. I have it reproduced here. > Will look at it tonight. The problem is that you source arch/x86/Kconfig.cpu from arch/x86/Kconfig.x86_64 but didn't give RWSEM_XCHGADD_ALGORITHM the required dependency on X86_32. > Sam cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Loopback mounts should update the mtime of the underlying file on writes
On Mon, 5 Nov 2007 19:09:24 -0600 Matt Mackall <[EMAIL PROTECTED]> wrote:
> Noticed by a Mercurial user. I think this should fix it.
>
"should". That pitter patter sound your hear is little akpm feet running
away.
>
> Index: l/drivers/block/loop.c
> ===
> --- l.orig/drivers/block/loop.c 2007-11-05 17:50:07.0 -0600
> +++ l/drivers/block/loop.c2007-11-05 19:03:51.0 -0600
> @@ -221,6 +221,7 @@ static int do_lo_send_aops(struct loop_d
> offset = pos & ((pgoff_t)PAGE_CACHE_SIZE - 1);
> bv_offs = bvec->bv_offset;
> len = bvec->bv_len;
> + file_update_time(file);
> while (len > 0) {
> sector_t IV;
> unsigned size;
> @@ -299,6 +300,7 @@ static int __do_lo_send_write(struct fil
>
> set_fs(get_ds());
> bw = file->f_op->write(file, buf, len, );
> + file_update_time(file);
> set_fs(old_fs);
> if (likely(bw == len))
> return 0;
Probably makes sense, but bear in mind that we can be fairly deep in
filesystem A functions here, and file_update_time() can do stuff like
starting journal transactions on filesystem B.
I expect the worst we'll see is not-yet-suppressed lockdep warnings and
possibly extra stack windup, but this patch may end up being more complex
than one expects..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] [BUG] rfcomm]
On 11/6/07, Dave Young <[EMAIL PROTECTED]> wrote: > On 11/5/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > > On 11/5/07, Dave Young <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I managed to produce this bug last weekend. I debugged it and found a > > > rfcomm_dev refcnt BUG. > > > please try the patch of attachment, sorry for attachement because of > > > my gmail/mutt configuration problem. > > > > > > I post it in below thread: > > > http://lkml.org/lkml/2007/11/4/207 > > > > It actually worse... :( > Hi, sorry for reply again, this seems a diffrent issue ... Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
On 10/1/07, Cornelia Huck <[EMAIL PROTECTED]> wrote: > On Fri, 28 Sep 2007 18:32:32 +0200, > Pierre-Yves Paulus <[EMAIL PROTECTED]> wrote: > > This looks more informational, thanks. > > > DEV: Unregistering device. ID = 'rfcomm0' > > PM: Removing info for No Bus:rfcomm0 > > kobject_uevent_env > > fill_kobj_path: path = '/class/tty/rfcomm0' > > fill_kobj_path: path = > > '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' > > kobject rfcomm0: cleaning up > > device_create_release called for rfcomm0 > > Here rfcomm0 was unregistered and released. > > > bus bluetooth: remove device acl00126253F906 > > PM: Removing info for bluetooth:acl00126253F906 > > kobject_uevent_env > > fill_kobj_path: path = > > '/devices/pci:00/:00:0f.4/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/hci2/acl00126253F906' > > kobject acl00126253F906: cleaning up > > And here the corresponding physdev. > > > BUG: unable to handle kernel NULL pointer dereference at virtual address > > > > printing eip: > > c0249e29 > > *pde = > > Oops: [#1] > > Modules linked in: rfcomm l2cap battery ipv6 dm_snapshot dm_mirror > > dm_mod softdog loop parport_pc parport floppy rtc pcspkr ac button > > psmouse serio_raw snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm > > snd_timer snd soundcore snd_page_alloc geode_rng cs5535_gpio hci_usb > > bluetooth geode_aes blkcipher tsdev evdev usbhid hid reiserfs ide_disk > > generic amd74xx ide_core ohci_hcd sata_via ata_generic 8139cp libata > > 8139too usbcore mii scsi_mod thermal processor fan > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010017 (2.6.23-rc8 #1) > > EIP is at skb_dequeue+0x23/0x4a > > eax: 0282 ebx: 0282 ecx: edx: caf8ab8c > > esi: c8428d48 edi: c8428c00 ebp: c8428c0c esp: c124ff60 > > ds: 007b es: 007b fs: gs: ss: 0068 > > Process events/0 (pid: 5, ti=c124e000 task=c1243500 task.ti=c124e000) > > Stack: caf8ab8c c024b0a1 c8428c00 d02f4075 c8428d60 c020eb8d c08978a8 > > > > cf7ab680 c8428d48 c020eac4 c01279a9 > > c124ffb4 > > 0046 c1243500 cf7ab680 cf7ab680 c0127ffe c124ffd0 c01280b0 > > > > Call Trace: > > [] skb_queue_purge+0x11/0x17 > > [] rfcomm_tty_flush_buffer+0x1c/0x33 [rfcomm] > > [] do_tty_hangup+0xc9/0x2d0 > > [] do_tty_hangup+0x0/0x2d0 > > [] run_workqueue+0x7d/0x103 > > [] worker_thread+0x0/0xbe > > [] worker_thread+0xb2/0xbe > > [] autoremove_wake_function+0x0/0x35 > > [] kthread+0x36/0x5b > > [] kthread+0x0/0x5b > > [] kernel_thread_helper+0x7/0x10 > > === > > rfcomm0 is already freed, maybe this code is still trying to access it? > > > Code: 89 42 0a 5b 5e 5f 5d c3 53 89 c2 9c 58 90 8d b4 26 00 00 00 00 89 > > c3 fa 90 8d b4 26 00 00 00 00 90 8b 0a 39 d1 75 04 31 c9 eb 17 <8b> 01 > > ff 4a 08 89 02 89 50 04 c7 01 00 00 00 00 c7 41 04 00 00 > > EIP: [] skb_dequeue+0x23/0x4a SS:ESP 0068:c124ff60 > > WARNING: at lib/kref.c:33 kref_get() > > [] kref_get+0x34/0x3d > > [] kobject_get+0xf/0x13 > > [] get_device+0xe/0x14 > > [] device_move+0x13/0x114 > > [] rfcomm_tty_close+0x23/0x61 [rfcomm] > > [] release_dev+0x1c0/0x54e > > [] rfcomm_dev_destruct+0x59/0x65 [rfcomm] > > [] rfcomm_dev_ioctl+0x329/0x4d0 [rfcomm] > > [] tick_program_event+0x2a/0x49 > > [] release_sock+0xc/0x74 > > [] tty_release+0x7/0xa > > [] __fput+0x93/0x147 > > [] filp_close+0x51/0x58 > > [] __sched_text_start+0x1d6/0x245 > > [] sys_close+0x54/0x83 > > [] syscall_call+0x7/0xb > > === > > DEVICE: moving 'rfcomm0' to '' > > kobject : cleaning up > > device_create_release called for rfcomm0 > > But here someone still tries to move rfcomm0 around? It already is gone > and released... The code path has no reference on rfcomm0. (Well, > device_move() tries to get a reference on the device to be moved, but > that doesn't help since the device is already gone.) > > This looks like a race inside rfcomm. The device_unregister() either > needs to be delayed until after device_move() has finished, or the > thread calling device_move() needs to have a reference. (device_move() > on an unregistered device should just fail but not oops.) Marcel? > - Hi, please try the attached patch. or the one by marcel in http://lkml.org/lkml/2007/11/5/111 Please tell me the result, thanks. Regards dave diff.rfcomm Description: Binary data
Re: [PATCH 03/10] x86: arch/x86/Kconfig.cpu unification
On Mon, Nov 05, 2007 at 07:53:39PM -0500, Brian Gerst wrote: > Sam Ravnborg wrote: > > Move all CPU definitions to Kconfig.cpu > > This patch causes build failure on x86_64: > > lib/rwsem.c: In function ‘__init_rwsem’: > lib/rwsem.c:24: error: ‘struct rw_semaphore’ has no member named ‘count’ > lib/rwsem.c:24: error: ‘RWSEM_UNLOCKED_VALUE’ undeclared (first use in > this function) > lib/rwsem.c:24: error: (Each undeclared identifier is reported only once > lib/rwsem.c:24: error: for each function it appears in.) > lib/rwsem.c: In function ‘__rwsem_do_wake’: > lib/rwsem.c:64: error: implicit declaration of function > ‘rwsem_atomic_update’ > lib/rwsem.c:64: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in this > function) > lib/rwsem.c:66: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in this > function) > lib/rwsem.c:115: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in > this function) > lib/rwsem.c:120: error: implicit declaration of function ‘rwsem_atomic_add’ > lib/rwsem.c: In function ‘rwsem_down_failed_common’: > lib/rwsem.c:169: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in > this function) > lib/rwsem.c: In function ‘rwsem_down_read_failed’: > lib/rwsem.c:197: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in > this function) > lib/rwsem.c:197: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in > this function) > lib/rwsem.c: In function ‘rwsem_down_write_failed’: > lib/rwsem.c:210: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in > this function) > > git bisect gives: > 55432d383871d127685d78f94e0ad60307dcc0e9 is first bad commit > commit 55432d383871d127685d78f94e0ad60307dcc0e9 > Author: Sam Ravnborg <[EMAIL PROTECTED]> > Date: Thu Nov 1 21:54:39 2007 +0100 > > x86: arch/x86/Kconfig.cpu unification Seems that a default value fail to change value when we shift from 32 to 64 bit. I have it reproduced here. Will look at it tonight. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add IORESOUCE_BUSY flag for System RAM take 2.
Hello.
I merged Baradi-san's patch and mine. This and Kame-san's
following patch is necessary for x86-64 memory unplug.
http://marc.info/?l=linux-mm=119399026017901=2
I heard Kame-san's patch is already included in -mm.
So, I'll repost merged patch now.
This patch is tested on 2.6.23-mm1.
Please apply.
---
i386 and x86-64 registers System RAM as IORESOURCE_MEM | IORESOURCE_BUSY.
But ia64 registers it as IORESOURCE_MEM only.
In addition, memory hotplug code registers new memory as IORESOURCE_MEM too.
This difference causes a failure of memory unplug of x86-64.
This patch fix it.
This patch adds IORESOURCE_BUSY to avoid potential overlap mapping
by PCI device.
Signed-off-by: Yasunori Goto <[EMAIL PROTECTED]>
Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
---
arch/ia64/kernel/efi.c |6 ++
kernel/resource.c |2 +-
mm/memory_hotplug.c|2 +-
3 files changed, 4 insertions(+), 6 deletions(-)
Index: current/arch/ia64/kernel/efi.c
===
--- current.orig/arch/ia64/kernel/efi.c 2007-11-02 17:17:30.0 +0900
+++ current/arch/ia64/kernel/efi.c 2007-11-02 17:19:10.0 +0900
@@ -,7 +,7 @@ efi_initialize_iomem_resources(struct re
if (md->num_pages == 0) /* should not happen */
continue;
- flags = IORESOURCE_MEM;
+ flags = IORESOURCE_MEM | IORESOURCE_BUSY;
switch (md->type) {
case EFI_MEMORY_MAPPED_IO:
@@ -1133,12 +1133,11 @@ efi_initialize_iomem_resources(struct re
case EFI_ACPI_MEMORY_NVS:
name = "ACPI Non-volatile Storage";
- flags |= IORESOURCE_BUSY;
break;
case EFI_UNUSABLE_MEMORY:
name = "reserved";
- flags |= IORESOURCE_BUSY | IORESOURCE_DISABLED;
+ flags |= IORESOURCE_DISABLED;
break;
case EFI_RESERVED_TYPE:
@@ -1147,7 +1146,6 @@ efi_initialize_iomem_resources(struct re
case EFI_ACPI_RECLAIM_MEMORY:
default:
name = "reserved";
- flags |= IORESOURCE_BUSY;
break;
}
Index: current/mm/memory_hotplug.c
===
--- current.orig/mm/memory_hotplug.c2007-11-02 17:19:09.0 +0900
+++ current/mm/memory_hotplug.c 2007-11-02 17:19:10.0 +0900
@@ -39,7 +39,7 @@ static struct resource *register_memory_
res->name = "System RAM";
res->start = start;
res->end = start + size - 1;
- res->flags = IORESOURCE_MEM;
+ res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
if (request_resource(_resource, res) < 0) {
printk("System RAM resource %llx - %llx cannot be added\n",
(unsigned long long)res->start, (unsigned long long)res->end);
Index: current/kernel/resource.c
===
--- current.orig/kernel/resource.c 2007-11-02 17:19:15.0 +0900
+++ current/kernel/resource.c 2007-11-02 17:22:39.0 +0900
@@ -287,7 +287,7 @@ walk_memory_resource(unsigned long start
int ret = -1;
res.start = (u64) start_pfn << PAGE_SHIFT;
res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
- res.flags = IORESOURCE_MEM;
+ res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
orig_end = res.end;
while ((res.start < res.end) && (find_next_system_ram() >= 0)) {
pfn = (unsigned long)(res.start >> PAGE_SHIFT);
--
Yasunori Goto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fat: optimize fat_count_free_clusters()
Andrew Morton <[EMAIL PROTECTED]> writes:
>> +/* 128kb is the whole sectors for FAT12 and FAT16 */
>> +#define FAT_READA_SIZE (128 * 1024)
>> +
>> +static void fat_ent_reada(struct super_block *sb, struct fat_entry *fatent,
>> + unsigned long reada_blocks)
>> +{
>> +struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
>> +sector_t blocknr;
>> +int i, offset;
>> +
>> +ops->ent_blocknr(sb, fatent->entry, , );
>> +
>> +for (i = 0; i < reada_blocks; i++)
>> +sb_breadahead(sb, blocknr + i);
>> +}
>
> You might find that it's simpler and faster to call
> page_cache_sync_readahead() against sb->s_bdev->bd_inode->i_mapping.
>
> Or maybe not - that requires a struct file_ra_state. We _used_ to have a
> nice simple read-some-stuff-into-pagecache function which didn't need an
> ra_state but that seems to have disappeared in the various recent readahead
> churn. Oh well.
Yes. I found it, but I gave up for now by file_ra_state. Also I'd like
to use a large block to read FAT. I'll rethink this code after large
block was merged.
Thanks.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] [BUG] rfcomm]
On 11/5/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > On 11/5/07, Dave Young <[EMAIL PROTECTED]> wrote: > > Hi, > > I managed to produce this bug last weekend. I debugged it and found a > > rfcomm_dev refcnt BUG. > > please try the patch of attachment, sorry for attachement because of > > my gmail/mutt configuration problem. > > > > I post it in below thread: > > http://lkml.org/lkml/2007/11/4/207 > > It actually worse... :( could you tell me your usage steps of rfcomm? Oct 23 19:41:42 alon1 EIP:0060:[]Tainted: PVLI Your kernel seems tainted. Regards dave > > Best Regards, > Alon Bar-Lev > > --- > > terrupt :02:01.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 > ieee80211_crypt: registered algorithm 'NULL' > ieee80211: 802.11 data/management/control stack, git-1.1.13 > ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> > ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq > ipw2200: Copyright(c) 2003-2006 Intel Corporation > Synaptics Touchpad, model: 1, fw: 5.9, id: 0x2c6ab1, caps: 0x884793/0x0 > serio: Synaptics pass-through port at isa0060/serio1/input0 > input: SynPS/2 Synaptics TouchPad as > /devices/platform/i8042/serio1/input/input2 > pnp: Device 00:0c activated. > nsc-ircc, chip->init > nsc-ircc, Found chip at base=0x02e > nsc-ircc, driver loaded (Dag Brattli) > IrDA: Registered device irda0 > nsc-ircc, Found dongle: HP HSDL-1100/HSDL-2100 > e1000: :02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:11:25:2e:e5:1f > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > Yenta: CardBus bridge found at :02:00.1 [1014:0552] > Yenta: Using INTVAL to route CSC interrupts to PCI > Yenta: Routing CardBus interrupts to PCI > Yenta TI: socket :02:00.1, mfunc 0x01d21b22, devctl 0x64 > Yenta: ISA IRQ mask 0x04b0, PCI irq 11 > Socket status: 3086 > pcmcia: parent PCI bridge I/O window: 0x4000 - 0x8fff > pcmcia: parent PCI bridge Memory window: 0xc020 - 0xcfff > pcmcia: parent PCI bridge Memory window: 0xe800 - 0xefff > ACPI: PCI Interrupt :00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, > low) -> IRQ 11 > PCI: Setting latency timer of device :00:1f.5 to 64 > udev: renamed network interface eth0 to eth1 > usb 2-1: new full speed USB device using uhci_hcd and address 3 > usb 2-1: configuration #1 chosen from 1 choice > usb 3-1: new full speed USB device using uhci_hcd and address 2 > usb 3-1: configuration #1 chosen from 1 choice > Bluetooth: Core ver 2.11 > NET: Registered protocol family 31 > Bluetooth: HCI device and connection manager initialized > Bluetooth: HCI socket layer initialized > Bluetooth: HCI USB driver ver 2.9 > intel8x0_measure_ac97_clock: measured 50304 usecs > intel8x0: clocking to 48000 > ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKC] -> GSI 11 (level, > low) -> IRQ 11 > ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection > usb 3-2: new full speed USB device using uhci_hcd and address 3 > usb 3-2: configuration #1 chosen from 1 choice > usbcore: registered new interface driver hci_usb > ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels) > IBM TrackPoint firmware: 0x0e, buttons: 3/3 > input: TPPS/2 IBM TrackPoint as > /devices/platform/i8042/serio1/serio2/input/input3 > EXT3 FS on loop5, internal journal > NET: Registered protocol family 17 > Non-volatile memory driver v1.2 > thinkpad_acpi: ThinkPad ACPI Extras v0.16 > thinkpad_acpi: http://ibm-acpi.sf.net/ > thinkpad_acpi: ThinkPad BIOS 1RETDPWW (3.21 ), EC 1RHT71WW-3.04 > thinkpad_acpi: IBM ThinkPad T42 > input: ThinkPad Extra Buttons as /devices/virtual/input/input4 > hdaps: IBM ThinkPad T42 detected. > hdaps: initial latch check good (0x01). > hdaps: device successfully initialized. > input: hdaps as /devices/platform/hdaps/input/input5 > hdaps: driver successfully loaded. > ACPI: AC Adapter [AC] (on-line) > ACPI: Battery Slot [BAT0] (battery present) > input: Power Button (FF) as /devices/virtual/input/input6 > ACPI: Power Button (FF) [PWRF] > input: Lid Switch as /devices/virtual/input/input7 > ACPI: Lid Switch [LID] > input: Sleep Button (CM) as /devices/virtual/input/input8 > ACPI: Sleep Button (CM) [SLPB] > ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) > ACPI: Processor [CPU] (supports 8 throttling states) > ACPI: Thermal Zone [THM0] (57 C) > Marking TSC unstable due to: possible TSC halt in C2. > Time: acpi_pm clocksource has been installed. > IBM machine detected. Enabling interrupts during APM calls. > apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) > dazuko: loaded, version=2.3.4 > io scheduler cfq registered > Module ioatdma cannot be unloaded due to unsafe usage in > drivers/dma/ioatdma.c:805 > PPP generic driver version 2.4.2 > SCSI subsystem initialized > Adding 1465120k swap on /dev/loop/4. Priority:-1 extents:1 across:1465120k > hda: selected mode 0x45 > hda: cache flushes supported > hdc: selected mode 0x42 > hdc: host side 80-wire cable detection failed, limiting
Truecrypt in kernel ?
i was trying to move my truecrypt container from my xp box to my debian etch box. on windows xp its just double click to mount it, no need to even install with the portable option. on linux i had to download the source of the kernel, compile it, add the truecrypt module, reboot and then mount it. just wondering why the truecrypt module isnt in the mainline kernel ? its the only cross platform encrypted disk solution out there and it should be less of a chore to use it in linux...is there something wrong with the truecrypt kernel driver ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] device struct bloat
On Monday 05 November 2007, Greg KH wrote:
> --- linux-2.6-2.orig/drivers/spi/spi.c
> +++ linux-2.6-2/drivers/spi/spi.c
It'd be quicker to end up in the right hands if you had
split this big and random patch according to subsystem...
There's already a patch in the MM queue that removes
the SPI-private semaphore. Except that it's missing
the bug noted below.
The class semaphore removal would be a different issue.
> @@ -613,7 +613,7 @@ int spi_write_then_read(struct spi_devic
> }
>
> /* ... unless someone else is using the pre-allocated buffer */
> - if (down_trylock()) {
> + if (mutex_trylock()) {
According to its kerneldoc, mutex_trylock() follows the
spinlock model not the semaphore model. So the sense of
this test is incorrect ... as will be any similar changes
in other parts of this patch:
* NOTE: this function follows the spin_trylock() convention, so
* it is negated to the down_trylock() return values! Be careful
* about this when converting semaphore users to mutexes.
So the patch in the MM queue says "if (!mutex_trylock(...)) {
> local_buf = kmalloc(SPI_BUFSIZ, GFP_KERNEL);
> if (!local_buf)
> return -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] replace "make ARCH=i386/x86_64 with make ARCH=x86"
Adrian Bunk wrote: The issue with "make allyesconfig" concerns me, although the same situation already exists with any multiple-choice configuration. What I guess we really want is to be able to specify a few specific choices. It's already available: $ cat myconfig CONFIG_HIGHMEM64G=y CONFIG_SMP=n CONFIG_PCI=n CONFIG_IPV6=m $ make allyesconfig KCONFIG_ALLCONFIG=myconfig OK. It would be nicer to be able to specify things via variables directly on the command line, but definitely fills the need. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
Jeremy Fitzhardinge wrote: Another thing it would be nice to add is an elf-note-like notion so that the kernel can export arbitrary key/value data to the bootloader (ie, the converse of the bootloader->kernel value list). Xen currently does this via ELF notes, but any semanically equivalent mechanism would do. It's probably simpler than trying to work out how to mush bzimage and ELF together. I suspect all we need is an offset-pointer field pointing into the kernel image. As far as the kernel build process is concerned, it becomes a section in the boot/compressed link script. That offset then needs to get exported to the setup.elf link stage and there adjusted to become a file offset. The ELF note format is sane enough, although it looks like it's not self-terminating, so we'd either need an offset and a length field, or adopt the convention that namesz = descsz = type = 0 terminates the block (I prefer the latter, myself.) We also need the notes documented, obviously. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] replace "make ARCH=i386/x86_64 with make ARCH=x86"
On Mon, Nov 05, 2007 at 03:46:20PM -0800, H. Peter Anvin wrote: > Sam Ravnborg wrote: >> On Mon, Nov 05, 2007 at 01:36:42PM -0800, Roland Dreier wrote: >>> > Like this: >>> > $ make ARCH=foo >>> > Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop. >>> >>> Seems sane, but maybe it would be worth putting in a special case >>> check for someone using i386 or x86_64 for ARCH, and tell them to >>> switch to x86? >> >> Will do so if my patchset gets applied. Need to redo it but >> that will be later this week and then I hope for a bit more >> feedback from the x86 guys. > > The patchset has looked good to me, and I believe it would be better to > take this particular breakage sooner rather than later. > > I haven't spoken up actively mostly because I wanted to look at the user > comments as they have been coming in. > > The issue with "make allyesconfig" concerns me, although the same situation > already exists with any multiple-choice configuration. What I guess we > really want is to be able to specify a few specific choices. It's already available: $ cat myconfig CONFIG_HIGHMEM64G=y CONFIG_SMP=n CONFIG_PCI=n CONFIG_IPV6=m $ make allyesconfig KCONFIG_ALLCONFIG=myconfig > -hpa cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]bluetooth rfcomm_dev refcount bug fix
On 11/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > Hi Dave, > > > In the rfcomm_tty_hangup the rfcomm_dev refcnt should be dropped later. > > > > If rfcomm_dev is destructed in tty_hangup function, then the later > > tty_close function will oops. > > your patch removes the complete release on hangup logic. That can't be > right. I think the problem is with calling tty_vhangup() and then > decrementing the reference count. In case we call tty_vhangup and we > have release on hangup we should not delete the device here. What about > the attached patch? Does it solve it? > > What are the steps to reproduce this? Hi, marcel steps to reproduce this : 1. add SP service 1."rfcomm listen 0 1" 2.from remote device connect to host side. 3. rfcomm release 0 right now , the rfcomm should be disconnected. oops will arise (sometimes) (please try more times) 4. then run again "rfcomm listen 0 1" if interval between these commands is shor, it will cause SLUB "poison writting" report, IMHO, the reason is same. = BUG kmalloc-128: Poison overwritten - INFO: 0xc27ca6e8-0xc27ca700. First byte 0x6a instead of 0x6b INFO: Allocated in rfcomm_dev_add+0x55/0x310 [rfcomm] age=91597 cpu=1 pid=2626 INFO: Freed in rfcomm_dev_destruct+0x84/0xb0 [rfcomm] age=71651 cpu=0 pid=2672 INFO: Slab 0xc104f940 used=5 fp=0xc27ca6e0 flags=0x40c3 INFO: Object 0xc27ca6e0 @offset=1760 fp=0xc27ca000 Bytes b4 0xc27ca6d0: 00 00 00 00 e3 b1 fe ff 5a 5a 5a 5a 5a 5a 5a 5a ã±þÿ Object 0xc27ca6e0: 6b 6b 6b 6b 6b 6b 6b 6b 6a 6b 6b 6b 6b 6b 6b 6b jkkk Object 0xc27ca6f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc27ca700: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkk Object 0xc27ca710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc27ca720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc27ca730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc27ca740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Object 0xc27ca750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkk¥ Redzone 0xc27ca760: bb bb bb bb Padding 0xc27ca788: 5a 5a 5a 5a 5a 5a 5a 5a [] check_bytes_and_report+0xaa/0xe0 [] check_object+0x198/0x1e0 [] alloc_debug_processing+0x9c/0x130 [] __slab_alloc+0x200/0x250 [] alloc_fdtable+0x80/0xf0 [] __kmalloc+0xe7/0xf0 [] alloc_fdtable+0x80/0xf0 [] alloc_fdtable+0x80/0xf0 [] expand_fdtable+0x2a/0xc0 [] dup_fd+0x1b9/0x200 [] getnstimeofday+0x3e/0x130 [] copy_files+0x33/0x60 [] copy_process+0x2e9/0x9f0 [] do_fork+0x4c/0x220 [] fd_install+0x21/0x50 [] sys_clone+0x32/0x40 [] syscall_call+0x7/0xb [] wait_for_common+0x60/0x160 === FIX kmalloc-128: Restoring 0xc27ca6e8-0xc27ca700=0x6b FIX kmalloc-128: Marking all objects used Your patch seems doesn't solve the problem. After release the rfcomm device, the remote device cannot connect again due to "Address already in use". Actually, remove the dev_del in hangup is just well, because the main issue is flush the buffer , let's leave the device deletion work for the tty_close. please take a look at my below dmesg text with debug infomation: Bluetooth: L2CAP ver 2.9 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: BNEP (Ethernet Emulation) ver 1.2 Bluetooth: BNEP filters: protocol multicast rfcomm_dev_ioctl: cmd 1074025160 arg bf9edeb0 rfcomm_create_dev: sk c2db18c0 dev_id 0 flags 0x3 rfcomm_dev_add: id 0 channel 1 rfcomm_tty_open: tty c2e41060 id 0 rfcomm_tty_open: dev c266c630 dst 56:B4:B6:C5:18:00 channel 1 opened 0 rfcomm_dev_modem_status: dlc c255adc0 dev c266c630 v24_sig 0x8d rfcomm_dev_put: dev c266c630 refcnt 19 rfcomm_dev_put: dev c266c630 refcnt 18 rfcomm_dev_put: dev c266c630 refcnt 17 rfcomm_dev_put: dev c266c630 refcnt 16 rfcomm_dev_put: dev c266c630 refcnt 15 rfcomm_dev_put: dev c266c630 refcnt 14 rfcomm_dev_put: dev c266c630 refcnt 13 rfcomm_dev_put: dev c266c630 refcnt 12 rfcomm_dev_put: dev c266c630 refcnt 11 rfcomm_dev_put: dev c266c630 refcnt 10 rfcomm_dev_put: dev c266c630 refcnt 9 rfcomm_dev_put: dev c266c630 refcnt 8 rfcomm_dev_put: dev c266c630 refcnt 7 rfcomm_dev_put: dev c266c630 refcnt 6 rfcomm_dev_put: dev c266c630 refcnt 5 rfcomm_dev_put: dev c266c630 refcnt 5 rfcomm_dev_put: dev c266c630 refcnt 4 rfcomm_dev_put: dev c266c630 refcnt 3 rfcomm_dev_put: dev c266c630 refcnt 6 rfcomm_dev_put: dev c266c630 refcnt 5 rfcomm_dev_put: dev c266c630 refcnt 4 rfcomm_dev_put: dev c266c630 refcnt 5 rfcomm_dev_put: dev c266c630 refcnt 4 rfcomm_dev_put: dev c266c630 refcnt 3 rfcomm_dev_put: dev c266c630 refcnt 6 rfcomm_dev_put: dev c266c630 refcnt 5
Re: x86_64 ten times slower than i386
Andi Kleen wrote: Jesse Barnes (cc:d) wrote a patch to address this, I think (x86: trim memory not covered by WB MTRRs), but as far as I can tell it hasn't been merged yet. System is Intel, 4gb of RAM. It wasn't merged because it broke booting on some systems. Besides the memory would be still lost -- all it did was to automate the "mem=" line. There really are only two ways to deal with this -- drop the memory (which should be automated, and a warning printed) or adjust the MTRRs. The problem is that at some point we run out of MTRRs, partially because they're masks instead of base/limit. Even use of PAT doesn't trivially resolve this issue with less than doing MTRR emulation via PAT (setting the default MTRR to WB); however, that is bound to cause trouble with SMM. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
H. Peter Anvin wrote: > Yes; specifically, boot_params.hdr.hardware_subarch == 0 (as opposed > to compile-time subarchitectures, like Voyager, which still boots the > same way as far as I know.) Yes, though it would be nice to use this mechanism to deal with voyager booting too, so that it can be normalized as a pvop backend rather than a separate build target. > It would definitely be good to document what other values in this > field changes, of course. Yep. > Specifically, with this bit set the decompression code won't touch the > segment registers at all, and it's up to the caller to have all code > and data segments set up with suitable descriptors. The kernel will > still try to install its own GDT when the kernel proper starts; this > becomes a hardware_subarch issue. Yes, the "setup proper kernel gdt" is part of the hwsubarch-specific startup code. Another thing it would be nice to add is an elf-note-like notion so that the kernel can export arbitrary key/value data to the bootloader (ie, the converse of the bootloader->kernel value list). Xen currently does this via ELF notes, but any semanically equivalent mechanism would do. It's probably simpler than trying to work out how to mush bzimage and ELF together. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
Jeremy Fitzhardinge wrote: I'm not so sure about that. Xen PV is rather fundamentally a different beast, hence the platform field recently added to the protocol. Hm, OK. So make this predicated on "hardware subarchitecture == PC". Yes; specifically, boot_params.hdr.hardware_subarch == 0 (as opposed to compile-time subarchitectures, like Voyager, which still boots the same way as far as I know.) It would definitely be good to document what other values in this field changes, of course. This is addressed by the "don't reload segments" bit in LOADFLAGS. OK. Specifically, with this bit set the decompression code won't touch the segment registers at all, and it's up to the caller to have all code and data segments set up with suitable descriptors. The kernel will still try to install its own GDT when the kernel proper starts; this becomes a hardware_subarch issue. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Loopback mounts should update the mtime of the underlying file on writes
Noticed by a Mercurial user. I think this should fix it.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/drivers/block/loop.c
===
--- l.orig/drivers/block/loop.c 2007-11-05 17:50:07.0 -0600
+++ l/drivers/block/loop.c 2007-11-05 19:03:51.0 -0600
@@ -221,6 +221,7 @@ static int do_lo_send_aops(struct loop_d
offset = pos & ((pgoff_t)PAGE_CACHE_SIZE - 1);
bv_offs = bvec->bv_offset;
len = bvec->bv_len;
+ file_update_time(file);
while (len > 0) {
sector_t IV;
unsigned size;
@@ -299,6 +300,7 @@ static int __do_lo_send_write(struct fil
set_fs(get_ds());
bw = file->f_op->write(file, buf, len, );
+ file_update_time(file);
set_fs(old_fs);
if (likely(bw == len))
return 0;
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
H. Peter Anvin wrote: > Jeremy Fitzhardinge wrote: >> H. Peter Anvin wrote: >>> Nailing down the interface as hard as possible is a good idea, to >>> avoid tying your hands for the future. >> >> Erm, I guess I see what you mean, but it comes to the effect of tying >> your hands now in a specific way, rather than having them tied in an >> unknown way later on... > > Sort of. The problem is you can frequently not > >> But I hadn't noticed the 32-bit boot protocol spec go in. Unfortunately >> it isn't useful for booting a pv Xen guest; I just mailed my >> comments. I hope we can iterate this to something more generally >> useful before >> getting too wedded to the current protocol. > > I'm not so sure about that. Xen PV is rather fundamentally a > different beast, hence the platform field recently added to the protocol. Hm, OK. So make this predicated on "hardware subarchitecture == PC". > > This is addressed by the "don't reload segments" bit in LOADFLAGS. OK. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] replace "make ARCH=i386/x86_64 with make ARCH=x86"
Guillaume Chazarain wrote: On 11/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: The issue with "make allyesconfig" concerns me, although the same situation already exists with any multiple-choice configuration. What I guess we really want is to be able to specify a few specific choices. I don't know enough about Kbuild to know if it's possible or not, but I would find it great if the *config targets could take CONFIG_ variables on the command line, like: make oldconfig CONFIG_SMP=y If it's not possible, why not inherit the CONFIG_ options from environment variables, like we already do for $CFLAGS, but only at make *config time in this case? It probably can only be done at *config time (and probably *should* only be done at *config time); but it seems like it would be a straightforward addition to Kconfig to look in the environment for variables named CONFIG_* just like it'd look in an old config file. That would definitely resolve a lot of issues. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] x86: arch/x86/Kconfig.cpu unification
Sam Ravnborg wrote: > Move all CPU definitions to Kconfig.cpu This patch causes build failure on x86_64: lib/rwsem.c: In function ‘__init_rwsem’: lib/rwsem.c:24: error: ‘struct rw_semaphore’ has no member named ‘count’ lib/rwsem.c:24: error: ‘RWSEM_UNLOCKED_VALUE’ undeclared (first use in this function) lib/rwsem.c:24: error: (Each undeclared identifier is reported only once lib/rwsem.c:24: error: for each function it appears in.) lib/rwsem.c: In function ‘__rwsem_do_wake’: lib/rwsem.c:64: error: implicit declaration of function ‘rwsem_atomic_update’ lib/rwsem.c:64: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in this function) lib/rwsem.c:66: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in this function) lib/rwsem.c:115: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in this function) lib/rwsem.c:120: error: implicit declaration of function ‘rwsem_atomic_add’ lib/rwsem.c: In function ‘rwsem_down_failed_common’: lib/rwsem.c:169: error: ‘RWSEM_ACTIVE_MASK’ undeclared (first use in this function) lib/rwsem.c: In function ‘rwsem_down_read_failed’: lib/rwsem.c:197: error: ‘RWSEM_WAITING_BIAS’ undeclared (first use in this function) lib/rwsem.c:197: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in this function) lib/rwsem.c: In function ‘rwsem_down_write_failed’: lib/rwsem.c:210: error: ‘RWSEM_ACTIVE_BIAS’ undeclared (first use in this function) git bisect gives: 55432d383871d127685d78f94e0ad60307dcc0e9 is first bad commit commit 55432d383871d127685d78f94e0ad60307dcc0e9 Author: Sam Ravnborg <[EMAIL PROTECTED]> Date: Thu Nov 1 21:54:39 2007 +0100 x86: arch/x86/Kconfig.cpu unification - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] RT: Allow current_cpu to be included in search
It doesn't hurt if we allow the current CPU to be included in the
search. We will just simply skip it later if the current CPU turns out
to be the lowest.
We will use this later in the series
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched_rt.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index fbe7b8a..7dd67db 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -326,9 +326,6 @@ static int find_lowest_rq(struct task_struct *task)
for_each_cpu_mask(cpu, cpu_mask) {
struct rq *rq = cpu_rq(cpu);
- if (cpu == rq->cpu)
- continue;
-
/* We look for lowest RT prio or non-rt CPU */
if (rq->rt.highest_prio >= MAX_RT_PRIO) {
lowest_rq = rq;
@@ -356,7 +353,7 @@ static struct rq *find_lock_lowest_rq(struct task_struct
*task,
for (tries = 0; tries < RT_MAX_TRIES; tries++) {
cpu = find_lowest_rq(task);
- if (cpu == -1)
+ if ((cpu == -1) || (cpu == rq->cpu))
break;
lowest_rq = cpu_rq(cpu);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] RT: Optimize rebalancing
We have logic to detect whether the system has migratable tasks, but we are
not using it when deciding whether to push tasks away. So we add support
for considering this new information.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched.c|2 ++
kernel/sched_rt.c | 10 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 8a27f09..0eced8c 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -268,6 +268,7 @@ struct rt_rq {
unsigned long rt_nr_uninterruptible;
/* highest queued rt task prio */
int highest_prio;
+ int overloaded;
};
/*
@@ -6869,6 +6870,7 @@ void __init sched_init(void)
rq->migration_thread = NULL;
INIT_LIST_HEAD(>migration_queue);
rq->rt.highest_prio = MAX_RT_PRIO;
+ rq->rt.overloaded = 0;
#endif
atomic_set(>nr_iowait, 0);
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 6ba5921..698f4d9 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -28,10 +28,12 @@ static inline cpumask_t *rt_overload(struct rq *rq)
static inline void rt_set_overload(struct rq *rq)
{
cpu_set(rq->cpu, *rt_overload_mask(rq->cpu));
+ rq->rt.overloaded = 1;
}
static inline void rt_clear_overload(struct rq *rq)
{
cpu_clear(rq->cpu, *rt_overload_mask(rq->cpu));
+ rq->rt.overloaded = 0;
}
static void update_rt_migration(struct task_struct *p, struct rq *rq)
@@ -496,6 +498,9 @@ static int push_rt_task(struct rq *rq)
assert_spin_locked(>lock);
+ if (!rq->rt.overloaded)
+ return 0;
+
next_task = pick_next_highest_task_rt(rq, -1);
if (!next_task)
return 0;
@@ -737,7 +742,7 @@ static void schedule_tail_balance_rt(struct rq *rq)
* the lock was owned by prev, we need to release it
* first via finish_lock_switch and then reaquire it here.
*/
- if (unlikely(rq->rt.rt_nr_running > 1)) {
+ if (unlikely(rq->rt.overloaded)) {
spin_lock(>lock);
push_rt_tasks(rq);
schedstat_inc(rq, rto_schedule_tail);
@@ -749,7 +754,8 @@ static void wakeup_balance_rt(struct rq *rq, struct
task_struct *p)
{
if (unlikely(rt_task(p)) &&
!task_running(rq, p) &&
- (p->prio >= rq->curr->prio)) {
+ (p->prio >= rq->rt.highest_prio) &&
+ rq->rt.overloaded) {
push_rt_tasks(rq);
schedstat_inc(rq, rto_wakeup);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] RT: Use a 2-d bitmap for searching lowest-pri CPU
The current code use a linear algorithm which causes scaling issues
on larger SMP machines. This patch replaces that algorithm with a
2-dimensional bitmap to reduce latencies in the wake-up path.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/Makefile |1
kernel/sched.c|4 +
kernel/sched_cpupri.c | 186 +
kernel/sched_cpupri.h | 10 +++
kernel/sched_rt.c | 52 ++
5 files changed, 210 insertions(+), 43 deletions(-)
diff --git a/kernel/Makefile b/kernel/Makefile
index e4e2acf..a822706 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_RELAY) += relay.o
obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
+obj-$(CONFIG_SMP) += sched_cpupri.o
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is
diff --git a/kernel/sched.c b/kernel/sched.c
index 0eced8c..6f24aa0 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -70,6 +70,8 @@
#include
+#include "sched_cpupri.h"
+
/*
* Scheduler clock - returns current time in nanosec units.
* This is default implementation.
@@ -6842,6 +6844,8 @@ void __init sched_init(void)
fair_sched_class.next = _sched_class;
idle_sched_class.next = NULL;
+ cpupri_init();
+
for_each_possible_cpu(i) {
struct rt_prio_array *array;
struct rq *rq;
diff --git a/kernel/sched_cpupri.c b/kernel/sched_cpupri.c
new file mode 100644
index 000..e6280b1
--- /dev/null
+++ b/kernel/sched_cpupri.c
@@ -0,0 +1,186 @@
+/*
+ * kernel/sched_cpupri.c
+ *
+ * CPU priority management
+ *
+ * Copyright (C) 2007 Novell
+ *
+ * Author: Gregory Haskins <[EMAIL PROTECTED]>
+ *
+ * This code tracks the priority of each CPU so that global migration
+ * decisions are easy to calculate. Each CPU can be in a state as follows:
+ *
+ * (INVALID), IDLE, NORMAL, RT1, ... RT99
+ *
+ * going from the lowest priority to the highest. CPUs in the INVALID state
+ * are not eligible for routing. The system maintains this state with
+ * a 2 dimensional bitmap (the first for priority class, the second for cpus
+ * in that class). Therefore a typical application without affinity
+ * restrictions can find a suitable CPU with O(1) complexity (e.g. two bit
+ * searches). For tasks with affinity restrictions, the algorithm has a
+ * worst case complexity of O(min(102, NR_CPUS)), though the scenario that
+ * yields the worst case search is fairly contrived.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include "sched_cpupri.h"
+
+#define CPUPRI_NR_PRIORITIES 2+MAX_RT_PRIO
+#define CPUPRI_NR_PRI_WORDS CPUPRI_NR_PRIORITIES/BITS_PER_LONG
+
+#define CPUPRI_INVALID -1
+#define CPUPRI_IDLE 0
+#define CPUPRI_NORMAL 1
+/* values 2-101 are RT priorities 0-99 */
+
+struct pri_vec
+{
+ raw_spinlock_t lock;
+ cpumask_t mask;
+};
+
+struct cpu_priority {
+ struct pri_vec pri_to_cpu[CPUPRI_NR_PRIORITIES];
+ long pri_active[CPUPRI_NR_PRI_WORDS];
+ intcpu_to_pri[NR_CPUS];
+};
+
+static __cacheline_aligned_in_smp struct cpu_priority cpu_priority;
+
+/* Convert between a 140 based task->prio, and our 102 based cpupri */
+static int convert_prio(int prio)
+{
+ int cpupri;
+
+ if (prio == MAX_PRIO)
+ cpupri = CPUPRI_IDLE;
+ else if (prio >= MAX_RT_PRIO)
+ cpupri = CPUPRI_NORMAL;
+ else
+ cpupri = MAX_RT_PRIO - prio + 1;
+
+ return cpupri;
+}
+
+#define for_each_cpupri_active(array, idx)\
+ for (idx = find_first_bit(array, CPUPRI_NR_PRIORITIES); \
+ idx < CPUPRI_NR_PRIORITIES;\
+ idx = find_next_bit(array, CPUPRI_NR_PRIORITIES, idx+1))
+
+/**
+ * cpupri_find - find the best (lowest-pri) CPU in the system
+ * @p: The task
+ * @lowest_mask: A mask to fill in with selected CPUs
+ *
+ * Note: This function returns the recommended CPUs as calculated during the
+ * current invokation. By the time the call returns, the CPUs may have in
+ * fact changed priorities any number of times. While not ideal, it is not
+ * an issue of correctness since the normal rebalancer logic will correct
+ * any discrepancies created by racing against the uncertainty of the current
+ * priority configuration.
+ *
+ * Returns: (int)bool - CPUs were found
+ */
+int cpupri_find(struct task_struct *p, cpumask_t *lowest_mask)
+{
+ int idx = 0;
+ struct cpu_priority *cp = _priority;
+ int task_pri = convert_prio(p->prio);
+
+
[PATCH 2/8] RT: Remove some CFS specific code from the wakeup path of RT tasks
The current wake-up code path tries to determine if it can optimize the
wake-up to "this_cpu" by computing load calculations. The problem is that
these calculations are only relevant to CFS tasks where load is king. For RT
tasks, priority is king. So the load calculation is completely wasted
bandwidth.
Therefore, we create a new sched_class interface to help with
pre-wakeup routing decisions and move the load calculation as a function
of CFS task's class.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
include/linux/sched.h |1
kernel/sched.c | 135 ---
kernel/sched_fair.c | 134 +++
kernel/sched_idletask.c |9 +++
kernel/sched_rt.c | 10 +++
5 files changed, 165 insertions(+), 124 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index fe3fd1d..cfef8fe 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1033,6 +1033,7 @@ struct sched_class {
void (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup);
void (*dequeue_task) (struct rq *rq, struct task_struct *p, int sleep);
void (*yield_task) (struct rq *rq, struct task_struct *p);
+ int (*select_task_rq)(struct task_struct *p, int sync);
void (*check_preempt_curr) (struct rq *rq, struct task_struct *p);
diff --git a/kernel/sched.c b/kernel/sched.c
index 49e68be..d16c686 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -859,6 +859,10 @@ static int balance_tasks(struct rq *this_rq, int this_cpu,
struct rq *busiest,
int *all_pinned, unsigned long *load_moved,
int *this_best_prio, struct rq_iterator *iterator);
+static unsigned long source_load(int cpu, int type);
+static unsigned long target_load(int cpu, int type);
+static unsigned long cpu_avg_load_per_task(int cpu);
+
#include "sched_stats.h"
#include "sched_rt.c"
#include "sched_fair.c"
@@ -1266,7 +1270,7 @@ void kick_process(struct task_struct *p)
* We want to under-estimate the load of migration sources, to
* balance conservatively.
*/
-static inline unsigned long source_load(int cpu, int type)
+static unsigned long source_load(int cpu, int type)
{
struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
@@ -1281,7 +1285,7 @@ static inline unsigned long source_load(int cpu, int type)
* Return a high guess at the load of a migration-target cpu weighted
* according to the scheduling class and "nice" value.
*/
-static inline unsigned long target_load(int cpu, int type)
+static unsigned long target_load(int cpu, int type)
{
struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
@@ -1295,7 +1299,7 @@ static inline unsigned long target_load(int cpu, int type)
/*
* Return the average load per task on the cpu's run queue
*/
-static inline unsigned long cpu_avg_load_per_task(int cpu)
+static unsigned long cpu_avg_load_per_task(int cpu)
{
struct rq *rq = cpu_rq(cpu);
unsigned long total = weighted_cpuload(cpu);
@@ -1454,53 +1458,6 @@ static int sched_balance_self(int cpu, int flag)
#endif /* CONFIG_SMP */
-/*
- * wake_idle() will wake a task on an idle cpu if task->cpu is
- * not idle and an idle cpu is available. The span of cpus to
- * search starts with cpus closest then further out as needed,
- * so we always favor a closer, idle cpu.
- *
- * Returns the CPU we should wake onto.
- */
-#if defined(ARCH_HAS_SCHED_WAKE_IDLE)
-static int wake_idle(int cpu, struct task_struct *p)
-{
- cpumask_t tmp;
- struct sched_domain *sd;
- int i;
-
- /*
-* If it is idle, then it is the best cpu to run this task.
-*
-* This cpu is also the best, if it has more than one task already.
-* Siblings must be also busy(in most cases) as they didn't already
-* pickup the extra load from this cpu and hence we need not check
-* sibling runqueue info. This will avoid the checks and cache miss
-* penalities associated with that.
-*/
- if (idle_cpu(cpu) || cpu_rq(cpu)->nr_running > 1)
- return cpu;
-
- for_each_domain(cpu, sd) {
- if (sd->flags & SD_WAKE_IDLE) {
- cpus_and(tmp, sd->span, p->cpus_allowed);
- for_each_cpu_mask(i, tmp) {
- if (idle_cpu(i))
- return i;
- }
- } else {
- break;
- }
- }
- return cpu;
-}
-#else
-static inline int wake_idle(int cpu, struct task_struct *p)
-{
- return cpu;
-}
-#endif
-
/***
* try_to_wake_up - wake up a thread
* @p: the to-be-woken-up thread
@@ -1523,8 +1480,6 @@ try_to_wake_up(struct task_struct *p, unsigned int state,
int sync, int mutex)
long old_state;
struct rq
[PATCH 1/8] RT: Consistency cleanup for this_rq usage
"this_rq" is normally used to denote the RQ on the current cpu
(i.e. "cpu_rq(this_cpu)"). So clean up the usage of this_rq to be
more consistent with the rest of the code.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched_rt.c | 46 +++---
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 9b06d7c..0348423 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -307,7 +307,7 @@ static struct task_struct *pick_next_highest_task_rt(struct
rq *rq,
/* Will lock the rq it finds */
static struct rq *find_lock_lowest_rq(struct task_struct *task,
- struct rq *this_rq)
+ struct rq *rq)
{
struct rq *lowest_rq = NULL;
cpumask_t cpu_mask;
@@ -321,21 +321,21 @@ static struct rq *find_lock_lowest_rq(struct task_struct
*task,
* Scan each rq for the lowest prio.
*/
for_each_cpu_mask(cpu, cpu_mask) {
- struct rq *rq = _cpu(runqueues, cpu);
+ struct rq *curr_rq = _cpu(runqueues, cpu);
- if (cpu == this_rq->cpu)
+ if (cpu == rq->cpu)
continue;
/* We look for lowest RT prio or non-rt CPU */
- if (rq->rt.highest_prio >= MAX_RT_PRIO) {
- lowest_rq = rq;
+ if (curr_rq->rt.highest_prio >= MAX_RT_PRIO) {
+ lowest_rq = curr_rq;
break;
}
/* no locking for now */
- if (rq->rt.highest_prio > task->prio &&
- (!lowest_rq || rq->rt.highest_prio >
lowest_rq->rt.highest_prio)) {
- lowest_rq = rq;
+ if (curr_rq->rt.highest_prio > task->prio &&
+ (!lowest_rq || curr_rq->rt.highest_prio >
lowest_rq->rt.highest_prio)) {
+ lowest_rq = curr_rq;
}
}
@@ -343,16 +343,16 @@ static struct rq *find_lock_lowest_rq(struct task_struct
*task,
break;
/* if the prio of this runqueue changed, try again */
- if (double_lock_balance(this_rq, lowest_rq)) {
+ if (double_lock_balance(rq, lowest_rq)) {
/*
* We had to unlock the run queue. In
* the mean time, task could have
* migrated already or had its affinity changed.
* Also make sure that it wasn't scheduled on its rq.
*/
- if (unlikely(task_rq(task) != this_rq ||
+ if (unlikely(task_rq(task) != rq ||
!cpu_isset(lowest_rq->cpu,
task->cpus_allowed) ||
-task_running(this_rq, task) ||
+task_running(rq, task) ||
!task->se.on_rq)) {
spin_unlock(_rq->lock);
lowest_rq = NULL;
@@ -377,21 +377,21 @@ static struct rq *find_lock_lowest_rq(struct task_struct
*task,
* running task can migrate over to a CPU that is running a task
* of lesser priority.
*/
-static int push_rt_task(struct rq *this_rq)
+static int push_rt_task(struct rq *rq)
{
struct task_struct *next_task;
struct rq *lowest_rq;
int ret = 0;
int paranoid = RT_MAX_TRIES;
- assert_spin_locked(_rq->lock);
+ assert_spin_locked(>lock);
- next_task = pick_next_highest_task_rt(this_rq, -1);
+ next_task = pick_next_highest_task_rt(rq, -1);
if (!next_task)
return 0;
retry:
- if (unlikely(next_task == this_rq->curr)) {
+ if (unlikely(next_task == rq->curr)) {
WARN_ON(1);
return 0;
}
@@ -401,24 +401,24 @@ static int push_rt_task(struct rq *this_rq)
* higher priority than current. If that's the case
* just reschedule current.
*/
- if (unlikely(next_task->prio < this_rq->curr->prio)) {
- resched_task(this_rq->curr);
+ if (unlikely(next_task->prio < rq->curr->prio)) {
+ resched_task(rq->curr);
return 0;
}
- /* We might release this_rq lock */
+ /* We might release rq lock */
get_task_struct(next_task);
/* find_lock_lowest_rq locks the rq if found */
- lowest_rq = find_lock_lowest_rq(next_task, this_rq);
+ lowest_rq = find_lock_lowest_rq(next_task, rq);
if (!lowest_rq) {
struct task_struct *task;
/*
-
[PATCH 5/8] RT: Pre-route RT tasks on wakeup
In the original patch series that Steven Rostedt and I worked on together,
we both took different approaches to low-priority wakeup path. I utilized
"pre-routing" (push the task away to a less important RQ before activating)
approach, while Steve utilized a "post-routing" approach. The advantage of
my approach is that you avoid the overhead of a wasted activate/deactivate
cycle and peripherally related burdens. The advantage of Steve's method is
that it neatly solves an issue preventing a "pull" optimization from being
deployed.
In the end, we ended up deploying Steve's idea. But it later dawned on me
that we could get the best of both worlds by deploying both ideas together,
albeit slightly modified.
The idea is simple: Use a "light-weight" lookup for pre-routing, since we
only need to approximate a good home for the task. And we also retain the
post-routing push logic to clean up any inaccuracies caused by a condition
of "priority mistargeting" caused by the lightweight lookup. Most of the
time, the pre-routing should work and yield lower overhead. In the cases
where it doesnt, the post-router will bat cleanup.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched_rt.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 7dd67db..43d4ea6 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -202,9 +202,28 @@ yield_task_rt(struct rq *rq, struct task_struct *p)
requeue_task_rt(rq, p);
}
+static int find_lowest_rq(struct task_struct *task);
+
#ifdef CONFIG_SMP
static int select_task_rq_rt(struct task_struct *p, int sync)
{
+ struct rq *rq = task_rq(p);
+
+ /*
+* If the task will not preempt the RQ, try to find a better RQ
+* before we even activate the task
+*/
+ if ((p->prio >= rq->rt.highest_prio)
+ && (p->nr_cpus_allowed > 1)) {
+ int cpu = find_lowest_rq(p);
+
+ return (cpu == -1) ? task_cpu(p) : cpu;
+ }
+
+ /*
+* Otherwise, just let it ride on the affined RQ and the
+* post-schedule router will push the preempted task away
+*/
return task_cpu(p);
}
#endif /* CONFIG_SMP */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] RT: scheduler migration/wakeup enhancements
Ingo, Steven, Thomas, Please consider this series for inclusion in 23-rt6, as it has shown to make a substantial improvement in our local testing. Independent verification and/or comments/review are more than welcome. -Greg - RT: scheduler migration/wakeup enhancements This series applies to 23.1-rt5 and includes numerous tweaks to the scheduler. The primary goal of this set of patches is to further improve wake-up latencies (particularly on larger SMP systems) and decrease migration overhead. This is accomplished by making improvements on several fronts: 1) We factor in CPU topology in the routing decision to pick the best migration target according to cache hierarchy. 2) We moved some CFS load calculation code as a member function of the CFS sched_class. This removes this unecessary code from the RT fastpath for tasks in the RT sched_class. 3) We make further improvements against non-migratable tasks by factoring in the RQ overload state, instead of just the RQ depth. 4) We replace the linear priority search with a 2-d algorithm. In past -rt releases, latencies could become quickly absymal on larger SMP (8+ cpus) to the order of 350us+. The recent work in -rt2 and -rt4 dropped this figure by a large margin, bringing things in the order of approximately ~120us. This new series improves upon this work even further, bringing latencies down to the sub 80us mark on our reference 8-way Intel C2D 5335 Xeon. These figures were obtained by simultaneous execution of: # ./cyclictest -n -p 90 -t 8 -d 100 -i 100 # while true; do make mrproper; make alldefconfig; make -j 128; done for long durations. The following are the results from one particular run, though the results are similar across various short and long term trials in our labs. 23.1-rt5-baseline -- 138.60 110.62 70.96 23/808 10246 T: 0 ( 5179) P:90 I:100 C:9011636 Min: 2 Act:4 Avg:4 Max: 117 T: 1 ( 5180) P:89 I:200 C:4505819 Min: 2 Act:5 Avg:4 Max: 95 T: 2 ( 5181) P:88 I:300 C:3003879 Min: 2 Act:9 Avg:5 Max: 85 T: 3 ( 5182) P:87 I:400 C:2252910 Min: 2 Act:3 Avg:4 Max: 75 T: 4 ( 5183) P:86 I:500 C:1802328 Min: 2 Act:7 Avg:5 Max: 71 T: 5 ( 5184) P:85 I:600 C:1501940 Min: 2 Act:4 Avg:5 Max: 74 T: 6 ( 5185) P:84 I:700 C:1287377 Min: 2 Act:6 Avg:6 Max: 85 T: 7 ( 5186) P:83 I:800 C:1126455 Min: 2 Act:4 Avg:5 Max: 75 23.1-rt5-gh -- 146.47 127.99 85.35 30/815 32289 T: 0 ( 5027) P:90 I:100 C:10856538 Min: 2 Act:4 Avg:4 Max: 60 T: 1 ( 5028) P:89 I:200 C:5428270 Min: 2 Act:7 Avg:5 Max: 57 T: 2 ( 5029) P:88 I:300 C:3618846 Min: 2 Act:5 Avg:5 Max: 48 T: 3 ( 5030) P:87 I:400 C:2714135 Min: 2 Act:7 Avg:5 Max: 61 T: 4 ( 5031) P:86 I:500 C:2171308 Min: 2 Act:6 Avg:6 Max: 51 T: 5 ( 5032) P:85 I:600 C:1809424 Min: 2 Act:5 Avg:7 Max: 59 T: 6 ( 5033) P:84 I:700 C:1550935 Min: 2 Act:6 Avg:6 Max: 54 T: 7 ( 5034) P:83 I:800 C:1357068 Min: 2 Act:7 Avg:6 Max: 62 Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] RT: Optimize our cpu selection based on topology
The current code base assumes a relatively flat CPU/core topology and will
route RT tasks to any CPU fairly equally. In the real world, there are
various toplogies and affinities that govern where a task is best suited to
run with the smallest amount of overhead. NUMA and multi-core CPUs are
prime examples of topologies that can impact cache performance.
Fortunately, linux is already structured to represent these topologies via
the sched_domains interface. So we change our RT router to consult a
combination of topology and affinity policy to best place tasks during
migration.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched.c|1 +
kernel/sched_rt.c | 99 +++--
2 files changed, 88 insertions(+), 12 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index d16c686..8a27f09 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -26,6 +26,7 @@
* 2007-07-01 Group scheduling enhancements by Srivatsa Vaddagiri
* 2007-10-22 RT overload balancing by Steven Rostedt
* (with thanks to Gregory Haskins)
+ * 2007-11-05 RT migration/wakeup tuning by Gregory Haskins
*/
#include
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index 43d4ea6..6ba5921 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -331,34 +331,109 @@ static struct task_struct
*pick_next_highest_task_rt(struct rq *rq,
return next;
}
-static int find_lowest_rq(struct task_struct *task)
+static int find_lowest_cpus(struct task_struct *task, cpumask_t *lowest_mask)
{
- int cpu;
- cpumask_t cpu_mask;
- struct rq *lowest_rq = NULL;
+ int cpu;
+ cpumask_t valid_mask;
+ int lowest_prio = -1;
+ int ret = 0;
- cpus_and(cpu_mask, cpu_online_map, task->cpus_allowed);
+ cpus_clear(*lowest_mask);
+ cpus_and(valid_mask, cpu_online_map, task->cpus_allowed);
/*
* Scan each rq for the lowest prio.
*/
- for_each_cpu_mask(cpu, cpu_mask) {
+ for_each_cpu_mask(cpu, valid_mask) {
struct rq *rq = cpu_rq(cpu);
/* We look for lowest RT prio or non-rt CPU */
if (rq->rt.highest_prio >= MAX_RT_PRIO) {
- lowest_rq = rq;
- break;
+ if (ret)
+ cpus_clear(*lowest_mask);
+ cpu_set(rq->cpu, *lowest_mask);
+ return 1;
}
/* no locking for now */
- if (rq->rt.highest_prio > task->prio &&
- (!lowest_rq || rq->rt.highest_prio >
lowest_rq->rt.highest_prio)) {
- lowest_rq = rq;
+ if ((rq->rt.highest_prio > task->prio)
+ && (rq->rt.highest_prio >= lowest_prio)) {
+ if (rq->rt.highest_prio > lowest_prio) {
+ /* new low - clear old data */
+ lowest_prio = rq->rt.highest_prio;
+ cpus_clear(*lowest_mask);
+ }
+ cpu_set(rq->cpu, *lowest_mask);
+ ret = 1;
+ }
+ }
+
+ return ret;
+}
+
+static inline int pick_optimal_cpu(int this_cpu, cpumask_t *mask)
+{
+ int first;
+
+ /* "this_cpu" is cheaper to preempt than a remote processor */
+ if ((this_cpu != -1) && cpu_isset(this_cpu, *mask))
+ return this_cpu;
+
+ first = first_cpu(*mask);
+ if (first != NR_CPUS)
+ return first;
+
+ return -1;
+}
+
+static int find_lowest_rq(struct task_struct *task)
+{
+ struct sched_domain *sd;
+ cpumask_t lowest_mask;
+ int this_cpu = smp_processor_id();
+ int cpu = task_cpu(task);
+
+ if (!find_lowest_cpus(task, _mask))
+ return -1;
+
+ /*
+* At this point we have built a mask of cpus representing the
+* lowest priority tasks in the system. Now we want to elect
+* the best one based on our affinity and topology.
+*
+* We prioritize the last cpu that the task executed on since
+* it is most likely cache-hot in that location.
+*/
+ if (cpu_isset(cpu, lowest_mask))
+ return cpu;
+
+ /*
+* Otherwise, we consult the sched_domains span maps to figure
+* out which cpu is logically closest to our hot cache data.
+*/
+ if (this_cpu == cpu)
+ this_cpu = -1; /* Skip this_cpu opt if the same */
+
+ for_each_domain(cpu, sd) {
+ if (sd->flags & SD_WAKE_AFFINE) {
+ cpumask_t domain_mask;
+ int best_cpu;
+
+ cpus_and(domain_mask, sd->span, lowest_mask);
+
+ best_cpu = pick_optimal_cpu(this_cpu,
+
[PATCH 3/8] RT: Break out the search function
Isolate the search logic into a function so that it can be used later
in places other than find_locked_lowest_rq().
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
kernel/sched_rt.c | 62 -
1 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c
index f1fc1b4..fbe7b8a 100644
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -312,43 +312,55 @@ static struct task_struct
*pick_next_highest_task_rt(struct rq *rq,
return next;
}
-/* Will lock the rq it finds */
-static struct rq *find_lock_lowest_rq(struct task_struct *task,
- struct rq *rq)
+static int find_lowest_rq(struct task_struct *task)
{
- struct rq *lowest_rq = NULL;
- cpumask_t cpu_mask;
int cpu;
- int tries;
+ cpumask_t cpu_mask;
+ struct rq *lowest_rq = NULL;
cpus_and(cpu_mask, cpu_online_map, task->cpus_allowed);
- for (tries = 0; tries < RT_MAX_TRIES; tries++) {
- /*
-* Scan each rq for the lowest prio.
-*/
- for_each_cpu_mask(cpu, cpu_mask) {
- struct rq *curr_rq = _cpu(runqueues, cpu);
+ /*
+* Scan each rq for the lowest prio.
+*/
+ for_each_cpu_mask(cpu, cpu_mask) {
+ struct rq *rq = cpu_rq(cpu);
- if (cpu == rq->cpu)
- continue;
+ if (cpu == rq->cpu)
+ continue;
- /* We look for lowest RT prio or non-rt CPU */
- if (curr_rq->rt.highest_prio >= MAX_RT_PRIO) {
- lowest_rq = curr_rq;
- break;
- }
+ /* We look for lowest RT prio or non-rt CPU */
+ if (rq->rt.highest_prio >= MAX_RT_PRIO) {
+ lowest_rq = rq;
+ break;
+ }
- /* no locking for now */
- if (curr_rq->rt.highest_prio > task->prio &&
- (!lowest_rq || curr_rq->rt.highest_prio >
lowest_rq->rt.highest_prio)) {
- lowest_rq = curr_rq;
- }
+ /* no locking for now */
+ if (rq->rt.highest_prio > task->prio &&
+ (!lowest_rq || rq->rt.highest_prio >
lowest_rq->rt.highest_prio)) {
+ lowest_rq = rq;
}
+ }
+
+ return lowest_rq ? lowest_rq->cpu : -1;
+}
+
+/* Will lock the rq it finds */
+static struct rq *find_lock_lowest_rq(struct task_struct *task,
+ struct rq *rq)
+{
+ struct rq *lowest_rq = NULL;
+ int cpu;
+ int tries;
+
+ for (tries = 0; tries < RT_MAX_TRIES; tries++) {
+ cpu = find_lowest_rq(task);
- if (!lowest_rq)
+ if (cpu == -1)
break;
+ lowest_rq = cpu_rq(cpu);
+
/* if the prio of this runqueue changed, try again */
if (double_lock_balance(rq, lowest_rq)) {
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] fat: optimize fat_count_free_clusters()
On Mon, 05 Nov 2007 07:09:00 +0900
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
> On large partition, scanning the free clusters is very slow if users
> doesn't use "usefree" option.
>
> For optimizing it, this patch uses sb_breadahead() to read of FAT
> sectors. On some user's 15GB partition, this patch improved it very
> much (1min => 600ms).
>
> The following is the result of 2GB partition on my machine.
>
> without patch:
> [EMAIL PROTECTED] (/)# time df -h > /dev/null
>
> real0m1.202s
> user0m0.000s
> sys 0m0.440s
>
> with patch:
> [EMAIL PROTECTED] (/)# time df -h > /dev/null
>
> real0m0.378s
> user0m0.012s
> sys 0m0.168s
>
Can't complain about that ;)
> ---
>
> fs/fat/fatent.c | 28
> 1 file changed, 28 insertions(+)
>
> diff -puN fs/fat/fatent.c~fat_optimize-count-freeclus fs/fat/fatent.c
> --- linux-2.6/fs/fat/fatent.c~fat_optimize-count-freeclus 2007-11-05
> 06:01:10.0 +0900
> +++ linux-2.6-hirofumi/fs/fat/fatent.c2007-11-05 06:01:10.0
> +0900
> @@ -590,21 +590,49 @@ error:
>
> EXPORT_SYMBOL_GPL(fat_free_clusters);
>
> +/* 128kb is the whole sectors for FAT12 and FAT16 */
> +#define FAT_READA_SIZE (128 * 1024)
> +
> +static void fat_ent_reada(struct super_block *sb, struct fat_entry *fatent,
> + unsigned long reada_blocks)
> +{
> + struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
> + sector_t blocknr;
> + int i, offset;
> +
> + ops->ent_blocknr(sb, fatent->entry, , );
> +
> + for (i = 0; i < reada_blocks; i++)
> + sb_breadahead(sb, blocknr + i);
> +}
You might find that it's simpler and faster to call
page_cache_sync_readahead() against sb->s_bdev->bd_inode->i_mapping.
Or maybe not - that requires a struct file_ra_state. We _used_ to have a
nice simple read-some-stuff-into-pagecache function which didn't need an
ra_state but that seems to have disappeared in the various recent readahead
churn. Oh well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] replace "make ARCH=i386/x86_64 with make ARCH=x86"
On 11/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > The issue with "make allyesconfig" concerns me, although the same > situation already exists with any multiple-choice configuration. What I > guess we really want is to be able to specify a few specific choices. I don't know enough about Kbuild to know if it's possible or not, but I would find it great if the *config targets could take CONFIG_ variables on the command line, like: make oldconfig CONFIG_SMP=y If it's not possible, why not inherit the CONFIG_ options from environment variables, like we already do for $CFLAGS, but only at make *config time in this case? -- Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 06 Nov 2007 01:21:09 +0100 > David Miller wrote: > > From: Patrick McHardy <[EMAIL PROTECTED]> > > Date: Mon, 05 Nov 2007 19:00:19 +0100 > > > >> This looks like a rather expensive operation for the unlikely case > >> that packets will be received by a packet socket. IMO it should only > >> be reconstructed if actually needed, by af_packet itself. > > > > Completely agreed. We should not do this by default when %99 > > of the networking stack simply does not care about this. > > > I think there is one more case that matters, which is briding > from a device with VLAN stripping for a VLAN not configured > locally. The tag will be stripped and will be lost for forwarded > packets. But I'm not exactly sure this really can be configured > (time for bed so I'll check tommorrow). If so then when such rules are loaded, just like PF_PACKET, it can set the indication to start reconstituting VLAN headers stripped by HW. > >> As we discussed some time back storing the VLAN tag in the CB on > >> TX clashes with other users of the CB like qdiscs, so we need a > >> new field in the skb for this anyway. > > > > Someone will have to find a way to remove some other fields in > > sk_buff before I'm going to allow more space to be eaten up > > by this completely fringe case feature. > > We have a two byte hole after tc_verd where we could fit this in. > But I'm pretty sure we also could reuse some other fields on input, > like queue_mapping or maybe even destructor for unowned skbs. Two bytes is enough, so if there is a hole we can use it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] more drm bug fixes and cleanups
Hi Linus,
Sorry these came up after I made yesterdays tree, two bugfixes, one
one-line cleanup..
Please pull from 'drm-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
to receive the following updates:
drivers/char/drm/drmP.h |2 --
drivers/char/drm/drm_ioctl.c|2 +-
drivers/char/drm/drm_os_linux.h |8
drivers/char/drm/savage_bci.c |3 ---
4 files changed, 1 insertions(+), 14 deletions(-)
Dave Airlie (2):
drm: remove second forward decleration of drm device struct.
drm: remove remnants of DRM_COPY_FROM/TO_USER_IOCTL
Li Zefan (1):
drm: DRM: fix memset size error
diff --git a/drivers/char/drm/drmP.h b/drivers/char/drm/drmP.h
index 9dd0760..dde02a1 100644
--- a/drivers/char/drm/drmP.h
+++ b/drivers/char/drm/drmP.h
@@ -559,8 +559,6 @@ struct drm_mm {
* a family of cards. There will one drm_device for each card present
* in this family
*/
-struct drm_device;
-
struct drm_driver {
int (*load) (struct drm_device *, unsigned long flags);
int (*firstopen) (struct drm_device *);
diff --git a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c
index d9be146..3cbebf8 100644
--- a/drivers/char/drm/drm_ioctl.c
+++ b/drivers/char/drm/drm_ioctl.c
@@ -272,7 +272,7 @@ int drm_getstats(struct drm_device *dev, void *data,
struct drm_stats *stats = data;
int i;
- memset(stats, 0, sizeof(stats));
+ memset(stats, 0, sizeof(*stats));
mutex_lock(>struct_mutex);
diff --git a/drivers/char/drm/drm_os_linux.h b/drivers/char/drm/drm_os_linux.h
index 76e44ac..daa69c9 100644
--- a/drivers/char/drm/drm_os_linux.h
+++ b/drivers/char/drm/drm_os_linux.h
@@ -62,14 +62,6 @@ static __inline__ int mtrr_del(int reg, unsigned long base,
unsigned long size)
#endif
-/** For data going into the kernel through the ioctl argument */
-#define DRM_COPY_FROM_USER_IOCTL(arg1, arg2, arg3) \
- if ( copy_from_user(, arg2, arg3) )\
- return -EFAULT
-/** For data going from the kernel through the ioctl argument */
-#define DRM_COPY_TO_USER_IOCTL(arg1, arg2, arg3) \
- if ( copy_to_user(arg1, , arg3) ) \
- return -EFAULT
/** Other copying of data to kernel space */
#define DRM_COPY_FROM_USER(arg1, arg2, arg3) \
copy_from_user(arg1, arg2, arg3)
diff --git a/drivers/char/drm/savage_bci.c b/drivers/char/drm/savage_bci.c
index 59484d5..d465b2f 100644
--- a/drivers/char/drm/savage_bci.c
+++ b/drivers/char/drm/savage_bci.c
@@ -968,9 +968,6 @@ static int savage_bci_event_wait(struct drm_device *dev,
void *data, struct drm_
DRM_DEBUG("\n");
- DRM_COPY_FROM_USER_IOCTL(event, (drm_savage_event_wait_t __user *) data,
-sizeof(event));
-
UPDATE_EVENT_COUNTER();
if (dev_priv->status_ptr)
hw_e = dev_priv->status_ptr[1] & 0x;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86_64 ten times slower than i386
On Mon, Nov 05, 2007 at 08:32:24AM -0800, Ray Lee wrote: > (Don't trim cc:s.) > > On Nov 5, 2007 8:00 AM, Bo Brantén <[EMAIL PROTECTED]> wrote: > > >> Intel Core 2 Quad > >> and I noticed that the 64-bit versions was at least 10 times slower than > >> the > >> 32-bit versions, > > > > > After I uppgraded the BIOS the mtrr looks like below, and now it works if > > I boot with mem=4736M so I can use all memory but it still doesn't work > > without the mem parameter then it will run as slow as before. Then the BIOS is still broken Comapl in to your motherboard vendor. > > > > reg00: base=0x ( 0MB), size=2048MB: write-back, count=1 > > reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1 > > reg02: base=0xc000 (3072MB), size= 256MB: write-back, count=1 > > reg03: base=0xcf80 (3320MB), size= 8MB: uncachable, count=1 > > reg04: base=0xcf70 (3319MB), size= 1MB: uncachable, count=1 > > reg05: base=0x1 (4096MB), size= 512MB: write-back, count=1 > > reg06: base=0x12000 (4608MB), size= 128MB: write-back, count=1 > > Jesse Barnes (cc:d) wrote a patch to address this, I think (x86: trim > memory not covered by WB MTRRs), but as far as I can tell it hasn't > been merged yet. System is Intel, 4gb of RAM. It wasn't merged because it broke booting on some systems. Besides the memory would be still lost -- all it did was to automate the "mem=" line. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
David Miller wrote: From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 05 Nov 2007 19:00:19 +0100 This looks like a rather expensive operation for the unlikely case that packets will be received by a packet socket. IMO it should only be reconstructed if actually needed, by af_packet itself. Completely agreed. We should not do this by default when %99 of the networking stack simply does not care about this. I think there is one more case that matters, which is briding from a device with VLAN stripping for a VLAN not configured locally. The tag will be stripped and will be lost for forwarded packets. But I'm not exactly sure this really can be configured (time for bed so I'll check tommorrow). As we discussed some time back storing the VLAN tag in the CB on TX clashes with other users of the CB like qdiscs, so we need a new field in the skb for this anyway. Someone will have to find a way to remove some other fields in sk_buff before I'm going to allow more space to be eaten up by this completely fringe case feature. We have a two byte hole after tc_verd where we could fit this in. But I'm pretty sure we also could reuse some other fields on input, like queue_mapping or maybe even destructor for unowned skbs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23.1: mdadm/raid5 hung/d-state
On 11/5/07, Justin Piszcz <[EMAIL PROTECTED]> wrote: [..] > > Are you seeing the same "md thread takes 100% of the CPU" that Joël is > > reporting? > > > > Yes, in another e-mail I posted the top output with md3_raid5 at 100%. > This seems too similar to Joël's situation for them not to be correlated, and it shows that iscsi is not a necessary component of the failure. The attached patch allows the debug statements in MD to be enabled via sysfs. Joël, since it is easier for you to reproduce can you capture the kernel log output after the raid thread goes into the spin? It will help if you have CONFIG_PRINTK_TIME=y set in your kernel configuration. After the failure run: echo 1 > /sys/block/md_d0/md/debug_print_enable; sleep 5; echo 0 > /sys/block/md_d0/md/debug_print_enable ...to enable the print messages for a few seconds. Please send the output in a private message if it proves too big for the mailing list. raid5-debug-print-enable.patch Description: Binary data
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c |1 +
drivers/ata/libata-core.c | 39 ---
drivers/ata/pata_hpt37x.c | 49 +--
drivers/ata/pata_serverworks.c | 11 -
include/linux/ata.h| 11 +
include/linux/libata.h |1 +
6 files changed, 84 insertions(+), 28 deletions(-)
Alan Cox (4):
pata_serverworks: Fix problem with some drive combinations
ata_piix: Add additional PCI identifier for 40 wire short cable
pata_hpt37x: Fix outstanding bug reports on the HPT374 and 37x cable
detect
libata: handle broken cable reporting
Geert Uytterhoeven (1):
libata and bogus LBA48 drives
Kristen Carlson Accardi (1):
libata: Don't disable dipm with SET FEATURES
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a4b2cb2..f08cca2 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -621,6 +621,7 @@ struct ich_laptop {
static const struct ich_laptop ich_laptop[] = {
/* devid, subvendor, subdev */
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
+ { 0x27DF, 0x1025, 0x0102 }, /* ICH7 on Acer 5602aWLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
{ 0x27DF, 0x103C, 0x30A1 }, /* ICH7 on HP Compaq nc2400 */
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 164c7d9..ec3ce12 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -676,10 +676,11 @@ static int ata_dev_set_dipm(struct ata_device *dev, enum
link_pm policy)
if (rc)
return rc;
- /* disable DIPM */
- if (ata_dev_enabled(dev) && (dev->flags & ATA_DFLAG_DIPM))
- err_mask = ata_dev_set_feature(dev,
- SETFEATURES_SATA_DISABLE, SATA_DIPM);
+ /*
+* we don't have to disable DIPM since IPM flags
+* disallow transitions to SLUMBER, which effectively
+* disable DIPM if it does not support PARTIAL
+*/
break;
case NOT_AVAILABLE:
case MAX_PERFORMANCE:
@@ -689,10 +690,11 @@ static int ata_dev_set_dipm(struct ata_device *dev, enum
link_pm policy)
if (rc)
return rc;
- /* disable DIPM */
- if (ata_dev_enabled(dev) && (dev->flags & ATA_DFLAG_DIPM))
- err_mask = ata_dev_set_feature(dev,
- SETFEATURES_SATA_DISABLE, SATA_DIPM);
+ /*
+* we don't have to disable DIPM since IPM flags
+* disallow all transitions which effectively
+* disable DIPM anyway.
+*/
break;
}
@@ -4239,6 +4241,10 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
{ "ST340823A", NULL, ATA_HORKAGE_HPA_SIZE, },
{ "ST320413A", NULL, ATA_HORKAGE_HPA_SIZE, },
+ /* Devices which get the IVB wrong */
+ { "QUANTUM FIREBALLlct10 05", "A03.0900", ATA_HORKAGE_IVB, },
+ { "TSSTcorp CDDVDW SH-S202J", "SB00", ATA_HORKAGE_IVB, },
+
/* End Marker */
{ }
};
@@ -4300,6 +4306,21 @@ static int ata_dma_blacklisted(const struct ata_device
*dev)
}
/**
+ * ata_is_40wire - check drive side detection
+ * @dev: device
+ *
+ * Perform drive side detection decoding, allowing for device vendors
+ * who can't follow the documentation.
+ */
+
+static int ata_is_40wire(struct ata_device *dev)
+{
+ if (dev->horkage & ATA_HORKAGE_IVB)
+ return ata_drive_40wire_relaxed(dev->id);
+ return ata_drive_40wire(dev->id);
+}
+
+/**
* ata_dev_xfermask - Compute supported xfermask of the given device
* @dev: Device to compute xfermask for
*
@@ -4368,7 +4389,7 @@ static void ata_dev_xfermask(struct ata_device *dev)
if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA))
/* UDMA/44 or higher would be available */
if ((ap->cbl == ATA_CBL_PATA40) ||
- (ata_drive_40wire(dev->id) &&
+ (ata_is_40wire(dev) &&
(ap->cbl == ATA_CBL_PATA_UNK ||
ap->cbl == ATA_CBL_PATA80))) {
ata_dev_printk(dev, KERN_WARNING,
diff --git a/drivers/ata/pata_hpt37x.c b/drivers/ata/pata_hpt37x.c
index e61cb1f..3816b86 100644
--- a/drivers/ata/pata_hpt37x.c
+++ b/drivers/ata/pata_hpt37x.c
@@ -295,7 +295,7 @@ static unsigned long hpt370_filter(struct ata_device *adev,
unsigned long mask)
static unsigned
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/82596.c |3 ++-
drivers/net/phy/marvell.c| 23 ++-
drivers/net/phy/phy_device.c |2 +-
drivers/net/sunhme.c |4 ++--
4 files changed, 23 insertions(+), 9 deletions(-)
David Miller (1):
SUNHME: Fix missing NETIF_F_VLAN_CHALLENGED on PCI happy meals
Evgeniy Dushistov (1):
82596: free nonexistent resource fix
Olof Johansson (2):
phylib: Add ID for Marvell 88E1240
phylib: Silence driver registration
diff --git a/drivers/net/82596.c b/drivers/net/82596.c
index bb30d5b..2797da7 100644
--- a/drivers/net/82596.c
+++ b/drivers/net/82596.c
@@ -1192,6 +1192,8 @@ struct net_device * __init i82596_probe(int unit)
goto out;
}
+ dev->base_addr = ioaddr;
+
for (i = 0; i < 8; i++) {
eth_addr[i] = inb(ioaddr + 8 + i);
checksum += eth_addr[i];
@@ -1209,7 +1211,6 @@ struct net_device * __init i82596_probe(int unit)
goto out1;
}
- dev->base_addr = ioaddr;
dev->irq = 10;
}
#endif
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index d2ede5f..035fd41 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -265,7 +265,7 @@ static struct phy_driver marvell_drivers[] = {
.read_status = _read_status,
.ack_interrupt = _ack_interrupt,
.config_intr = _config_intr,
- .driver = {.owner = THIS_MODULE,},
+ .driver = { .owner = THIS_MODULE },
},
{
.phy_id = 0x01410c90,
@@ -278,7 +278,7 @@ static struct phy_driver marvell_drivers[] = {
.read_status = _read_status,
.ack_interrupt = _ack_interrupt,
.config_intr = _config_intr,
- .driver = {.owner = THIS_MODULE,},
+ .driver = { .owner = THIS_MODULE },
},
{
.phy_id = 0x01410cc0,
@@ -291,7 +291,7 @@ static struct phy_driver marvell_drivers[] = {
.read_status = _read_status,
.ack_interrupt = _ack_interrupt,
.config_intr = _config_intr,
- .driver = {.owner = THIS_MODULE,},
+ .driver = { .owner = THIS_MODULE },
},
{
.phy_id = 0x01410cd0,
@@ -304,8 +304,21 @@ static struct phy_driver marvell_drivers[] = {
.read_status = _read_status,
.ack_interrupt = _ack_interrupt,
.config_intr = _config_intr,
- .driver = {.owner = THIS_MODULE,},
- }
+ .driver = { .owner = THIS_MODULE },
+ },
+ {
+ .phy_id = 0x01410e30,
+ .phy_id_mask = 0xfff0,
+ .name = "Marvell 88E1240",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = _config_init,
+ .config_aneg = _config_aneg,
+ .read_status = _read_status,
+ .ack_interrupt = _ack_interrupt,
+ .config_intr = _config_intr,
+ .driver = { .owner = THIS_MODULE },
+ },
};
static int __init marvell_init(void)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index c046121..f6e4848 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -706,7 +706,7 @@ int phy_driver_register(struct phy_driver *new_driver)
return retval;
}
- pr_info("%s: Registered new driver\n", new_driver->name);
+ pr_debug("%s: Registered new driver\n", new_driver->name);
return 0;
}
diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c
index 120c8af..c20a3bd 100644
--- a/drivers/net/sunhme.c
+++ b/drivers/net/sunhme.c
@@ -3143,8 +3143,8 @@ static int __devinit happy_meal_pci_probe(struct pci_dev
*pdev,
dev->irq = pdev->irq;
dev->dma = 0;
- /* Happy Meal can do it all... */
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ /* Happy Meal can do it all... except VLAN. */
+ dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_VLAN_CHALLENGED;
#if defined(CONFIG_SBUS) && defined(CONFIG_PCI)
/* Hook up PCI register/dma accessors. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: writeout stalls in current -git
On Fri, 2 Nov 2007 18:33:29 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote: > On Fri, Nov 02, 2007 at 11:15:32AM +0100, Peter Zijlstra wrote: > > On Fri, 2007-11-02 at 10:21 +0800, Fengguang Wu wrote: > > > > > Interestingly, no background_writeout() appears, but only > > > balance_dirty_pages() and wb_kupdate. Obviously wb_kupdate won't > > > block the process. > > > > Yeah, the background threshold is not (yet) scaled. So it can happen > > that the bdi_dirty limit is below the background limit. > > > > I'm curious though as to these stalls, though, I can't seem to think of > > what goes wrong.. esp since most writeback seems to happen from pdflush. > > Me confused too. The new debug patch will confirm whether emerge is > waiting in balance_dirty_pages(). > > > (or I'm totally misreading it - quite a possible as I'm still recovering > > from a serious cold and not all the green stuff has yet figured out its > > proper place wrt brain cells 'n stuff) > > Do take care of yourself. > > > > > I still have this patch floating around: > > I think this patch is OK for 2.6.24 :-) > > Reviewed-by: Fengguang Wu <[EMAIL PROTECTED]> I would prefer Tested-by: :( > > > > --- > > Subject: mm: speed up writeback ramp-up on clean systems > > > > We allow violation of bdi limits if there is a lot of room on the > > system. Once we hit half the total limit we start enforcing bdi limits > > and bdi ramp-up should happen. Doing it this way avoids many small > > writeouts on an otherwise idle system and should also speed up the > > ramp-up. Given the problems we're having in there I'm a bit reluctant to go tossing hastily put together and inadequately tested stuff onto the fire. And that's what this patch looks like to me. Wanna convince me otherwise? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dn_route.c momentarily exiting RCU read-side critical section
On Mon, Nov 05, 2007 at 08:12:03AM -0800, Paul E. McKenney wrote:
> > >>
> > >> > net/decnet/dn_route.c in dn_rt_cache_get_next() is as follows:
> > >> >
> > >> > static struct dn_route *dn_rt_cache_get_next(struct seq_file *seq,
> > >> > struct dn_route *rt)
> > >> > {
> > >> > struct dn_rt_cache_iter_state *s = rcu_dereference(seq->private);
> > >> >
> > >> > rt = rt->u.dst.dn_next;
> > >> > while(!rt) {
> > >> > rcu_read_unlock_bh();
> > >> > if (--s->bucket < 0)
> > >> > break;
>
> Thank you for the info! Stupid question #3: what sequence of events
> would the smp_read_barrier_depends() be defending against?
The reading of rt from the hash bucket and the dereferencing above.
We need to make sure that we see the initialised rt.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] replace "make ARCH=i386/x86_64 with make ARCH=x86"
Sam Ravnborg wrote: On Mon, Nov 05, 2007 at 01:36:42PM -0800, Roland Dreier wrote: > Like this: > $ make ARCH=foo > Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop. Seems sane, but maybe it would be worth putting in a special case check for someone using i386 or x86_64 for ARCH, and tell them to switch to x86? Will do so if my patchset gets applied. Need to redo it but that will be later this week and then I hope for a bit more feedback from the x86 guys. The patchset has looked good to me, and I believe it would be better to take this particular breakage sooner rather than later. I haven't spoken up actively mostly because I wanted to look at the user comments as they have been coming in. The issue with "make allyesconfig" concerns me, although the same situation already exists with any multiple-choice configuration. What I guess we really want is to be able to specify a few specific choices. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
On 11/5/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Mon, 5 Nov 2007, Ahmed S. Darwish wrote: > > > On Sun, Nov 04, 2007 at 12:28:48PM +, Pavel Machek wrote: > > > > > > Can we avoid string parsers in the kernel? > > > > > > > Ok, Could someone suggest a better idea please ?. > > I personally think string parsers are *much* better than the alternatives > (which basically boil down to nasty binary interfaces) > > > I thought about packing the rules in a structure and sending > > it over an ioctl() command. Is this applicable ? > > That's *MUCH* worse. > > Strings are nice. They aren't that complex, and as long as it's not a > performance-critical area, there are basically no downsides. > > Binary structures and ioctl's are *much* worse. They are totally > undebuggable with generic tools (think "echo" or "strace"), and they are a > total nightmare to parse across architectures and pointer sizes. > > So the rule should be: always use strings if at all possible and relevant. > If the data is fundamentally binary, it shouldn't be re-coded to ascii (no > real advantage), but if the data is "stringish", and there aren't big > performance issues, then keep it as strings. > Thanks a lot for such a kind advice. I'll keep that in my mind. Regards, -- Ahmed S. Darwish Homepage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 25/27] r-o-bind-mounts-track-number-of-mount-writers-make-lockdep-happy-with-r-o-bind-mounts
On Thu, 01 Nov 2007 16:09:00 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote: > With the r/o bind mount patches, we can have as many > spinlocks nested as there are CPUs on the system. > Lockdep freaks out after 8. > > So, create a new lockdep class of locks for the > mnt_writer spinlocks, and initialize each of the > cpu locks to be in a different class. > > It should shut up warnings like this, while still > allowing some of the lockdep goodness to remain: > > = > [ INFO: possible recursive locking detected ] > 2.6.23-rc6 #6 > I added your signed-off-by: to this. I wish you hadn't mucked up all those Subject:s - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pktcdvd oops
On Mon, 5 Nov 2007, Jens Axboe wrote: Hi Peter, You don't seem to have a bugzilla account, so could not reassign to you. See http://bugzilla.kernel.org/show_bug.cgi?id=9294 Problem is repeatable on my computer. It dies in __module_get() on this line: BUG_ON(module_refcount(module) == 0); I think this is because commit 7b595756ec1f49e0049a9e01a1298d53a7faaa15, which states: "Note that with this change, userland holding a sysfs node does not prevent the backing module from being unloaded." Unfortunately, I don't know how this sysfs stuff is supposed to work, and therefore don't know how to fix the problem. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] PCI patches for 2.6.24-rc1
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Mon, 5 Nov 2007 14:42:15 -0800 (PST) > > > On Mon, 5 Nov 2007, Greg KH wrote: > > > > I'm guessing that David is referring to a commit in his tree, not in > > yours yet. > > Well, I suspect that David referred to a commit that he just sent by > email. Which obviously will have a *different* commit ID once you commit > it - so it probably made sense in his tree, but not once he exported it > as an email instead of syncing with git natively. > > I also suspect that the whole series was re-ordered in email (or by you > reading/applying them in a different order). Since now the revert of the > "disable MSI" happens *before* the patch that looks like it will fix the > issue. > > So I think David also probably didn't number his patches. They were in the correct order, and I did number them. The commit with the invalid commit ID in question went in a long time ago, into 2.6.23 in fact, and as I explained in another email I rebased by net-2.6 tree before I had sent that patch in, but I forgot to update the commit log in these PCI layer changes. I was not referencing a commit ID within the PCI patch set itself. I just did a pull and verified that the commits are in the correct order. For reference the commit I meant to reference was: commit 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 Author: Michael Chan <[EMAIL PROTECTED]> Date: Thu Sep 6 12:04:29 2007 +0100 [TG3]: Workaround MSI bug on 5714/5780. A hardware bug was revealed after a recent PCI MSI patch was made to always disable legacy INTX when enabling MSI. The 5714/5780 chips will not generate MSI when INTX is disabled, causing MSI failure messages to be reported, and another patch was made to workaround the problem by disabling MSI on ServerWorks HT1000 bridge chips commonly found with the 5714. We workaround this chip bug by enabling INTX after we enable MSI and after we resume from suspend. Update version to 3.81. This problem was discovered by David Miller. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Acked-by: Andy Gospodarek <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/27] r-o-bind-mounts-elevate-write-count-for-some-ioctls
On Thu, 01 Nov 2007 16:08:47 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> Some ioctl()s can cause writes to the filesystem. Take these, and make them
> use mnt_want/drop_write() instead.
>
> We need to pass the filp one layer deeper in XFS, but somebody _just_ pulled
> it out in February because nobody was using it, so I don't feel guilty for
> adding it back.
See, when we combine this patch with Jan's
forbid-user-to-change-file-flags-on-quota-files.patch we silently add bugs
to five filesystems. Lessons:
- never ever ever do `return' from deep in the guts of a function. This
is a *classic* instance of the maintainability risks which this practice
introduces.
- this whole elevate-the-write-count-in-a-zillion-places stuff is quite
fragile.
diff -puN
fs/ext2/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
fs/ext2/ioctl.c
---
a/fs/ext2/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
+++ a/fs/ext2/ioctl.c
@@ -57,7 +57,8 @@ int ext2_ioctl (struct inode * inode, st
/* Is it quota file? Do not allow user to mess with it */
if (IS_NOQUOTA(inode)) {
mutex_unlock(>i_mutex);
- return -EPERM;
+ ret = -EPERM;
+ goto setflags_out;
}
oldflags = ei->i_flags;
diff -puN
fs/ext3/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
fs/ext3/ioctl.c
---
a/fs/ext3/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
+++ a/fs/ext3/ioctl.c
@@ -60,7 +60,8 @@ int ext3_ioctl (struct inode * inode, st
/* Is it quota file? Do not allow user to mess with it */
if (IS_NOQUOTA(inode)) {
mutex_unlock(>i_mutex);
- return -EPERM;
+ err = -EPERM;
+ goto flags_out;
}
oldflags = ei->i_flags;
diff -puN
fs/ext4/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
fs/ext4/ioctl.c
---
a/fs/ext4/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
+++ a/fs/ext4/ioctl.c
@@ -59,7 +59,8 @@ int ext4_ioctl (struct inode * inode, st
/* Is it quota file? Do not allow user to mess with it */
if (IS_NOQUOTA(inode)) {
mutex_unlock(>i_mutex);
- return -EPERM;
+ err = -EPERM;
+ goto flags_out;
}
oldflags = ei->i_flags;
diff -puN
fs/jfs/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
fs/jfs/ioctl.c
---
a/fs/jfs/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
+++ a/fs/jfs/ioctl.c
@@ -85,8 +85,10 @@ int jfs_ioctl(struct inode * inode, stru
flags &= ~JFS_DIRSYNC_FL;
/* Is it quota file? Do not allow user to mess with it */
- if (IS_NOQUOTA(inode))
- return -EPERM;
+ if (IS_NOQUOTA(inode)) {
+ err = -EPERM;
+ goto setflags_out;
+ }
jfs_get_inode_flags(jfs_inode);
oldflags = jfs_inode->mode2;
diff -puN
fs/reiserfs/ioctl.c~r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files
fs/reiserfs/ioctl.c
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] PCI patches for 2.6.24-rc1
From: Greg KH <[EMAIL PROTECTED]> Date: Mon, 5 Nov 2007 14:17:52 -0800 > On Mon, Nov 05, 2007 at 02:13:58PM -0800, Linus Torvalds wrote: > > On Mon, 5 Nov 2007, Greg KH wrote: > > > > > > They are a bunch of quirk updates from David Miller, a new config item > > > to help Jeff Garzik start to cleanup the isdn drivers and let him take > > > those patches through his tree, and a few other minor bugfixes. > > > > This one is bogus: > > > > PCI: Revert "PCI: disable MSI by default on systems with Serverworks > > HT1000 chips" > > > > This reverts commit e3008dedff4bdc96a5f67224cd3d8d12237082a0. > > > > The real bug was an INTX issue in the tg3 ethernet chip, and > > cured by commit c129d962a66c76964954a98b38586ada82cf9381 > > > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > Acked-by: Jeff Garzik <[EMAIL PROTECTED]> > > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > > It says "cured by commit c129d962a66c76964954a98b38586ada82cf9381", but no > > such commit exists. What? > > > > Did you mean commit ba698ad4b7e466cbb4a8bde6b9da8080ab06808d, and if so, > > where did that c129d.. come from? > > I'll defer to David on this one, as he sent it to me. At the time I originally wrote that patch, that was the commit ID in my net-2.6 tree, but I rebased net-2.6 before final submittion of the tg3 patch and I didn't update the commit log for this patch to match. Sorry. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] PCI patches for 2.6.24-rc1
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon, 5 Nov 2007 14:37:31 -0800 (PST)
> So let me one more say:
>
> - don't just say
>
> .. was cured by commit xyz
>
> - but add the one-liner description of the commit, something along the
>lines of
>
> .. was cured by commit xyz ("PCI: Add quirk for devices which
> disable MSI when INTX_DISABLE is set.")
>
> so that the commit messages are readable even outside git.
I agree, and I've been trying to get into the habit of
doing this even though I didn't this time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANN] Squashfs 3.3 released
Phillip Lougher wrote: > Hi, > > I'm pleased to announce another release of Squashfs. This is the 22nd > release in just over five years. Thanks Phillip. A tiny bug[fix] I always forgot to send... In fs/squashfs/inode.c, constants TASK_UNINTERRUPTIBLE and TASK_INTERRUPTIBLE are used, but they aren't sometimes defined (declared in linux/sched.h): CC [M] fs/squashfs/inode.o fs/squashfs/inode.c: In function 'squashfs_get_cached_block': fs/squashfs/inode.c:367: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/squashfs/inode.c:367: error: (Each undeclared identifier is reported only once fs/squashfs/inode.c:367: error: for each function it appears in.) fs/squashfs/inode.c:367: warning: implicit declaration of function 'schedule' fs/squashfs/inode.c:404: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function) fs/squashfs/inode.c: In function 'release_cached_fragment': fs/squashfs/inode.c:499: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/squashfs/inode.c:499: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function) fs/squashfs/inode.c: In function 'get_cached_fragment': fs/squashfs/inode.c:522: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) fs/squashfs/inode.c:559: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function) I'm not exactly sure which config option is "at blame" (this is an i486-based UP generic-hardware config), but I'm not interested to know, either. The following trivial patch fixes it once for all. --- linux-2.6.22.orig/fs/squashfs/inode.c 2007-07-12 14:57:22.0 +0400 +++ linux-2.6.22/fs/squashfs/inode.c2007-07-12 14:57:53.0 +0400 @@ -31,6 +31,7 @@ #include #include +#include #include #include "squashfs.h" It was needed for v3.2 too. Thanks. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [to-be-posted-soon] Multiple handlers per marker
* Mike Mason ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers wrote: >> * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: >>> * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: * Mike Mason ([EMAIL PROTECTED]) wrote: > Hi Mathieu, > > Are you aware of any working being done to allow multiple handlers to > be attached to a marker? Something like what kprobes allows. I've > started to look into this and don't want to duplicate efforts. > Nope, but I know we will have to address this. Something along the lines of walking an RCU list of function pointers, calling them. The only downside I see is that we will have to pass a va_list * instead of real va args. The could make the marker site a little bit bigger and will change the probe callback arguments. What do you think about these ideas ? If we can find a way to make the common case (only one probe connected) _ultra_ fast, and yet architecture independent, that would be awesome. A simple call is kind of hard to beat though.. So we may have to think about a design with : - One call at the marker site - if 1 probe is installed : - If the format string is empty, connect a probe without va args. - If the format string is not empty, connect a "stage 1" probe that takes the va args, starts/ends the va_list and calls _one_ function (let's call it "stage 2" probe), that takes va_list as parameter. - if more than 1 probe is installed : - The stage 1 probe creates the va_list and passes it to each function connected, iterated with an RCU list. What do you think ? Mathieu >>> I'm working on an implementation. >>> >> It's ready for testing. Please grab >> http://ltt.polymtl.ca/lttng/patch-2.6.24-rc1-git13-lttng-0.10-pre18.tar.bz2 >> patch name : >> markers-support-multiple-probes.patch > > This patch alone doesn't apply cleanly at all on 2.6.24-rc1-git14. Are > there other patches in this series I should apply first? > Yes, the following ones should suffice : # instrumentation menu removal add-kconfig-to-arch.patch add-arch-supports-oprofile.patch add-arch-supports-kprobes.patch move-kconfig-instrumentation-to-arch.patch # kprobes-use-mutex-for-insn-pages.patch kprobes-dont-use-kprobes-mutex-in-arch-code.patch kprobes-declare-kprobes-mutex-static.patch declare-array.patch text-edit-lock-architecture-independent-code.patch text-edit-lock-alternative-i386-and-x86_64.patch text-edit-lock-kprobes-architecture-independent.patch text-edit-lock-kprobes-i386.patch text-edit-lock-kprobes-x86_64.patch text-edit-lock-i386-standardize-debug-rodata.patch text-edit-lock-x86_64-standardize-debug-rodata.patch # immediate-values-architecture-independent-code.patch immediate-values-kconfig-embedded.patch immediate-values-move-kprobes-i386-restore-interrupt-to-kdebug-h.patch add-asm-compat-to-x86.patch immediate-values-i386-optimization.patch immediate-values-powerpc-optimization.patch immediate-values-documentation.patch # linux-kernel-markers-immediate-values.patch # markers-support-multiple-probes.patch Tell me if you still have rejects. Mathieu > Mike > >> It still need to go through patchcheck.pl and some polishing, but it >> seems to work fine for me with multiple probes (the sample marker, >> sample probe and multiple instances of my lttng probes can >> connect/disconnect without problem). >> Currently, the "connect/disconnect" and "arm/disarm" operations are >> separate. However, they could be merged. Any comment/preference on this? >> Being separate, a probe provider can wait until the very last moment >> before it activates its markers, with a minimalistic impact on the >> system, but it is not such a strong argument. >> Mathieu > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] Add and use media change notification
Linus Torvalds wrote: On Sun, 4 Nov 2007, Jeff Garzik wrote: The end to CD-ROM polling... newer SATA ATAPI hardware will emit 'asynchronous notification' events when media is changed. This adds support. I *really* didn't want to pull this. Not only is it after the -rc1 period, but I also think you pushed this ina really offensive manner, and I don't like how you and James have made this whole thing personal. You guys need to sort it out, and there is no way you can blame James for all your troubles, since I've heard the same kind of complaints about every single maintainer out there (including you) about some driver or other infrastructure issue. So I'm unhappy about pulling this. That said, I did finally decide to just pull it. Partly because the concept apparently has been in -mm for a while anyway (even if the final patch has not - but the patch itself isn't that large, I'd worry more about thngs like certain hardware simply not doing things right), but mostly because I hate it when others hold up driver features, and I decided that in this case this really is something that is better done earlier rather than later, to get exposure as soon as possible. But I really think you need to lay off James, and help him rather than make every single complaint a big flame-war! Please, Jeff? Fair enough... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 05 Nov 2007 19:00:19 +0100 > This looks like a rather expensive operation for the unlikely case > that packets will be received by a packet socket. IMO it should only > be reconstructed if actually needed, by af_packet itself. Completely agreed. We should not do this by default when %99 of the networking stack simply does not care about this. > As we discussed some time back storing the VLAN tag in the CB on > TX clashes with other users of the CB like qdiscs, so we need a > new field in the skb for this anyway. Someone will have to find a way to remove some other fields in sk_buff before I'm going to allow more space to be eaten up by this completely fringe case feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Policy on dual licensing?
> What I suppose is that people porting BSD code to Linux don't mean > closing the doors for back-porting changes. They are simply unaware > or forget about the possibility of dual licensing. Obviously, each > submitter should read Documentation/SubmittingDrivers, where it is > explicitly stated. Yet humans are prone to forgetting, so this may > seem not enough. > > What I propose is implementing a policy on accepting such code. > According to it, every time a maintainer is considering a driver > that is derived from BSD and licensed GPL-only, should request > for dual licensing before accepting the patch. If the submitter is > reluctant to do so - what can we do, it's better to have this inside > this way than not at all. However, this should minimize such cases > and, hopefully, satisfy the claims about Linux maintainers not doing > all that they could to make the world a better place. > > Best regards, > Remigiusz Modrzejewski This will result in more code in the Linux tree that has a license other than the project default. This will impose a greater and greater burden on developers who have to carefully check the license of files every time they cut and paste code from one file into another. It creates a serious risk of incorrect license notices (because someone cuts/pastes a substantial chunk of GPL-only code into a dual-licensed file without changing the license notice) and accidental copyright violations (because someone else took the cut/pasted part into a BSD-licensed project) if intimately-connected files are under different licenses. Every effort should be made to avoid this. Having a clear policy would be a good idea. I think the general policy should be that any dual-licensed file should contain a clear notice that the Linux kernel is GPL (that is the only license 'guaranteed' to cover the entire distribution) and that development may result in the file being "contaminated" by code that is not dual-licensed. Just a notice referring to a 'dual license FAQ' in Documention would be fine, of course. That file should advise developers that they should remove the dual license if they cause the file to be no longer dual-licensable due to code they've added, cut/pasted, or modified. Gratuitous removal of dual-licensing should be discouraged, but removing it should be encouraged where it's a genuine impediment to development. The example I always use is if we have a filesystem with a different license. Imagine if a new function is added to the filesystem interface. It is offered in a 'generic' version, with the expectation that filesystems will override it to provide a better-performing version. Imagine if the generic version is GPLv2-only and a filesystem in-tree is dual licensed. A developer probably cannot cut/paste the generic version as a base without breaking the dual license. If they want to keep the dual license, they have to re-implement the function. This creates an increased risk of bugs or incompatibilities. Worse, it creates a maintenance headache in that this function will need to be understood separately from other filesystems' implementation of the same function. A little imagination will allow one to imagine many ways this can cause problems. The only good way this can end is if they change the license on that file to GPL only. Possible bad ways include accidentally contaminating the apparently dual-licensed file with code that was offered by its author only under the GPL. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
