Re: [ofa-general] [PATCH 2/2] ib fmr pool: flush used clean entries
This looks like a really nice approach to me. Olaf? - R. -- 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/
Intel 945GM: 2.6.25-rc3 report (with a possible regression)
Hi, this mail is to give feedback about the 2.6.25-rc3 kernel, on an Ubuntu 7.10 system, running on a Toshiba Satellite U305. Video is a Intel 845GM, and I run 915resolution at start to make X happy with the correct widescreen resolution. A lot of data is collected here (if more is needed, tell me): http://www.dea.icai.upcomillas.es/romano/linux/info/ 1) The minor regression is that I cannot have any more a correct console. I tried a lot of combinations, but without a framebuffer, console is garbled by ubuntu splash and/or X. With the .config copied in the site above, I do not have console (a random pattern appears as I switch consoles). With intelfb framebuffer, sometime it works, sometime it doesn't work, and everytime break resume from STR. (I mean, the laptop seems to resume, but the screen is blank). I have a doubt about this: is it possible that some state is maintained across reboots? Because sometime two reboots in a row led to different results; for example, after following https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/147606 I had a nice console, but after the failed resume and a sysrq-b reboot, no console again. 2) LCD/CRT switch. It's the first time I tried it, so no idea if it ever worked. Without a CRT connected, nothing happens pressing the key combination (fn-F5), correctly. When I connected a overhead proyector (CRT), pressed fn-F5, and the LCD went off and the CRT on (ok); after that the LCD never came on again. pressing again fn-f5 two times lead to a all-off, a third time made the CRT switch on, and again. The laptop is working but the LCD stay black till the next reboot. (It is very similar to what seems to happen after resume). 3) on the nice side of things, it seems that now echo mem > /sys/power/state works (at least in X, I do not have a console to test it...). Thank you very much, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- 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 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:58:02PM +0100, Sam Ravnborg wrote: > > > > Please name the tools that are that broken that they wouldn't apply this > > patch correctly and don't claim my patch was broken (or shut up). > > It is only one or two weeks ago we ended up with a zero size file > in the kernel tree - and I do not know why. > I just wanted to make sure we did not see this happen again. Then research first what went wrong in this case. But it is not funny when you wrongly accuse me publically of sending patches that would remove files in an incorrect way. > 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: 2.6.25-rc1 xen pvops regression
Mark McLoughlin wrote:
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
}
}
else {
+ if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM))
+ goto out;
One issue with using the e820 map for this is that a Xen Dom0 will also
have this region marked as RAM in the e820 map, but will set up a fixmap
for it, allowing dmi_scan_machine() to map the region.
Would it be easier to just fake up a mapping so that window points to
the real dmi area, and mark E820 accordingly?
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: [xfs-masters] Re: filesystem corruption on xfs after 2.6.25-rc1 (bisected, powerpc related?)
Gaudenz Steinlin wrote:
> On Tue, Feb 26, 2008 at 01:13:56AM +0100, Rafael J. Wysocki wrote:
>> On Tuesday, 26 of February 2008, Christoph Hellwig wrote:
>>> On Tue, Feb 26, 2008 at 12:52:56AM +0100, Rafael J. Wysocki wrote:
> I'm not suggesting a partial revert; I just wonder which part of the
> change is causing the problem, as part of the debugging process.
>
> I debuged this a bit further by testing the 4 changed functions
> individually. The problem only occurs with the new version of
> xfs_lowbit64.
FWIW, Dave & I did some testing/debugging on 32-bit powerpc, and it is
indeed only xfs_lowbit64 which is doing the wrong thing on that arch,
because generic find_next_bit is doing the wrong thing on big-endian
32-bit systems, for sizes > 32 bits, near as I can tell.
Rather than reverting it all, I think just changing xfs_lowbit64 back to:
int
xfs_lowbit64(
__uint64_t v)
{
__uint32_t w = (__uint32_t)v;
int n = 0;
if (w) {/* lower bits */
n = ffs(w);
} else {/* upper bits */
w = (__uint32_t)(v >> 32);
if (w && (n = ffs(w)))
n += 32;
}
return n - 1;
}
for now should fix it (this is essentially just ffs64())
-Eric
--
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: Is there a memory block device?
On Tue, 26 Feb 2008, rzryyvzy wrote: > I know that tmpfs is a memmory filesystem. Is there a possibility to > create also a memory block device? > Is there a possibility to create for example a 1 GB memory block device > (from the RAM)? There are the /dev/ram* devices, created through kernel config CONFIG_BLK_DEV_RAM (RAM disk support), kernel module rd.ko But I'm not sure how to configure their size besides setting the kernel config option, it's a long time ago that I used them last. c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) -- 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] x86: vSMP selection in config
On Sun, Feb 24, 2008 at 10:43:49PM -0800, Yinghai Lu wrote: > > find out vSMP setting is going away in config after make oldconfig > > vSMP need to PARAVIRT and PCI. > so move PARAVIRT out of if PARAVIRT_GUEST, and make vSMP select PCI instead of > depends on PCI > > after patch vSMP could stick there. I'm certain that we have hit a Kconfig bug / limitation here and the patch below is just a workaround for that issue. I tracked it down to a minimal case and hope Roman can provide either an explanation or a fix. IMO VSMP can wait until this is resolved properly and we should not apply this patch. 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/
Re: [RFC] mmiotrace full patch, preview 1
On Mon, 25 Feb 2008 14:49:22 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > Please feed the diff through scritps/checkpatch.pl and consider addressing > the things which it finds. I checked that, but I didn't think any of them were worth fixing. And since this is a work in progress and a in a state which I do not want committed yet, I did not sign this patch. mmio-mod.c is still a mess. > WARNING: Use of volatile is usually wrong: see > Documentation/volatile-considered-harmful.txt > #1097: FILE: arch/x86/mm/mmio-mod.c:437: > +void iounmap_trace(volatile void __iomem *addr) I believe the 'volatile' belongs here, it is also in the declaration of iounmap() in arch/x86/mm/ioremap.c. > WARNING: externs should be avoided in .c files > #1766: FILE: arch/x86/mm/testmmiotrace.c:7: > +extern void __iomem *ioremap_nocache_trace(unsigned long offset, > > WARNING: Use of volatile is usually wrong: see > Documentation/volatile-considered-harmful.txt > #1768: FILE: arch/x86/mm/testmmiotrace.c:9: > +extern void iounmap_trace(volatile void __iomem *addr); > > WARNING: externs should be avoided in .c files > #1768: FILE: arch/x86/mm/testmmiotrace.c:9: > +extern void iounmap_trace(volatile void __iomem *addr); These are all in testmmiotrace.c which calls the traced ioremap functions directly. These direct calls will go away and it will call the normal ioremap functions. > WARNING: Use of volatile is usually wrong: see > Documentation/volatile-considered-harmful.txt > #1790: FILE: arch/x86/mm/testmmiotrace.c:31: > + volatile unsigned int v; Since testmmiotrace does not use v for anything other than return value of ioread8/16/32(), I wanted to prevent the compiler from optimizing it away. Now thinking it again, ioread*() must guarantee that the read is always executed. I'll remove v altogether. Patch for the other issues you mentioned is brewing. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- 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.25-rc2 regression in rt61pci wireless driver
On Tue, Feb 26, 2008 at 07:11:39PM +, Chris Clayton wrote: > Sorry, but that's not the case. I find the same results as without the > patches. With the parameter set to 'pid', the network connection fails very > quickly, but with it set to 'simple' I can ping and ftp files to and from my > laptop as much as I like and the connection stays up. In fact, if anything > the patches seem to have made the network even more fragile, in that it fails > almost instantly once I start some network activity ( < 10 pings). > > I'm sure this is not the hardware - it works perfectly with Windows XP, with > 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the > in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's > ieee80211_default_rc_algo parameter set to 'simple'. At last! Vindication for insisting that we keep 'simple' around! Bwahahaha! :-) So, am I to understand that 'pid' works find for you with rtl8180? If so, then I wonder if Stefano and Ivo can help us figure-out what kind of problem is sensitive to both driver _and_ rate control algorithm? Thanks, John -- John W. Linville [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: [2.6 patch v2] cris: proper defconfig setup
> > Please name the tools that are that broken that they wouldn't apply this > patch correctly and don't claim my patch was broken (or shut up). It is only one or two weeks ago we ended up with a zero size file in the kernel tree - and I do not know why. I just wanted to make sure we did not see this happen again. 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/
[2.6 patch] m32r: use KBUILD_DEFCONFIG
With using KBUILD_DEFCONFIG we don't have to ship a second copy of m32700ut.smp_defconfig Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/m32r/Makefile |2 arch/m32r/defconfig | 863 2 files changed, 2 insertions(+), 863 deletions(-) c1797789816e8d79133d63da3578705f47cedbd3 diff --git a/arch/m32r/Makefile b/arch/m32r/Makefile index 4072a07..469766b 100644 --- a/arch/m32r/Makefile +++ b/arch/m32r/Makefile @@ -5,6 +5,8 @@ # architecture-specific flags and dependencies. # +KBUILD_DEFCONFIG := m32700ut.smp_defconfig + LDFLAGS:= OBJCOPYFLAGS := -O binary -R .note -R .comment -S LDFLAGS_vmlinux:= diff --git a/arch/m32r/defconfig b/arch/m32r/defconfig deleted file mode 100644 index af3b981..000 --- a/arch/m32r/defconfig +++ /dev/null @@ -1,863 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc1 -# Wed Aug 1 17:22:35 2007 -# -CONFIG_M32R=y -CONFIG_GENERIC_ISA_DMA=y -CONFIG_ZONE_DMA=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_NO_IOPORT=y -CONFIG_NO_DMA=y -CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_LOCK_KERNEL=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION="" -CONFIG_LOCALVERSION_AUTO=y -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -CONFIG_SYSVIPC_SYSCTL=y -# CONFIG_POSIX_MQUEUE is not set -CONFIG_BSD_PROCESS_ACCT=y -# CONFIG_BSD_PROCESS_ACCT_V3 is not set -# CONFIG_TASKSTATS is not set -# CONFIG_USER_NS is not set -# CONFIG_AUDIT is not set -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=15 -# CONFIG_CPUSETS is not set -CONFIG_SYSFS_DEPRECATED=y -# CONFIG_RELAY is not set -# CONFIG_BLK_DEV_INITRD is not set -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set -CONFIG_SYSCTL=y -CONFIG_EMBEDDED=y -CONFIG_SYSCTL_SYSCALL=y -# CONFIG_KALLSYMS is not set -CONFIG_HOTPLUG=y -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_ELF_CORE=y -CONFIG_BASE_FULL=y -# CONFIG_FUTEX is not set -CONFIG_ANON_INODES=y -# CONFIG_EPOLL is not set -CONFIG_SIGNALFD=y -CONFIG_TIMERFD=y -CONFIG_EVENTFD=y -CONFIG_SHMEM=y -CONFIG_VM_EVENT_COUNTERS=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set -# CONFIG_SLOB is not set -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -# CONFIG_MODULE_FORCE_UNLOAD is not set -# CONFIG_MODVERSIONS is not set -# CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y -CONFIG_STOP_MACHINE=y -CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set -# CONFIG_LSF is not set -# CONFIG_BLK_DEV_BSG is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -# CONFIG_IOSCHED_AS is not set -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_DEFAULT_AS is not set -# CONFIG_DEFAULT_DEADLINE is not set -CONFIG_DEFAULT_CFQ=y -# CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED="cfq" - -# -# Processor type and features -# -# CONFIG_PLAT_MAPPI is not set -# CONFIG_PLAT_USRV is not set -CONFIG_PLAT_M32700UT=y -# CONFIG_PLAT_OPSPUT is not set -# CONFIG_PLAT_OAKS32R is not set -# CONFIG_PLAT_MAPPI2 is not set -# CONFIG_PLAT_MAPPI3 is not set -# CONFIG_PLAT_M32104UT is not set -CONFIG_CHIP_M32700=y -# CONFIG_CHIP_M32102 is not set -# CONFIG_CHIP_M32104 is not set -# CONFIG_CHIP_VDEC2 is not set -# CONFIG_CHIP_OPSP is not set -CONFIG_MMU=y -CONFIG_TLB_ENTRIES=32 -CONFIG_ISA_M32R2=y -CONFIG_ISA_DSP_LEVEL2=y -CONFIG_ISA_DUAL_ISSUE=y -CONFIG_BUS_CLOCK=5000 -CONFIG_TIMER_DIVIDE=128 -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_MEMORY_START=0x0800 -CONFIG_MEMORY_SIZE=0x0100 -CONFIG_NOHIGHMEM=y -CONFIG_ARCH_DISCONTIGMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -# CONFIG_FLATMEM_MANUAL is not set -CONFIG_DISCONTIGMEM_MANUAL=y -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_DISCONTIGMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -CONFIG_NEED_MULTIPLE_NODES=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -CONFIG_IRAM_START=0x00f0 -CONFIG_IRAM_SIZE=0x0008 -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -CONFIG_PREEMPT=y -CONFIG_SMP=y -# CONFIG_CHIP_M32700_TS1 is not set -CONFIG_NR_CPUS=2 -CONFIG_NODES_SHIFT=1 - -# -# Bus options (PCI, PCMCIA, EISA, MCA, ISA) -# -# CONFIG_ARCH_SUPPORTS_MSI is not set -# CONFIG_ISA is not set - -# -# PCCARD (PCMCIA/CardBus) support -# -# CONFIG_PCCARD is not set - -# -# Executable file formats -# -CONFIG_BINFMT_ELF=y -# CONFIG_BINFMT_MISC is not set - -# -# Networking -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -CONFIG_XFRM=y -# CONFIG_XFRM_USER is
[2.6 patch] m68k: use KBUILD_DEFCONFIG
The default defconfig should be one from arch/m68k/configs/ arch/m68k/defconfig was not exactly identical to amiga_defconfig but also considering how long they have been without any update that doesn't seem to have been on purpose. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/m68k/Makefile |2 arch/m68k/defconfig | 657 2 files changed, 2 insertions(+), 657 deletions(-) f52a66f85069cc79c30b0c9520713bbba6cfc20d diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile index 2cba605..b15173f 100644 --- a/arch/m68k/Makefile +++ b/arch/m68k/Makefile @@ -13,6 +13,8 @@ # Copyright (C) 1994 by Hamish Macdonald # +KBUILD_DEFCONFIG := amiga_defconfig + # override top level makefile AS += -m68020 LDFLAGS := -m m68kelf diff --git a/arch/m68k/defconfig b/arch/m68k/defconfig deleted file mode 100644 index 7d935e4..000 --- a/arch/m68k/defconfig +++ /dev/null @@ -1,657 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.12-rc6-m68k -# Tue Jun 7 20:34:17 2005 -# -CONFIG_M68K=y -CONFIG_MMU=y -CONFIG_UID16=y -CONFIG_RWSEM_GENERIC_SPINLOCK=y -CONFIG_GENERIC_CALIBRATE_DELAY=y - -# -# Code maturity level options -# -CONFIG_EXPERIMENTAL=y -CONFIG_CLEAN_COMPILE=y -CONFIG_BROKEN_ON_SMP=y -CONFIG_INIT_ENV_ARG_LIMIT=32 - -# -# General setup -# -CONFIG_LOCALVERSION="" -CONFIG_SWAP=y -CONFIG_SYSVIPC=y -# CONFIG_POSIX_MQUEUE is not set -# CONFIG_BSD_PROCESS_ACCT is not set -CONFIG_SYSCTL=y -# CONFIG_AUDIT is not set -# CONFIG_HOTPLUG is not set -CONFIG_KOBJECT_UEVENT=y -# CONFIG_IKCONFIG is not set -# CONFIG_EMBEDDED is not set -CONFIG_KALLSYMS=y -# CONFIG_KALLSYMS_EXTRA_PASS is not set -CONFIG_PRINTK=y -CONFIG_BUG=y -CONFIG_BASE_FULL=y -CONFIG_FUTEX=y -CONFIG_EPOLL=y -CONFIG_SHMEM=y -CONFIG_CC_ALIGN_FUNCTIONS=0 -CONFIG_CC_ALIGN_LABELS=0 -CONFIG_CC_ALIGN_LOOPS=0 -CONFIG_CC_ALIGN_JUMPS=0 -# CONFIG_TINY_SHMEM is not set -CONFIG_BASE_SMALL=0 - -# -# Loadable module support -# -# CONFIG_MODULES is not set - -# -# Platform dependent setup -# -# CONFIG_SUN3 is not set -CONFIG_AMIGA=y -# CONFIG_ATARI is not set -# CONFIG_MAC is not set -# CONFIG_APOLLO is not set -# CONFIG_VME is not set -# CONFIG_HP300 is not set -# CONFIG_SUN3X is not set -# CONFIG_Q40 is not set - -# -# Processor type -# -CONFIG_M68020=y -CONFIG_M68030=y -CONFIG_M68040=y -# CONFIG_M68060 is not set -CONFIG_MMU_MOTOROLA=y -# CONFIG_M68KFPU_EMU is not set -# CONFIG_ADVANCED is not set - -# -# General setup -# -CONFIG_BINFMT_ELF=y -CONFIG_BINFMT_AOUT=y -# CONFIG_BINFMT_MISC is not set -CONFIG_ZORRO=y -# CONFIG_AMIGA_PCMCIA is not set -# CONFIG_HEARTBEAT is not set -CONFIG_PROC_HARDWARE=y -# CONFIG_ZORRO_NAMES is not set - -# -# Device Drivers -# - -# -# Generic Driver Options -# -CONFIG_STANDALONE=y -CONFIG_PREVENT_FIRMWARE_BUILD=y -# CONFIG_FW_LOADER is not set - -# -# Memory Technology Devices (MTD) -# -# CONFIG_MTD is not set - -# -# Parallel port support -# -# CONFIG_PARPORT is not set - -# -# Plug and Play support -# - -# -# Block devices -# -CONFIG_AMIGA_FLOPPY=y -# CONFIG_AMIGA_Z2RAM is not set -# CONFIG_BLK_DEV_COW_COMMON is not set -# CONFIG_BLK_DEV_LOOP is not set -# CONFIG_BLK_DEV_NBD is not set -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=16 -CONFIG_BLK_DEV_RAM_SIZE=4096 -CONFIG_BLK_DEV_INITRD=y -CONFIG_INITRAMFS_SOURCE="" -CONFIG_CDROM_PKTCDVD=y -CONFIG_CDROM_PKTCDVD_BUFFERS=8 -# CONFIG_CDROM_PKTCDVD_WCACHE is not set - -# -# IO Schedulers -# -CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y -CONFIG_IOSCHED_DEADLINE=y -CONFIG_IOSCHED_CFQ=y -# CONFIG_ATA_OVER_ETH is not set - -# -# ATA/ATAPI/MFM/RLL support -# -# CONFIG_IDE is not set - -# -# SCSI device support -# -CONFIG_SCSI=y -CONFIG_SCSI_PROC_FS=y - -# -# SCSI support type (disk, tape, CD-ROM) -# -CONFIG_BLK_DEV_SD=y -CONFIG_CHR_DEV_ST=y -# CONFIG_CHR_DEV_OSST is not set -CONFIG_BLK_DEV_SR=y -# CONFIG_BLK_DEV_SR_VENDOR is not set -# CONFIG_CHR_DEV_SG is not set - -# -# Some SCSI devices (e.g. CD jukebox) support multiple LUNs -# -# CONFIG_SCSI_MULTI_LUN is not set -CONFIG_SCSI_CONSTANTS=y -# CONFIG_SCSI_LOGGING is not set - -# -# SCSI Transport Attributes -# -# CONFIG_SCSI_SPI_ATTRS is not set -# CONFIG_SCSI_FC_ATTRS is not set -# CONFIG_SCSI_ISCSI_ATTRS is not set - -# -# SCSI low-level drivers -# -# CONFIG_SCSI_SATA is not set -# CONFIG_SCSI_DEBUG is not set -CONFIG_A3000_SCSI=y -CONFIG_A2091_SCSI=y -CONFIG_GVP11_SCSI=y -# CONFIG_CYBERSTORM_SCSI is not set -# CONFIG_CYBERSTORMII_SCSI is not set -# CONFIG_BLZ2060_SCSI is not set -# CONFIG_BLZ1230_SCSI is not set -# CONFIG_FASTLANE_SCSI is not set -# CONFIG_OKTAGON_SCSI is not set - -# -# Multi-device support (RAID and LVM) -# -# CONFIG_MD is not set - -# -# Fusion MPT device support -# - -# -# IEEE 1394 (FireWire) support -# - -# -# I2O device support -# - -# -# Networking support -# -CONFIG_NET=y - -# -# Networking options -# -CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set -CONFIG_UNIX=y -# CONFIG_NET_KEY is not set -CONFIG_INET=y -# CONFIG_
[2.6 patch] mips: use KBUILD_DEFCONFIG
With KBUILD_DEFCONFIG we don't have to ship a second copy of ip22_defconfig Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- arch/mips/Makefile |2 arch/mips/defconfig | 1158 2 files changed, 2 insertions(+), 1158 deletions(-) 57da2fa4b7e8c035c8317e8796ca6d2ea17c1d1f diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 001c017..93ef27b 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -12,6 +12,8 @@ # for "archclean" cleaning up for this architecture. # +KBUILD_DEFCONFIG := ip22_defconfig + cflags-y := # diff --git a/arch/mips/defconfig b/arch/mips/defconfig deleted file mode 100644 index 4f5e56c..000 --- a/arch/mips/defconfig +++ /dev/null @@ -1,1158 +0,0 @@ -# -# Automatically generated make config: don't edit -# Linux kernel version: 2.6.23-rc2 -# Tue Aug 7 12:39:49 2007 -# -CONFIG_MIPS=y - -# -# Machine selection -# -CONFIG_ZONE_DMA=y -# CONFIG_MACH_ALCHEMY is not set -# CONFIG_BASLER_EXCITE is not set -# CONFIG_MIPS_COBALT is not set -# CONFIG_MACH_DECSTATION is not set -# CONFIG_MACH_JAZZ is not set -# CONFIG_LEMOTE_FULONG is not set -# CONFIG_MIPS_ATLAS is not set -# CONFIG_MIPS_MALTA is not set -# CONFIG_MIPS_SEAD is not set -# CONFIG_MIPS_SIM is not set -# CONFIG_MARKEINS is not set -# CONFIG_MACH_VR41XX is not set -# CONFIG_PNX8550_JBS is not set -# CONFIG_PNX8550_STB810 is not set -# CONFIG_PMC_MSP is not set -# CONFIG_PMC_YOSEMITE is not set -CONFIG_SGI_IP22=y -# CONFIG_SGI_IP27 is not set -# CONFIG_SGI_IP32 is not set -# CONFIG_SIBYTE_CRHINE is not set -# CONFIG_SIBYTE_CARMEL is not set -# CONFIG_SIBYTE_CRHONE is not set -# CONFIG_SIBYTE_RHONE is not set -# CONFIG_SIBYTE_SWARM is not set -# CONFIG_SIBYTE_LITTLESUR is not set -# CONFIG_SIBYTE_SENTOSA is not set -# CONFIG_SIBYTE_BIGSUR is not set -# CONFIG_SNI_RM is not set -# CONFIG_TOSHIBA_JMR3927 is not set -# CONFIG_TOSHIBA_RBTX4927 is not set -# CONFIG_TOSHIBA_RBTX4938 is not set -# CONFIG_WR_PPMC is not set -CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set -CONFIG_GENERIC_FIND_NEXT_BIT=y -CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_GENERIC_TIME=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y -# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set -CONFIG_ARC=y -CONFIG_DMA_NONCOHERENT=y -CONFIG_DMA_NEED_PCI_MAP_STATE=y -CONFIG_EARLY_PRINTK=y -CONFIG_SYS_HAS_EARLY_PRINTK=y -# CONFIG_NO_IOPORT is not set -CONFIG_GENERIC_ISA_DMA_SUPPORT_BROKEN=y -CONFIG_CPU_BIG_ENDIAN=y -# CONFIG_CPU_LITTLE_ENDIAN is not set -CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y -CONFIG_IRQ_CPU=y -CONFIG_SWAP_IO_SPACE=y -CONFIG_ARC32=y -CONFIG_BOOT_ELF32=y -CONFIG_MIPS_L1_CACHE_SHIFT=5 -CONFIG_ARC_CONSOLE=y -CONFIG_ARC_PROMLIB=y - -# -# CPU selection -# -# CONFIG_CPU_LOONGSON2 is not set -# CONFIG_CPU_MIPS32_R1 is not set -# CONFIG_CPU_MIPS32_R2 is not set -# CONFIG_CPU_MIPS64_R1 is not set -# CONFIG_CPU_MIPS64_R2 is not set -# CONFIG_CPU_R3000 is not set -# CONFIG_CPU_TX39XX is not set -# CONFIG_CPU_VR41XX is not set -# CONFIG_CPU_R4300 is not set -# CONFIG_CPU_R4X00 is not set -# CONFIG_CPU_TX49XX is not set -CONFIG_CPU_R5000=y -# CONFIG_CPU_R5432 is not set -# CONFIG_CPU_R6000 is not set -# CONFIG_CPU_NEVADA is not set -# CONFIG_CPU_R8000 is not set -# CONFIG_CPU_R1 is not set -# CONFIG_CPU_RM7000 is not set -# CONFIG_CPU_RM9000 is not set -# CONFIG_CPU_SB1 is not set -CONFIG_SYS_HAS_CPU_R4X00=y -CONFIG_SYS_HAS_CPU_R5000=y -CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y -CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y - -# -# Kernel type -# -CONFIG_32BIT=y -# CONFIG_64BIT is not set -CONFIG_PAGE_SIZE_4KB=y -# CONFIG_PAGE_SIZE_8KB is not set -# CONFIG_PAGE_SIZE_16KB is not set -# CONFIG_PAGE_SIZE_64KB is not set -CONFIG_BOARD_SCACHE=y -CONFIG_IP22_CPU_SCACHE=y -CONFIG_MIPS_MT_DISABLED=y -# CONFIG_MIPS_MT_SMP is not set -# CONFIG_MIPS_MT_SMTC is not set -CONFIG_CPU_HAS_LLSC=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_GENERIC_HARDIRQS=y -CONFIG_GENERIC_IRQ_PROBE=y -CONFIG_ARCH_FLATMEM_ENABLE=y -CONFIG_SELECT_MEMORY_MODEL=y -CONFIG_FLATMEM_MANUAL=y -# CONFIG_DISCONTIGMEM_MANUAL is not set -# CONFIG_SPARSEMEM_MANUAL is not set -CONFIG_FLATMEM=y -CONFIG_FLAT_NODE_MEM_MAP=y -# CONFIG_SPARSEMEM_STATIC is not set -CONFIG_SPLIT_PTLOCK_CPUS=4 -# CONFIG_RESOURCES_64BIT is not set -CONFIG_ZONE_DMA_FLAG=1 -CONFIG_BOUNCE=y -CONFIG_VIRT_TO_BUS=y -# CONFIG_HZ_48 is not set -# CONFIG_HZ_100 is not set -# CONFIG_HZ_128 is not set -# CONFIG_HZ_250 is not set -# CONFIG_HZ_256 is not set -CONFIG_HZ_1000=y -# CONFIG_HZ_1024 is not set -CONFIG_SYS_SUPPORTS_ARBIT_HZ=y -CONFIG_HZ=1000 -# CONFIG_PREEMPT_NONE is not set -CONFIG_PREEMPT_VOLUNTARY=y -# CONFIG_PREEMPT is not set -# CONFIG_KEXEC is not set -CONFIG_SECCOMP=y -CONFIG_LOCKDEP_SUPPORT=y -CONFIG_STACKTRACE_SUPPORT=y -CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" - -# -# General setup -# -CONFIG_EXPERIMENTAL=y -CONFIG_BROKEN_ON_SMP=y
Re: [2.6 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 08:44:53PM +0100, Sam Ravnborg wrote: > On Tue, Feb 26, 2008 at 07:04:02PM +0100, Jesper Nilsson wrote: > > On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: > > > This patch moves the cris defconfigs to arch/cris/configs/ where they > > > belong. > > > > > > As a side effect they can now be used directly through e.g. > > > make ARCH=cris artpec_3_defconfig > > > > > > The default defconfig is set through KBUILD_DEFCONFIG. > > > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > > > Patch updated after I discovered an additional defconfig in > > > arch/cris/arch-v10/defconfig > > > > That could probably have been nuked, it's ancient. > > > > I'll put this in my queue. Thanks! > If you blindly apply this patch then make sure you do not end > up with zero size files. They are disliked by the kerne and > make distclean will delete them - and git becomes unhappy. At least GNU patch will correctly remove the files with my patch. Please name the tools that are that broken that they wouldn't apply this patch correctly and don't claim my patch was broken (or shut up). > 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/
[RFC/PATCH] ipg: add jumbo frame support kconfig option
[ Sorry for the duplicate. I typoed Francois' email address. ]
From: Pekka Enberg <[EMAIL PROTECTED]>
Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and
fix compilation errors.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |8
drivers/net/ipg.c | 21 ++---
drivers/net/ipg.h | 11 ++-
3 files changed, 24 insertions(+), 16 deletions(-)
Index: linux-2.6/drivers/net/Kconfig
===
--- linux-2.6.orig/drivers/net/Kconfig
+++ linux-2.6/drivers/net/Kconfig
@@ -2029,6 +2029,14 @@ config IP1000
To compile this driver as a module, choose M here: the module
will be called ipg. This is recommended.
+config IP1000_JUMBO_FRAME
+ bool "Support for jumbo frames (EXPERIMENTAL)"
+ depends on IP1000 && EXPERIMENTAL
+ help
+ This option enables jumbo frame support for the IP1000 driver.
+
+ If in doubt, say N.
+
config IGB
tristate "Intel(R) 82575 PCI-Express Gigabit Ethernet support"
depends on PCI
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -42,7 +42,6 @@
#define ipg_r16(reg) ioread16(ioaddr + (reg))
#define ipg_r8(reg)ioread8(ioaddr + (reg))
-#define JUMBO_FRAME_4k_ONLY
enum {
netdev_io_size = 128
};
@@ -1079,7 +1078,7 @@ static int ipg_nic_rxrestore(struct net_
return 0;
}
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
/* use jumboindex and jumbosize to control jumbo frame status
* initial status is jumboindex=-1 and jumbosize=0
@@ -1274,7 +1273,7 @@ static void ipg_nic_rx_with_end(struct n
framelen = le64_to_cpu(rxfd->rfs) & IPG_RFS_RXFRAMELEN;
- endframeLen = framelen - jumbo->current_size;
+ endframelen = framelen - jumbo->current_size;
/*
if (framelen > IPG_RXFRAG_SIZE)
framelen=IPG_RXFRAG_SIZE;
@@ -1282,8 +1281,8 @@ static void ipg_nic_rx_with_end(struct n
if (framelen > IPG_RXSUPPORT_SIZE)
dev_kfree_skb_irq(jumbo->skb);
else {
- memcpy(skb_put(jumbo->skb, endframeLen),
- skb->data, endframeLen);
+ memcpy(skb_put(jumbo->skb, endframelen),
+ skb->data, endframelen);
jumbo->skb->protocol =
eth_type_trans(jumbo->skb, dev);
@@ -1355,16 +1354,16 @@ static int ipg_nic_rx(struct net_device
switch (ipg_nic_rx_check_frame_type(dev)) {
case FRAME_WITH_START_WITH_END:
- ipg_nic_rx_with_start_and_end(dev, tp, rxfd, entry);
+ ipg_nic_rx_with_start_and_end(dev, sp, rxfd, entry);
break;
case FRAME_WITH_START:
- ipg_nic_rx_with_start(dev, tp, rxfd, entry);
+ ipg_nic_rx_with_start(dev, sp, rxfd, entry);
break;
case FRAME_WITH_END:
- ipg_nic_rx_with_end(dev, tp, rxfd, entry);
+ ipg_nic_rx_with_end(dev, sp, rxfd, entry);
break;
case FRAME_NO_START_NO_END:
- ipg_nic_rx_no_start_no_end(dev, tp, rxfd, entry);
+ ipg_nic_rx_no_start_no_end(dev, sp, rxfd, entry);
break;
}
}
@@ -1595,7 +1594,7 @@ static irqreturn_t ipg_interrupt_handler
IPG_DEBUG_MSG("_interrupt_handler\n");
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
ipg_nic_rxrestore(dev);
#endif
spin_lock(&sp->lock);
@@ -1807,7 +1806,7 @@ static int ipg_nic_open(struct net_devic
if (ipg_config_autoneg(dev) < 0)
printk(KERN_INFO "%s: Auto-negotiation error.\n", dev->name);
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
/* initialize JUMBO Frame control variable */
sp->jumbo.found_start = 0;
sp->jumbo.current_size = 0;
Index: linux-2.6/drivers/net/ipg.h
===
--- linux-2.6.orig/drivers/net/ipg.h
+++ linux-2.6/drivers/net/ipg.h
@@ -536,7 +536,7 @@ enum ipg_regs {
*/
#defineIPG_FRAMESBETWEENTXDMACOMPLETES 0x1
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
# ifdef JUMBO_FRAME_SIZE_2K
# define JUMBO_FRAME_SIZE 2048
@@ -575,6 +575,7 @@ enum ipg_regs {
# define __IPG_RXF
Re: [PATCH 1/2] Revert "IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs"
Diabolical ;-) Thanks for the pointer! Benny On Feb. 26, 2008, 11:39 -0800, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote: >> Pete, the subject says "PATCH 1/2" but I didn't see any follow-up message >> for PATCH 2/2. Just wondering :) > > I think the problem's on your end ... I got it and so did marc: > http://marc.info/?l=linux-scsi&m=120405067313933&w=2 > -- 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/
[RFC/PATCH] ipg: add jumbo frame support kconfig option
From: Pekka Enberg <[EMAIL PROTECTED]>
Convert the internal JUMBO_FRAME #ifdef to CONFIG_IP1000_JUMBO_FRAME proper and
fix compilation errors.
Cc: Francois Romieu <[EMAIL PROTECTED]>
Cc: Sorbica Shieh <[EMAIL PROTECTED]>
Cc: Jesse Huang <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |8
drivers/net/ipg.c | 21 ++---
drivers/net/ipg.h | 11 ++-
3 files changed, 24 insertions(+), 16 deletions(-)
Index: linux-2.6/drivers/net/Kconfig
===
--- linux-2.6.orig/drivers/net/Kconfig
+++ linux-2.6/drivers/net/Kconfig
@@ -2029,6 +2029,14 @@ config IP1000
To compile this driver as a module, choose M here: the module
will be called ipg. This is recommended.
+config IP1000_JUMBO_FRAME
+ bool "Support for jumbo frames (EXPERIMENTAL)"
+ depends on IP1000 && EXPERIMENTAL
+ help
+ This option enables jumbo frame support for the IP1000 driver.
+
+ If in doubt, say N.
+
config IGB
tristate "Intel(R) 82575 PCI-Express Gigabit Ethernet support"
depends on PCI
Index: linux-2.6/drivers/net/ipg.c
===
--- linux-2.6.orig/drivers/net/ipg.c
+++ linux-2.6/drivers/net/ipg.c
@@ -42,7 +42,6 @@
#define ipg_r16(reg) ioread16(ioaddr + (reg))
#define ipg_r8(reg)ioread8(ioaddr + (reg))
-#define JUMBO_FRAME_4k_ONLY
enum {
netdev_io_size = 128
};
@@ -1079,7 +1078,7 @@ static int ipg_nic_rxrestore(struct net_
return 0;
}
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
/* use jumboindex and jumbosize to control jumbo frame status
* initial status is jumboindex=-1 and jumbosize=0
@@ -1274,7 +1273,7 @@ static void ipg_nic_rx_with_end(struct n
framelen = le64_to_cpu(rxfd->rfs) & IPG_RFS_RXFRAMELEN;
- endframeLen = framelen - jumbo->current_size;
+ endframelen = framelen - jumbo->current_size;
/*
if (framelen > IPG_RXFRAG_SIZE)
framelen=IPG_RXFRAG_SIZE;
@@ -1282,8 +1281,8 @@ static void ipg_nic_rx_with_end(struct n
if (framelen > IPG_RXSUPPORT_SIZE)
dev_kfree_skb_irq(jumbo->skb);
else {
- memcpy(skb_put(jumbo->skb, endframeLen),
- skb->data, endframeLen);
+ memcpy(skb_put(jumbo->skb, endframelen),
+ skb->data, endframelen);
jumbo->skb->protocol =
eth_type_trans(jumbo->skb, dev);
@@ -1355,16 +1354,16 @@ static int ipg_nic_rx(struct net_device
switch (ipg_nic_rx_check_frame_type(dev)) {
case FRAME_WITH_START_WITH_END:
- ipg_nic_rx_with_start_and_end(dev, tp, rxfd, entry);
+ ipg_nic_rx_with_start_and_end(dev, sp, rxfd, entry);
break;
case FRAME_WITH_START:
- ipg_nic_rx_with_start(dev, tp, rxfd, entry);
+ ipg_nic_rx_with_start(dev, sp, rxfd, entry);
break;
case FRAME_WITH_END:
- ipg_nic_rx_with_end(dev, tp, rxfd, entry);
+ ipg_nic_rx_with_end(dev, sp, rxfd, entry);
break;
case FRAME_NO_START_NO_END:
- ipg_nic_rx_no_start_no_end(dev, tp, rxfd, entry);
+ ipg_nic_rx_no_start_no_end(dev, sp, rxfd, entry);
break;
}
}
@@ -1595,7 +1594,7 @@ static irqreturn_t ipg_interrupt_handler
IPG_DEBUG_MSG("_interrupt_handler\n");
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
ipg_nic_rxrestore(dev);
#endif
spin_lock(&sp->lock);
@@ -1807,7 +1806,7 @@ static int ipg_nic_open(struct net_devic
if (ipg_config_autoneg(dev) < 0)
printk(KERN_INFO "%s: Auto-negotiation error.\n", dev->name);
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
/* initialize JUMBO Frame control variable */
sp->jumbo.found_start = 0;
sp->jumbo.current_size = 0;
Index: linux-2.6/drivers/net/ipg.h
===
--- linux-2.6.orig/drivers/net/ipg.h
+++ linux-2.6/drivers/net/ipg.h
@@ -536,7 +536,7 @@ enum ipg_regs {
*/
#defineIPG_FRAMESBETWEENTXDMACOMPLETES 0x1
-#ifdef JUMBO_FRAME
+#ifdef CONFIG_IP1000_JUMBO_FRAME
# ifdef JUMBO_FRAME_SIZE_2K
# define JUMBO_FRAME_SIZE 2048
@@ -575,6 +575,7 @@ enum ipg_regs {
# define __IPG_RXFRAG_SIZE 4088
# else
# define JUMBO_FRAME_SIZE
Re: [BUG] using smp_processor_id() in preemptible as suspending
On Tue, Feb 26, 2008 at 08:33:54AM -0800, Andrew Morton wrote: > On Tue, 26 Feb 2008 16:24:11 +0800 Dave Young <[EMAIL PROTECTED]> wrote: > > > I don't know whom I should mail to, could you cc the proper guy? Thanks. Hello, Dave, Would you be willing to try out the following (untested, might not even compile) patch show at the very end of this message? This assumes that you were running with CONFIG_PREEMPT_RCU, which seems most likely based on looking at your oops. Thanx, Paul > > [ 118.331674] acpi LNXSYSTM:00: suspend > > [ 118.331674] Disabling non-boot CPUs ... > > [ 118.331674] CPU0 attaching NULL sched-domain. > > [ 118.331674] CPU1 attaching NULL sched-domain. > > [ 118.438750] CPU 1 is now offline > > [ 118.438750] lockdep: fixing up alternatives. > > [ 118.438750] SMP alternatives: switching to UP code > > [ 118.438750] BUG: using smp_processor_id() in preemptible [] > > code: s2ram/2818 > > [ 118.438750] caller is rcu_offline_cpu+0x15a/0x1c0 > > [ 118.438750] Pid: 2818, comm: s2ram Not tainted 2.6.25-rc3-test #2 > > [ 118.438750] [] ? printk+0x18/0x20 > > [ 118.438750] [] debug_smp_processor_id+0xb1/0xc0 > > [ 118.438750] [] rcu_offline_cpu+0x15a/0x1c0 > > [ 118.438750] [] rcu_cpu_notify+0x3f/0x60 > > [ 118.438750] [] notifier_call_chain+0x3d/0x80 > > [ 118.438750] [] __raw_notifier_call_chain+0x19/0x20 > > [ 118.438750] [] raw_notifier_call_chain+0x1a/0x20 > > [ 118.438750] [] _cpu_down+0x13b/0x230 > > [ 118.438750] [] disable_nonboot_cpus+0x49/0xd0 > > [ 118.438750] [] suspend_devices_and_enter+0x72/0x130 > > [ 118.438750] [] ? printk+0x18/0x20 > > [ 118.438750] [] enter_state+0xb3/0xe0 > > [ 118.438750] [] state_store+0x7d/0xc0 > > [ 118.438750] [] ? state_store+0x0/0xc0 > > [ 118.438750] [] kobj_attr_store+0x2e/0x40 > > [ 118.438750] [] flush_write_buffer+0x47/0x70 > > [ 118.438750] [] sysfs_write_file+0x49/0x70 > > [ 118.438750] [] vfs_write+0x91/0x140 > > [ 118.438750] [] sys_write+0x3d/0x70 > > [ 118.438750] [] syscall_call+0x7/0xb > > [ 118.438750] === > > [ 118.438750] CPU0 attaching NULL sched-domain. > > [ 118.440335] CPU1 is down > > Paul & Ingo I guess > > > My .config > > Doesn't tell us whether you'r eusing CONFIG_CLASSIC_RCU or > CONFIG_PREEMPT_RCU. I assume CONFIG_CLASSIC_RCU, if you ran `make > oldconfig'. > > Which kernel are you running here? Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> --- rcupreempt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -urpNa -X dontdiff linux-2.6.25-rc2/kernel/rcupreempt.c linux-2.6.25-rc2-rcuoffline/kernel/rcupreempt.c --- linux-2.6.25-rc2/kernel/rcupreempt.c2008-02-24 10:30:44.0 -0800 +++ linux-2.6.25-rc2-rcuoffline/kernel/rcupreempt.c 2008-02-26 11:39:33.0 -0800 @@ -702,8 +702,8 @@ void rcu_offline_cpu(int cpu) * fix. */ - rdp = RCU_DATA_ME(); spin_lock_irqsave(&rdp->lock, flags); + rdp = RCU_DATA_ME(); *rdp->nexttail = list; if (list) rdp->nexttail = tail; -- 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 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 07:04:02PM +0100, Jesper Nilsson wrote: > On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: > > This patch moves the cris defconfigs to arch/cris/configs/ where they > > belong. > > > > As a side effect they can now be used directly through e.g. > > make ARCH=cris artpec_3_defconfig > > > > The default defconfig is set through KBUILD_DEFCONFIG. > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > > Patch updated after I discovered an additional defconfig in > > arch/cris/arch-v10/defconfig > > That could probably have been nuked, it's ancient. > > I'll put this in my queue. Thanks! If you blindly apply this patch then make sure you do not end up with zero size files. They are disliked by the kerne and make distclean will delete them - and git becomes unhappy. 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/
Re: [PATCH 00/37] Permit filesystem local caching
On Tuesday 26 February 2008 06:33, David Howells wrote: > > Suppose one were to take a mundane approach to the persistent cache > > problem instead of layering filesystems. What you would do then is > > change NFS's ->write_page and variants to fiddle the persistent > > cache > > It is a requirement laid down by the Linux NFS fs maintainers that the writes > to the cache be asynchronous, even if the writes to NFS aren't. As it happens, I will be hanging out for the next few days with said NFS maintainers, it would help to be as informed as possible about your patch set. > Note further that NFS's write_page() != writing to the cache. Writing to the > cache is typically done by NFS's readpages(). Yes, of course. But also by ->write_page no? > > Which I could eventually find out by reading all the patches but asking you > > is so much more fun :-) > > And a waste of my time. I've provided documentation in the main FS-Cache > patch, both as text files and in comments in header files that answer your > questions. Please read them first. 37 Patches, none of which has "Documentation" in the subject line, and you did not provide a diffstat in patch 0 for the patch set as a whole. If I had known it was there of course I would have read it. It is great to see this level of documentation. But I do not think it is fair to blame your (one) reader for missing it. See the smiley above? The _real_ reason I am asking you is that I do not think anybody understands your patch set, in spite of your considerable efforts to address that. Discussion in public, right or wrong, is the only way to fix that. It is counterproductive to drive readers away from the discussion for fear that they may miss some point obvious to the original author, or perhaps already discussed earlier on lkml, and get flamed for it. Obviously, the patch set is not going to be perfect when it goes in and it would be a silly abuse of the open source process to require that, but the parts where it touches the rest of the system have to be really well understood, and it is clear from the level of participation in the thread that they are not. One bit that already came out of this, which you have alluded to several times yourself but somehow seem to keep glossing over, is that you need a ->direct_bio file operations method. So does loopback mount. It might be worth putting some effort into seeing how ->direct_IO can be refactored to make that happen. You can get it in separately on the basis of helping loopback, and it will make your patches nicer. Daniel -- 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] forcing SCO connection patch
Hi Loius,
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
17:17:11.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
17:30:23.0 +0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
NAK. There is no need to check for ACL_LINK. The sync_complete will
only be called for SCO or eSCO connections.
I see. I removed this check line in the patch.
Thanks.
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-26
12:46:36.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-26
12:47:23.0 +0900
@@ -1313,8 +1313,15 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ else
+ goto unlock;
+ }
if (!ev->status) {
conn->handle = __le16_to_cpu(ev->handle);
do something like this:
if (!conn) {
conn =
if (!conn)
goto unlock;
conn->type = ev->link_type;
}
And include a description when submitting a patch.
Regards
Marcel
--
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: [dm-devel] Re: device mapper not reporting no-barrier-support?
On Tue, Feb 26 2008, Anders Henke wrote:
> On Tue, Feb 26 2008 Jens Axboe wrote:
> > On Tue, Feb 26 2008, Alasdair G Kergon wrote:
> > > On Mon, Feb 25, 2008 at 03:20:50PM -0800, Andrew Morton wrote:
> > > > On Mon, 25 Feb 2008 14:26:15 +0100 Anders Henke <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > I'm currently stuck between Kernel LVM and DRBD, as I'm using Kernel
> > > > > 2.6.24.2 with DRBD 8.2.5 on top of an LVM2 device (LV).
> > > > > -LVM2/device mapper doesn't support write barriers
> > >
> > > That's right.
> > >
> > > > > -DRBD uses blkdev_issue_flush() to flush its metadata to disk.
> > >
> > > Which won't work if device-mapper is underneath.
> > >
> > > > > On a no-barrier-device, DRBD should receive EOPNOTSUPP, but
> > > > > it really does receive an EIO. Promptly, DRBD gives the
> > > > > error message "drbd0: local disk flush failed with status -5".
> > > > > I've posted a lengty summary of my findings to
> > > > > http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html
> > > > > ... that DRBD does catch the EOPNOTSUPP for blkdev_issue_flush and
> > > > > BIO_RW_BARRIER, but the lvm implementation of blkdev_issue_flush in
> > > > > 2.6.24.2 aparently does return EIO for blkdev_issue_flush.
> > > > I'd say it's a DM bug.
> > >
> > > The dm code is unchanged, but look at the limited endio handling in
> > > ll_rw_blk.c:
> > >
> > > static void bio_end_empty_barrier(struct bio *bio, int err)
> > > {
> > > if (err)
> > > clear_bit(BIO_UPTODATE, &bio->bi_flags);
> > >
> > > complete(bio->bi_private);
> > > }
> > >
> > > int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector)
> > > {
> > > ...
> > > wait_for_completion(&wait);
> > > if (error_sector)
> > > *error_sector = bio->bi_sector;
> > > ret = 0;
> > > if (!bio_flagged(bio, BIO_UPTODATE))
> > > ret = -EIO;
> >
> > You are right, the return value got broken there. Does this make it
> > return -EOPNOTSUPP properly for you?
>
>
> No, it doesn't.
>
>
>
> I've applied your patch manually, as 2.6.24.2. doesn't have a "blk-barrier.c":
>
> ---cut
> --- linux-2.6.24.2/block/ll_rw_blk.c.prepatch 2008-02-11
> 06:51:11.0 +0100
> +++ linux-2.6.24.2/block/ll_rw_blk.c2008-02-26 20:02:28.514641620
> +0100
> @@ -2667,8 +2667,11 @@
>
> static void bio_end_empty_barrier(struct bio *bio, int err)
> {
> - if (err)
> + if (err) {
> + if (err == -EOPNOTSUPP)
> + set_bit(BIO_EOPNOTSUPP, &bio->bi_flags);
> clear_bit(BIO_UPTODATE, &bio->bi_flags);
> + }
>
> complete(bio->bi_private);
> }
> ---cut
>
> ... and the resulting kernel shows exactly the same behaviour than before:
Not surprising, as you missed half of the patch:
> > @@ -309,7 +312,9 @@ int blkdev_issue_flush(struct block_device *bdev,
> > sector_t *error_sector)
> > *error_sector = bio->bi_sector;
> >
> > ret = 0;
> > - if (!bio_flagged(bio, BIO_UPTODATE))
> > + if (bio_flagged(bio, BIO_EOPNOTSUPP))
> > + ret = -EOPNOTSUPP;
> > + else if (!bio_flagged(bio, BIO_UPTODATE))
> > ret = -EIO;
> >
> > bio_put(bio);
--
Jens Axboe
--
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/
Kconfig configuration restore bug [Was: x86: vSMP selection in config]
Hi Roman. We discovered a situation where we could set a choice value in menuconfig but later when we either was running menuconfig or oldconfig the value were changed. I have created a minimal config that exhibit the error. It was created in a pure mechanical trial-and-error fashion. First the minimal Kconfig file: # x86 configuration choice prompt "Subarchitecture Type" config X86_PC bool "PC-compatible" config X86_VOYAGER bool "Voyager (NCR)" config X86_VSMP bool "Support for ScaleMP vSMP" depends on PCI endchoice config PCI bool "PCI support" if !X86_VISWS depends on !X86_VOYAGER default y config USB_ARCH_HAS_HCD bool default PCI config USB bool "Support for Host-side USB" depends on USB_ARCH_HAS_HCD config USB_PHIDGET bool "USB Phidgets drivers" depends on USB config USB_PHIDGETMOTORCONTROL bool "USB PhidgetMotorControl support" depends on USB_PHIDGET Next the saved .config that is used: # # Automatically generated make config: don't edit # Linux kernel version: KERNELVERSION # Tue Feb 26 20:27:09 2008 # # CONFIG_X86_PC is not set # CONFIG_X86_VOYAGER is not set CONFIG_X86_VSMP=y CONFIG_PCI=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_PHIDGET is not set When we enter menuconfig or are running oldconfig then we can see that CONFIG_X86_PC is set to 'y' and CONFIG_X86_VSMP is set to 'n'. If I in menuconfig select VSMP this setting is saved but then oldconfig kicks in and we loose the setting again. If I delete any of the config variables in the sample above then we no longer change the values and we keep the VSMP equals 'y'. Can you please take a look at this. Thanks, 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/
Re: [PATCH 1/2] Revert "IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs"
On Tue, Feb 26, 2008 at 11:23:01AM -0800, Benny Halevy wrote: > Pete, the subject says "PATCH 1/2" but I didn't see any follow-up message > for PATCH 2/2. Just wondering :) I think the problem's on your end ... I got it and so did marc: http://marc.info/?l=linux-scsi&m=120405067313933&w=2 -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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: delete timer in l2cap_conn_del()
Hi Quel, Delete a possibly armed timer before kfree'ing the connection object. Solves: http://lkml.org/lkml/2008/2/15/514 Reported-by:Quel Qun <[EMAIL PROTECTED]> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> --- net/bluetooth/l2cap.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/net/bluetooth/l2cap.c === --- linux-2.6.orig/net/bluetooth/l2cap.c +++ linux-2.6/net/bluetooth/l2cap.c @@ -417,6 +417,8 @@ static void l2cap_conn_del(struct hci_co l2cap_sock_kill(sk); } + del_timer_sync(&conn->info_timer); + hcon->l2cap_data = NULL; kfree(conn); } can you confirm that this actually fixes the issue. Thomas, if confirmed, this is Acked-by me. Regards Marcel -- 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: [dm-devel] Re: device mapper not reporting no-barrier-support?
On Tue, Feb 26 2008 Jens Axboe wrote:
> On Tue, Feb 26 2008, Alasdair G Kergon wrote:
> > On Mon, Feb 25, 2008 at 03:20:50PM -0800, Andrew Morton wrote:
> > > On Mon, 25 Feb 2008 14:26:15 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
> > > > I'm currently stuck between Kernel LVM and DRBD, as I'm using Kernel
> > > > 2.6.24.2 with DRBD 8.2.5 on top of an LVM2 device (LV).
> > > > -LVM2/device mapper doesn't support write barriers
> >
> > That's right.
> >
> > > > -DRBD uses blkdev_issue_flush() to flush its metadata to disk.
> >
> > Which won't work if device-mapper is underneath.
> >
> > > > On a no-barrier-device, DRBD should receive EOPNOTSUPP, but
> > > > it really does receive an EIO. Promptly, DRBD gives the
> > > > error message "drbd0: local disk flush failed with status -5".
> > > > I've posted a lengty summary of my findings to
> > > > http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html
> > > > ... that DRBD does catch the EOPNOTSUPP for blkdev_issue_flush and
> > > > BIO_RW_BARRIER, but the lvm implementation of blkdev_issue_flush in
> > > > 2.6.24.2 aparently does return EIO for blkdev_issue_flush.
> > > I'd say it's a DM bug.
> >
> > The dm code is unchanged, but look at the limited endio handling in
> > ll_rw_blk.c:
> >
> > static void bio_end_empty_barrier(struct bio *bio, int err)
> > {
> > if (err)
> > clear_bit(BIO_UPTODATE, &bio->bi_flags);
> >
> > complete(bio->bi_private);
> > }
> >
> > int blkdev_issue_flush(struct block_device *bdev, sector_t *error_sector)
> > {
> > ...
> > wait_for_completion(&wait);
> > if (error_sector)
> > *error_sector = bio->bi_sector;
> > ret = 0;
> > if (!bio_flagged(bio, BIO_UPTODATE))
> > ret = -EIO;
>
> You are right, the return value got broken there. Does this make it
> return -EOPNOTSUPP properly for you?
No, it doesn't.
I've applied your patch manually, as 2.6.24.2. doesn't have a "blk-barrier.c":
---cut
--- linux-2.6.24.2/block/ll_rw_blk.c.prepatch 2008-02-11
06:51:11.0 +0100
+++ linux-2.6.24.2/block/ll_rw_blk.c2008-02-26 20:02:28.514641620
+0100
@@ -2667,8 +2667,11 @@
static void bio_end_empty_barrier(struct bio *bio, int err)
{
- if (err)
+ if (err) {
+ if (err == -EOPNOTSUPP)
+ set_bit(BIO_EOPNOTSUPP, &bio->bi_flags);
clear_bit(BIO_UPTODATE, &bio->bi_flags);
+ }
complete(bio->bi_private);
}
---cut
... and the resulting kernel shows exactly the same behaviour than before:
[ 752.301388] drbd0: Writing meta data super block now.
[ 752.349713] drbd0: local disk flush failed with status -5
[ 752.416256] drbd0: local disk flush failed with status -5
[ 753.419254] drbd0: local disk flush failed with status -5
[ 753.925726] drbd0: local disk flush failed with status -5
[ 754.551176] drbd0: local disk flush failed with status -5
[ 754.806052] drbd0: local disk flush failed with status -5
[ 755.327988] drbd0: local disk flush failed with status -5
[ 755.781863] drbd0: local disk flush failed with status -5
[ 756.266694] drbd0: local disk flush failed with status -5
Anders
> diff --git a/block/blk-barrier.c b/block/blk-barrier.c
> index 6901eed..55c5f1f 100644
> --- a/block/blk-barrier.c
> +++ b/block/blk-barrier.c
> @@ -259,8 +259,11 @@ int blk_do_ordered(struct request_queue *q, struct
> request **rqp)
>
> static void bio_end_empty_barrier(struct bio *bio, int err)
> {
> - if (err)
> + if (err) {
> + if (err == -EOPNOTSUPP)
> + set_bit(BIO_EOPNOTSUPP, &bio->bi_flags);
> clear_bit(BIO_UPTODATE, &bio->bi_flags);
> + }
>
> complete(bio->bi_private);
> }
> @@ -309,7 +312,9 @@ int blkdev_issue_flush(struct block_device *bdev,
> sector_t *error_sector)
> *error_sector = bio->bi_sector;
>
> ret = 0;
> - if (!bio_flagged(bio, BIO_UPTODATE))
> + if (bio_flagged(bio, BIO_EOPNOTSUPP))
> + ret = -EOPNOTSUPP;
> + else if (!bio_flagged(bio, BIO_UPTODATE))
> ret = -EIO;
>
> bio_put(bio);
>
> --
> Jens Axboe
>
--
1&1 Internet AG "Use the --force, Luke"
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhef://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
--
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: oops when using git gc --auto
Nick Piggin <[EMAIL PROTECTED]> writes: > On Wednesday 27 February 2008 00:22, Otavio Salvador wrote: >> Hello, >> >> Today I got this oops, someone has an idea of what's going wrong? >> >> Unable to handle kernel paging request at 0200 RIP: >> [] find_get_pages+0x3c/0x69 > > At this point, the most likely candidate is a memory corruption > error, probably hardware. Can you run memtest86 for a few hours > to get a bit more confidence in the hw (preferably overnight)? > > I did recently see another quite similar corruption in the > pagecache radix-tree, though. Coincidence maybe? I let it running at lunch time and all went OK. I've also let burnP6 running later and nothing happened. Looks like hw is OK. I've just got another oops, with same kernel. Unable to handle kernel paging request at 83006d922370 RIP: [] shrink_page_list+0x16f/0x570 PGD 0 Oops: [1] SMP CPU 2 Modules linked in: sha256_generic aes_generic aes_x86_64 cbc blkcipher nvidia(P) rfcomm l2cap bluetooth ac battery ipv6 nfs lockd nfs_acl sunrpc bridge ext2 mbcache dm_crypt tun kvm_intel kvm loop snd_hda_intel snd_usb_audio snd_pcm snd_timer snd_usb_lib snd_rawmidi snd_seq_device snd_hwdep snd i2c_i801 soundcore snd_page_alloc intel_agp serio_raw button pcspkr e1000e i2c_core psmouse evdev xfs dm_mirror dm_snapshot dm_mod raid0 md_mod sg sr_mod cdrom sd_mod usbhid hid pata_marvell usb_storage floppy ahci ata_generic libata scsi_mod uhci_hcd ehci_hcd thermal processor fan Pid: 213, comm: kswapd0 Tainted: P2.6.24-1-amd64 #1 RIP: 0010:[] [] shrink_page_list+0x16f/0x570 RSP: 0018:81007ac8bbe0 EFLAGS: 00010286 RAX: 00010009 RBX: 810001e888a8 RCX: 810001e888d0 RDX: 83006d922350 RSI: 0001 RDI: 810001e888a8 RBP: 81007d1b9258 R08: 81007d776407 R09: R10: 0009 R11: 0002 R12: 0001 R13: 81007ac8be70 R14: 81007ac8bda0 R15: 81007ac8be01 FS: () GS:81007d776340() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 83006d922370 CR3: 6d4ac000 CR4: 26e0 DR0: DR1: DR2: DR3: DR6: 4ff0 DR7: 0400 Process kswapd0 (pid: 213, threadinfo 81007ac8a000, task 81007cc03800) Stack: 0006 0002 0002 0001 810001dc79e0 810001dc7a18 810001dc7fc8 810001dc8000 0001 0001 Call Trace: [] isolate_lru_pages+0x5d/0x1d9 [] isolate_lru_pages+0x5d/0x1d9 [] shrink_inactive_list+0x11d/0x381 [] shrink_zone+0xe5/0x108 [] kswapd+0x2fc/0x49b [] thread_return+0x3d/0xab [] autoremove_wake_function+0x0/0x2e [] kswapd+0x0/0x49b [] kthread+0x47/0x74 [] child_rip+0xa/0x12 [] kthread+0x0/0x74 [] child_rip+0x0/0x12 Code: 48 83 7a 20 00 0f 85 47 03 00 00 48 8d 42 30 48 39 42 30 0f RIP [] shrink_page_list+0x16f/0x570 RSP CR2: 83006d922370 ---[ end trace b01014a6540e7663 ]--- -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- 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: epoll and shared fd's
On Tue, 26 Feb 2008, Michael Kerrisk wrote: > Okay -- I'll look at it some more. I am however loathe to drop the > term open file description, because POSIX uses, as well as a number of > other Linux man pages by now. Heh, POSIX. Now doesn't take a genius to see that "file description" and "file descriptor" looks amazingly similar, does it? :) > > That'd mean placing an eventpoll custom hook into sys_close(). Looks > > very bad to me, and probably will look even worse to other kernel > > folks. Is not much a performance issue (a check to see if a file* is > > an eventpoll file is as easy as comparing the f_op pointer), but a > > design/style issue. > > Oh -- I wasn't suggesting we could make the change now -- it would > break the ABI and all that. I was just wondering why the decision > wasn't made to do it the other way to begin with. The existing > semantics are somewhat couterintuitive, and potentially interact > libraries that do private manipulations with file descriptors. For the same reason that a custom hook in sys_close wouldn't have passed the radar ;) As far as problems with libraries doing tricks with fds, that's an issue that goes beyond epoll. - Davide -- 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: arcmsr & areca-1660 - strange behaviour under heavy load
Hi Andrew, no, right now I have the machine in the weird state, swap is empty (3GB), and so is bigger part of RAM (~100MB free), and the gcc crashes even when trying to compile c program with empty main function. so it doesn't seem to be problem with memory exhaustion. Hopefully the areca guys will be able to find out what is going on. But anyways, if You'll have any other idea what should I check/try, please let me know, as I have to admit that I'd really like to hunt it down myself (and yes, there is some vanity on my side here :)) thanks a lot once more cheers nik On Tue, 26 Feb 2008, Andrew Morton wrote: On Tue, 26 Feb 2008 10:35:31 +0100 (CET) Nikola Ciprich <[EMAIL PROTECTED]> wrote: Hi On Sun, 24 Feb 2008, Andrew Morton wrote: Hi Andrew, thanks a lot for reply, I'm attaching requested information. please let me know if You need more information/testing, whatever. I'll be glad to help. BR nik Areca support doesn't seem to be very interested in the problem :-( (cc's added) Please get the machine into this state of memory exhaustion then take copies of the output of the following, and send them via reply-to-all to this email: - cat /proc/meminfo - cat /proc/slabinfo - dmesg -c > /dev/null ; echo m > /proc/sysrq-trigger ; dmesg -c Thanks. Alas, that all looks OK to me. You never get any out-of-memory messages, and no oom-killing messages? Possibly what is happening here is that in this low-memory condition, some of the driver's internal memory-allocation attempts are failing, and the driver isn't correctly handling this. This is a rare situation which may well not have been hit in anyone else's testing. I expect that the Areca engineers will be able to reproduce this with a suitably small "mem=" kernel boot option. If not, they could perhaps investigate the kernel's fault-injection framework, which permits simulation of page allocation failures. -- 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/ -- -- 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] Revert "IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs"
Pete, the subject says "PATCH 1/2" but I didn't see any follow-up message
for PATCH 2/2. Just wondering :)
Benny
On Feb. 26, 2008, 10:27 -0800, Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38.
>
> The original commit breaks iSER reliably, making it complain:
>
> iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11
>
> The FMR cleanup thread runs ib_fmr_batch_release() as dirty
> entries build up. This commit causes clean but used FMR
> entries also to be purged. During that process, another thread
> can see that there are no free FMRs and fail, even though
> there should always have been enough available.
>
> Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
> ---
> drivers/infiniband/core/fmr_pool.c | 21 ++---
> 1 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/infiniband/core/fmr_pool.c
> b/drivers/infiniband/core/fmr_pool.c
> index 7f00347..4044fdf 100644
> --- a/drivers/infiniband/core/fmr_pool.c
> +++ b/drivers/infiniband/core/fmr_pool.c
> @@ -139,7 +139,7 @@ static inline struct ib_pool_fmr
> *ib_fmr_cache_lookup(struct ib_fmr_pool *pool,
> static void ib_fmr_batch_release(struct ib_fmr_pool *pool)
> {
> int ret;
> - struct ib_pool_fmr *fmr, *next;
> + struct ib_pool_fmr *fmr;
> LIST_HEAD(unmap_list);
> LIST_HEAD(fmr_list);
>
> @@ -158,20 +158,6 @@ static void ib_fmr_batch_release(struct ib_fmr_pool
> *pool)
> #endif
> }
>
> - /*
> - * The free_list may hold FMRs that have been put there
> - * because they haven't reached the max_remap count.
> - * Invalidate their mapping as well.
> - */
> - list_for_each_entry_safe(fmr, next, &pool->free_list, list) {
> - if (fmr->remap_count == 0)
> - continue;
> - hlist_del_init(&fmr->cache_node);
> - fmr->remap_count = 0;
> - list_add_tail(&fmr->fmr->list, &fmr_list);
> - list_move(&fmr->list, &unmap_list);
> - }
> -
> list_splice(&pool->dirty_list, &unmap_list);
> INIT_LIST_HEAD(&pool->dirty_list);
> pool->dirty_len = 0;
> @@ -384,6 +370,11 @@ void ib_destroy_fmr_pool(struct ib_fmr_pool *pool)
>
> i = 0;
> list_for_each_entry_safe(fmr, tmp, &pool->free_list, list) {
> + if (fmr->remap_count) {
> + INIT_LIST_HEAD(&fmr_list);
> + list_add_tail(&fmr->fmr->list, &fmr_list);
> + ib_unmap_fmr(&fmr_list);
> + }
> ib_dealloc_fmr(fmr->fmr);
> list_del(&fmr->list);
> kfree(fmr);
--
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: epoll and shared fd's
On Tue, Feb 26, 2008 at 8:04 PM, Davide Libenzi <[EMAIL PROTECTED]> wrote: > > On Tue, 26 Feb 2008, Michael Kerrisk wrote: > > > Following up after quite some time: > > > > Davide Libenzi wrote: > > > On Sat, 26 Jan 2008, Michael Kerrisk wrote: > > > > > >> On Jan 25, 2008 12:57 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote: > > >>> On Thu, 24 Jan 2008, Pierre Habouzit wrote: > > >>> > > On Fri, Jan 18, 2008 at 09:10:18PM +, Davide Libenzi wrote: > > > On Fri, 18 Jan 2008, Pierre Habouzit wrote: > > > > > >> Hi, > > >> > > >> I just came across a strange behavior of epoll that seems to > > >> contradict the documentation. Here is what happens: > > >> > > >> * I have two processes P1 and P2, P1 accept()s connections, and send > > >> the > > >> resulting file descriptors to P2 through a unix socket. > > >> > > >> * P2 registers the received socket in his epollfd. > > >> > > >> [time passes] > > >> > > >> * P2 is done with the socket and closes it > > >> > > >> * P2 gets events for the socket again ! > > >> > > >> > > >> Though the documentation says that if a process closes a file > > >> descriptor, it gets unregistered. And yes I'm sure that P2 doens't > > >> dup() > > >> the file descriptor. Though (because of a bug) it was still open in > > >> P1[0], hence the referenced socket still live at the kernel level. > > >> > > >> Of course the userland workaround is to force the EPOLL_CTL_DEL > > >> before > > >> the close, which I now do, but costs me a syscall where I wanted to > > >> spare one :| > > > For epoll, a close is when the kernel file* is released (that is, > > > when all > > > its instances are gone). > > > We could put a special handling in filp_close(), but I don't think is > > > a > > > good idea, and we're better live with the current behaviour. > > Okay, maybe updating the linux manpages to be more clear about that > > is > > the way to go then. Thanks > > >>> Sure. I'll send Michael Kerrisk and updated statement for the A6 answer > > >>> in > > >>> the epoll man page. > > >> Thanks Davide -- yes please send me a patch. > > >> -- > > >> 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/ > > >> > > > > > > Something like the one below ... > > > > > > > > > - Davide > > > > > > > > > > > > --- epoll.4 2008-01-26 12:58:21.0 -0800 > > > +++ epoll.4.new 2008-01-26 13:06:36.0 -0800 > > > @@ -285,7 +285,19 @@ > > > sets automatically? > > > .TP > > > .B A6 > > > -Yes. > > > +A file descriptor is the userspace counterpart of an internal kernel > > > handle. > > > +Every time a process calls functions liks > > > +.BR dup (2), > > > +.BR dup2 (2) > > > +or > > > +.BR fork (2), > > > +a new file descriptor referring to the same internal kernel handle is > > > +created. The internal kernel handle remains alive until all the userspace > > > +file descriptors have been closed. > > > +The > > > +.BR epoll (4) > > > +interface automatically removes the internal kernel handle from the set, > > > +once all the file descriptor instances have been closed. > > > .TP > > > .B Q7 > > > If more than one event occurs between > > > > Davide, > > > > Two points. > > > > a) I did a > > > > s/internal kernel handle/open file description/ > > > > since that is the POSIX term for the internal handle. > > > > b) It seems to me that you text doesn't quite make the point explicit > > enough. I've tried to rewrite it; could you please check: > > > >A6 Yes, but be aware of the following point. A file > > descriptor is a reference to an open file descrip- > > tion (see open(2)). Whenever a descriptor is > > duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, > > or fork(2), a new file descriptor referring to the > > same open file description is created. An open > > file description continues to exist until all file > > descriptors referring to it have been closed. The > > epoll interface automatically removes a file > > descriptor from an epoll set only after all the > > file descriptors referring to the underlying open > > file handle have been closed. This means that > > even after a file descriptor that is part of an > > epoll set has been closed, events may be reported > > for that file descriptor if other file descriptors > > referring to the same underlying file description > > remain open. > > > > Does that seem okay? I plan to include th
Re: 2.6.25-rc2 regression in rt61pci wireless driver
Hi, > > I've bisected anyway and although the results are not absolutely > > conclusive, as I neared the end of the process, I was amongst a bunch of > > mac80211 patches. This set me on a path that resulted in me discovering > > that with the rt61pci driver, I can freeze my wireless network connection > > almost at will if I set mac82011's ieee80211_default_rc_algo parameter to > > 'pid'. if the parametre is set to 'simple', the network seems to be > > reliable. I've just let the ping application run on and ping another box > > on my network almost 1500 times whilst repeatedly transferring a kernel > > source tarball by ftp from another box and the network connection was > > mantained That's with the parameter set to 'simple', if \I set it to > > 'pid' the connection rarely survives more than 40 pings even without the > > ftp activity. > > > > If I replace my wireless card with one that uses the rtl8180 driver, the > > network connection seems to be reliable regardless of how I set the > > parameter, although I admit that i have not tested this extensively yet. > > I'll do that now and report later. > I've rerun my tests with the rtl8180 driver and found the network to be reliable with the mac82011 module's ieee80211_default_rc_algo parameter set to either 'simple' or 'pid'. > I'm about to send 4 patches to this (linux-wireless) list with patches > for rt2x00, > most of them you already tested individually, but several people reported > success after those patches. > > Hopefully it will be working for you as well. :) > Sorry, but that's not the case. I find the same results as without the patches. With the parameter set to 'pid', the network connection fails very quickly, but with it set to 'simple' I can ping and ftp files to and from my laptop as much as I like and the connection stays up. In fact, if anything the patches seem to have made the network even more fragile, in that it fails almost instantly once I start some network activity ( < 10 pings). I'm sure this is not the hardware - it works perfectly with Windows XP, with 2.6.23.14 plus the out-of-tree rt61 driver from serialmonkey, with the in-tree driver from 2.6.24.x and with 2.6.25-rc3 with the mac82011's ieee80211_default_rc_algo parameter set to 'simple'. Like I say above, sorry! Chris > Ivo -- Beauty is in the eye of the beerholder. -- 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: + rcu-split-listh-and-move-rcu-protected-lists-into-rculisth.patch added to -mm tree
Franck Bui-Huu wrote: > Josh Triplett wrote: >> [I did not see this patch go by on any mailing list, so I replied to >> the -mm mail and CCed LKML.] >> > > Well I'm pretty sure to have always CC'ed LKML, see for example: > > http://lkml.org/lkml/2008/2/19/150 > http://lkml.org/lkml/2008/2/19/151 I must have missed it when I dug through the archive. Thanks. - Josh Triplett -- 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: Is there a memory block device?
On Tue, 26 Feb 2008 19:53:36 +0100, rzryyvzy said: > I know that tmpfs is a memmory filesystem. Is there a possibility to create > also a memory block device? > Is there a possibility to create for example a 1 GB memory block device (from > the RAM)? A better question would be: What problem are you trying to solve by ysing a "memory block device"? There may well be other approaches that would work better, but it's hard to say. Are you trying to avoid the buffer cache pool? Ensure pages are in physical memory? Or some other problem? pgpgoVkj7j7vL.pgp Description: PGP signature
Re: epoll and shared fd's
On Tue, 26 Feb 2008, Michael Kerrisk wrote: > Following up after quite some time: > > Davide Libenzi wrote: > > On Sat, 26 Jan 2008, Michael Kerrisk wrote: > > > >> On Jan 25, 2008 12:57 AM, Davide Libenzi <[EMAIL PROTECTED]> wrote: > >>> On Thu, 24 Jan 2008, Pierre Habouzit wrote: > >>> > On Fri, Jan 18, 2008 at 09:10:18PM +, Davide Libenzi wrote: > > On Fri, 18 Jan 2008, Pierre Habouzit wrote: > > > >> Hi, > >> > >> I just came across a strange behavior of epoll that seems to > >> contradict the documentation. Here is what happens: > >> > >> * I have two processes P1 and P2, P1 accept()s connections, and send > >> the > >> resulting file descriptors to P2 through a unix socket. > >> > >> * P2 registers the received socket in his epollfd. > >> > >> [time passes] > >> > >> * P2 is done with the socket and closes it > >> > >> * P2 gets events for the socket again ! > >> > >> > >> Though the documentation says that if a process closes a file > >> descriptor, it gets unregistered. And yes I'm sure that P2 doens't > >> dup() > >> the file descriptor. Though (because of a bug) it was still open in > >> P1[0], hence the referenced socket still live at the kernel level. > >> > >> Of course the userland workaround is to force the EPOLL_CTL_DEL > >> before > >> the close, which I now do, but costs me a syscall where I wanted to > >> spare one :| > > For epoll, a close is when the kernel file* is released (that is, when > > all > > its instances are gone). > > We could put a special handling in filp_close(), but I don't think is a > > good idea, and we're better live with the current behaviour. > Okay, maybe updating the linux manpages to be more clear about that is > the way to go then. Thanks > >>> Sure. I'll send Michael Kerrisk and updated statement for the A6 answer in > >>> the epoll man page. > >> Thanks Davide -- yes please send me a patch. > >> -- > >> 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/ > >> > > > > Something like the one below ... > > > > > > - Davide > > > > > > > > --- epoll.4 2008-01-26 12:58:21.0 -0800 > > +++ epoll.4.new 2008-01-26 13:06:36.0 -0800 > > @@ -285,7 +285,19 @@ > > sets automatically? > > .TP > > .B A6 > > -Yes. > > +A file descriptor is the userspace counterpart of an internal kernel > > handle. > > +Every time a process calls functions liks > > +.BR dup (2), > > +.BR dup2 (2) > > +or > > +.BR fork (2), > > +a new file descriptor referring to the same internal kernel handle is > > +created. The internal kernel handle remains alive until all the userspace > > +file descriptors have been closed. > > +The > > +.BR epoll (4) > > +interface automatically removes the internal kernel handle from the set, > > +once all the file descriptor instances have been closed. > > .TP > > .B Q7 > > If more than one event occurs between > > Davide, > > Two points. > > a) I did a > > s/internal kernel handle/open file description/ > > since that is the POSIX term for the internal handle. > > b) It seems to me that you text doesn't quite make the point explicit > enough. I've tried to rewrite it; could you please check: > >A6 Yes, but be aware of the following point. A file > descriptor is a reference to an open file descrip- > tion (see open(2)). Whenever a descriptor is > duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, > or fork(2), a new file descriptor referring to the > same open file description is created. An open > file description continues to exist until all file > descriptors referring to it have been closed. The > epoll interface automatically removes a file > descriptor from an epoll set only after all the > file descriptors referring to the underlying open > file handle have been closed. This means that > even after a file descriptor that is part of an > epoll set has been closed, events may be reported > for that file descriptor if other file descriptors > referring to the same underlying file description > remain open. > > Does that seem okay? I plan to include the text in man-pages-2.79. I agree with Bodo, it is kinda confusing. The name "open file description", even though POSIX, looks very similar to "file descriptor". I honestly don't know how more easily such concept could be expressed. IMHO at least "internal kernel handle" does not play look-alike games with "file descriptor". > Was the
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Tue, Feb 26, 2008 at 10:42 AM, Ravikiran Thirumalai <[EMAIL PROTECTED]> wrote: > On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: > >On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> > wrote: > >> On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: > >> > >> > > > >> >If you can't support that in your hardware you're supposed > >> >to clear it. > >> > >> Hmm! How would a hardware vendor do that? That doesn't seem to be clear > in > >> the BKDG. (Well, this is the problem with undocumented features :() > >> > >any good sign for APIC_clustered box? there is apicid between cpus > >even all cpu are quadcore and fully populated? > > I would suggest checking the SLIT distances -- On AMD boxes, if you have > three > different distances between nodes, then that system would be multiboard, > and there is no way TSCs can be synced. On Intel boxes, if there are two > different distances between nodes, then this would be a multi board/multi > chassi box and TSCs won't be synced. This is a more generic solution and > should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for > now. It might need the same treatment as AMD) 1. if acpi=off ? 2. some system will be treated wrong. my four sockets system ACPI: SLIT: nodes = 4 10 13 13 16 13 10 16 13 13 16 10 13 16 13 13 10 my eight sockets system ACPI: SLIT: nodes = 8 10 12 12 14 14 14 14 16 12 10 14 12 14 14 12 14 12 14 10 14 12 12 14 14 14 12 14 10 12 12 14 14 14 14 12 12 10 14 12 14 14 14 12 12 14 10 14 12 14 12 14 14 12 14 10 12 16 14 14 14 14 12 12 10 YH -- 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue, 26 Feb 2008 19:16:11 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > On Tue 2008-02-26 13:10:01, Dave Jones wrote: > > On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote: > > > > > > if by 'custom' you mean the solution everyone agreed to work > > > > toward at the power management summit several years ago > > > > (hal/pm-utils) then, yes. > > > > > > I must have been on different summit... I believe it is bad to tie > > > s2ram to hal, because it makes testing on minimal system hard. > > > > > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps > > > Fedora already has his machine whitelisted... > > > > There is no s2ram. pm-suspend uses the white/black-lists in pm-utils. > > Remember that? The cross-distro package everyone agreed was a good idea > > so that every distro didn't have their own magic utility ? > > Well, we have cross-distro package, it is at suspend.sf.net , and it > can bring up video - which is kind of important. (It is single binary, > so it can be pagelocked -- which is important for s2disk). > > Plus it does not depend on HAL. Meanwhile, my computer continues to not work. First thing we need to do is to work out why it won't stay suspended? -- 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/
Odd performance observation for RAID0
Hi folks: I posted this in linux-raid, though I thought it might interest the kernel folks due to the subsystems in question. No responses there. Executive summary version: building a RAID0 across 2 large hardware RAIDed disks results in buffered I/O performance that is similar to a single one of these controllers. Additional tests, breaking the raid apart into 2 separate drives, yields the expected I/O performance when using buffered IO, and 2 simultaneous IO operations, one to each disk. Direct IO doesn't show this performance anomaly and is fast in either case. Observed with kernel 2.6.23.14. A curious thing happens with 2.6.24.2, in that now direct IO performance is as bad as buffered IO performance. The problem as stated, leads me to think that I might be running into a point of serialization of the buffer cache. Details: I built a RAID0 stripe across two large hardware RAID cards (identical cards/driver). What I am finding is that direct IO is about the performance I expect (2x the single RAID card) while buffered IO is about the same as the performance of a single RAID card. This is true across chunk sizes of 64 through 4096k, with an xfs file system. This is a 2.6.23.14 kernel. I tried 2.6.24.2, and there the direct IO on two RAID cards was the same speed as the direct and buffered IO on one RAID card, even though the RAID0 striped across 2 RAID cards. There appears to be some issue with this combination of RAID0, buffer cache, and the driver. Breaking the raid in 2, and performing the same tests on each RAID card results in the expected performance during buffered io and direct IO. Tests were simple reads and writes: dd if=/dev/zero of=/big/local.file bs=8388608 count=1 and dd if=/big/local.file of=/dev/null bs=8388608 added oflag=direct and iflag=direct for the direct io versions. I tried changing the default IO scheduler (cfq to deadline) though this particular workload shouldn't make much of a difference (all reads or all writes). I tried altering queue depth, and a number of other parameters. All told, they had limited impact. The end user of this system indicated that they will be using fadvise mechanisms to handle cache hinting, and they will be doing large block sequential streaming, so direct IO like performance should be fine. That said, I am concerned that the buffered IO case appears serialized. Of course we are not re-using the buffer for these tests, so this could have an impact. Along those lines, I tried adjusting the "dirty" parameters to see what I could do /proc/sys/vm/dirty_expire_centisecs /proc/sys/vm/dirty_writeback_centisecs /proc/sys/vm/dirty_ratio /proc/sys/vm/dirty_background_ratio I tried various changes that I thought might work (increasing the dirty_ratio while decreasing the dirty_expire_centisecs). I did get some impact, though it was mostly in the direction of lower performance. The questions I have are, could the raid0 device be effectively serializing access to the buffer cache? The hardware RAID devices I am using are quite fast, so this might represent a different area of testing than raid0 normally gets. Other possibilities I have thought of include oddities in xfs (I tried ext3 as well, though I ran into an 8TB limit) and how it interacts with the buffer cache. Driver oddities (seen on several versions of this driver). To try to eliminate these other effects, I broke the unit up into 2 separate devices (1 per RAID card), and built two file systems. Simultaneous IO to each file system gave expected performance. My take on that is that the driver (handling both RAIDs) has no trouble interacting with the OS and the buffer cache under heavy IO situations. I used xfs on each file system, so it further suggests that xfs is not likely the problem. With all this said, does anyone have any suggestions on this? Or even where to look in the raid0.c code (or elsewhere) to see what is going on? Thanks! Joe -- 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: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2
It does happen with 2.6.22 too. Do you see any known pattern in these extra bytes ? Best Regards Gerold 2a 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |[EMAIL PROTECTED]| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0002 2a 00 00 00 00 40 00 00 40 00 00 00 00 40 00 00 |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004 2a 00 00 00 00 80 00 00 40 00 00 00 00 80 00 00 |[EMAIL PROTECTED]| 00040010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0006 2a 00 00 00 00 c0 00 00 02 00 00 00 00 c0 00 00 |*...| 00060010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00061010 00 00 00 00 00 00 00 00 2a 00 00 00 00 c2 00 00 |*...| 00061020 40 00 00 00 00 c2 00 00 00 00 00 00 00 00 00 00 |@...| 00061030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 00081010 00 00 00 00 00 00 00 00 2a 00 00 00 01 02 00 00 |*...| 00081020 40 00 00 00 01 02 00 00 00 00 00 00 00 00 00 00 |@...| 00081030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000a1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 42 00 00 |*B..| 000a1020 40 00 00 00 01 42 00 00 00 00 00 00 00 00 00 00 |@B..| 000a1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 000c1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 82 00 00 |*...| 000c1020 40 00 00 00 01 82 00 00 00 00 00 00 00 00 00 00 |@...| 000c1030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * On Tuesday 26 February 2008 00:32:49 Andrew Morton wrote: >On Mon, 25 Feb 2008 20:05:22 +0100 Gerold Jury <[EMAIL PROTECTED]> wrote: >> Hello, >> >> I have two DVD drives, one connected to the SATA port (LG) the other to >> the IDE port (PHILIPS) of a via chipset. >> They are driven by VIA SATA support (SATA_VIA) and VIA PATA support >> (PATA_VIA). >> >> When I write an iso image to the drive on the SATA port /dev/sr0 it has >> some extra bytes on disk which make the disk unreadable. >> Writing to the IDE drive /dev/sr1 works well. >> >> A simple test with a DVD RAM and dd instead of growisofs >> >> dd if=/dev/zero of=/dev/srX bs=1024k count=10 >> >> and a readback afterwards >> >> dd if=/dev/srX of=imageX.bin bs=1024k count=10 >> >> gives me an all zero file from the IDE drive but a file >> full of probably scsi commands for the SATA drive and looks like >> >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || * >> 0002 2a 00 00 00 00 40 00 00 40 00 00 00 00 40 00 00 >> |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 >> 00 || * >> 0004 2a 00 00 00 00 80 00 00 40 00 00 00 00 80 00 00 >> |[EMAIL PROTECTED]| 00040010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 || * >> 0006 2a 00 00 00 00 c0 00 00 02 00 00 00 00 c0 00 00 >> |*...| 00060010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 || * >> 00061010 00 00 00 00 00 00 00 00 2a 00 00 00 00 c2 00 00 >> |*...| 00061020 40 00 00 00 00 c2 00 00 00 00 00 00 00 00 00 >> 00 |@...| 00061030 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 || * >> 00081010 00 00 00 00 00 00 00 00 2a 00 00 00 01 02 00 00 >> |*...| 00081020 40 00 00 00 01 02 00 00 00 00 00 00 00 00 00 >> 00 |@...| 00081030 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 || * >> 000a1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 42 00 00 >> |*B..| 000a1020 40 00 00 00 01 42 00 00 00 00 00 00 00 00 00 >> 00 |@B..| 000a1030 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 || * >> 000c1010 00 00 00 00 00 00 00 00 2a 00 00 00 01 82 00 00 >> |*...| 000c1020 40 00 00 00 01 82 00 00 00 00 00 00 00 00 00 >> 00 |@...| 000c1030 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 || >> >> I really need some hints to make the SATA drive usable, please. > >(added linux-ide) > >Did any earlier kernel work OK? 2.6.22? > >Thanks. > >> uname -a >> Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD >> Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux >> >> lspvi -v >> >> 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID >> Controller (rev 80) >> Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X/A8V >> Deluxe motherboard >> Flags: bus master, medium devsel, latency 64, IRQ 20 >> I/O ports at e800 [size=8] >> I/O ports at e400 [size=4] >> I/O ports at e000 [size=8] >> I/O ports at d800 [size=4] >> I/O ports at d400 [size=16] >> I/O ports at d00
[PATCH] x86_64: Seperate mmconf for fam10h out from setup_64.c
Seperate mmconf for fam10h out from setup_64.c
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 199f8b5..4f2b9ed 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -101,4 +101,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU) += pci-gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU)+= pci-calgary_64.o tce_64.o
obj-$(CONFIG_SWIOTLB) += pci-swiotlb_64.o
+
+obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o
endif
diff --git a/arch/x86/kernel/mmconf-fam10h_64.c
b/arch/x86/kernel/mmconf-fam10h_64.c
new file mode 100644
index 000..3789792
--- /dev/null
+++ b/arch/x86/kernel/mmconf-fam10h_64.c
@@ -0,0 +1,215 @@
+/*
+ * AMD Family 10h mmconfig enablement
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct pci_hostbridge_probe {
+ u32 bus;
+ u32 slot;
+ u32 vendor;
+ u32 device;
+};
+
+static u64 __cpuinitdata fam10h_pci_mmconf_base;
+static int __cpuinitdata fam10h_pci_mmconf_base_status;
+
+static struct pci_hostbridge_probe pci_probes[] __cpuinitdata = {
+ { 0, 0x18, PCI_VENDOR_ID_AMD, 0x1200 },
+ { 0xff, 0, PCI_VENDOR_ID_AMD, 0x1200 },
+};
+
+struct range {
+ u64 start;
+ u64 end;
+};
+
+static int __cpuinit cmp_range(const void *x1, const void *x2)
+{
+ const struct range *r1 = x1;
+ const struct range *r2 = x2;
+ int start1, start2;
+
+ start1 = r1->start >> 32;
+ start2 = r2->start >> 32;
+
+ return start1 - start2;
+}
+
+/*[47:0] */
+/* need to avoid (0xfd<<32) and (0xfe<<32), ht used space */
+#define FAM10H_PCI_MMCONF_BASE (0xfcULL<<32)
+#define BASE_VALID(b) ((b != (0xfdULL << 32)) && (b != (0xfeULL << 32)))
+static void __cpuinit get_fam10h_pci_mmconf_base(void)
+{
+ int i;
+ unsigned bus;
+ unsigned slot;
+ int found;
+
+ u64 val;
+ u32 address;
+ u64 tom2;
+ u64 base = FAM10H_PCI_MMCONF_BASE;
+
+ int hi_mmio_num;
+ struct range range[8];
+
+ /* only try to get setting from BSP */
+ /* -1 or 1 */
+ if (fam10h_pci_mmconf_base_status)
+ return;
+
+ if (!early_pci_allowed())
+ goto fail;
+
+ found = 0;
+ for (i = 0; i < ARRAY_SIZE(pci_probes); i++) {
+ u32 id;
+ u16 device;
+ u16 vendor;
+
+ bus = pci_probes[i].bus;
+ slot = pci_probes[i].slot;
+ id = read_pci_config(bus, slot, 0, PCI_VENDOR_ID);
+
+ vendor = id & 0x;
+ device = (id>>16) & 0x;
+ if (pci_probes[i].vendor == vendor &&
+ pci_probes[i].device == device) {
+ found = 1;
+ break;
+ }
+ }
+
+ if (!found)
+ goto fail;
+
+ /* SYS_CFG */
+ address = MSR_K8_SYSCFG;
+ rdmsrl(address, val);
+
+ /* TOP_MEM2 is not enabled? */
+ if (!(val & (1<<21))) {
+ tom2 = 0;
+ } else {
+ /* TOP_MEM2 */
+ address = MSR_K8_TOP_MEM2;
+ rdmsrl(address, val);
+ tom2 = val & (0xULL<<32);
+ }
+
+ if (base <= tom2)
+ base = tom2 + (1ULL<<32);
+
+ /*
+* need to check if the range is in the high mmio range that is
+* above 4G
+*/
+ hi_mmio_num = 0;
+ for (i = 0; i < 8; i++) {
+ u32 reg;
+ u64 start;
+ u64 end;
+ reg = read_pci_config(bus, slot, 1, 0x80 + (i << 3));
+ if (!(reg & 3))
+ continue;
+
+ start = (((u64)reg) << 8) & (0xffULL << 32); /* 39:16 on 31:8*/
+ reg = read_pci_config(bus, slot, 1, 0x84 + (i << 3));
+ end = (((u64)reg) << 8) & (0xffULL << 32); /* 39:16 on 31:8*/
+
+ if (!end)
+ continue;
+
+ range[hi_mmio_num].start = start;
+ range[hi_mmio_num].end = end;
+ hi_mmio_num++;
+ }
+
+ if (!hi_mmio_num)
+ goto out;
+
+ /* sort the range */
+ sort(range, hi_mmio_num, sizeof(struct range), cmp_range, NULL);
+
+ if (range[hi_mmio_num - 1].end < base)
+ goto out;
+ if (range[0].start > base)
+ goto out;
+
+ /* need to find one window */
+ base = range[0].start - (1ULL << 32);
+ if ((base > tom2) && BASE_VALID(base))
+ goto out;
+ base = range[hi_mmio_num - 1].end + (1ULL << 32);
+ if ((base > tom2) && BASE_VALID(base))
+ goto out;
+ /* need to find window between ranges */
+ if (hi_mmio_num > 1)
+ for (i = 0; i < hi_mmio_num - 1; i++) {
+ if (range[i + 1].start > (
Is there a memory block device?
I know that tmpfs is a memmory filesystem. Is there a possibility to create also a memory block device? Is there a possibility to create for example a 1 GB memory block device (from the RAM)? -- E-Mail sent with anti-spam site TrashMail.net! Free disposable email addresses: http://www.trashmail.net/ -- 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.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
Hi Adrian. On Tue, Feb 26, 2008 at 05:34:21PM +0200, Adrian Bunk ([EMAIL PROTECTED]) wrote: > Using ndelay() with a 64bit variable as parameter can result in build > errors like the following on some 32bit systems when it results in a > 64bit division: > > <-- snip --> > > ... > MODPOST 759 modules > ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! > > <-- snip --> > > Reported by Martin Michlmayr. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Yep, ndelay() uses division, thanks a lot Adrian for spotting this. Herbert, please apply. ACK. -- Evgeniy Polyakov -- 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: epoll design problems with common fork/exec patterns
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Davide Libenzi wrote:
> > On Sun, 28 Oct 2007, David Schwartz wrote:
> >
> >> Eric Dumazet wrote:
> >>
> >>> Events are not necessarly reported "by descriptors". epoll uses an opaque
> >>> field provided by the user.
> >>>
> >>> It's up to the user to properly chose a tag that will makes sense
> >>> if the user
> >>> app is playing dup()/close() games for example.
> >> Great. So the only issue then is that the documentation is confusing. It
> >> frequently uses the term "fd" where it means file. For example, it says:
> >>
> >> Q1 What happens if you add the same fd to an
> >> epoll_set
> >> twice?
> >>
> >> A1 You will probably get EEXIST. However, it is
> >> possible
> >> that two threads may add the same fd twice. This
> >> is
> >> a
> >> harmless condition.
> >>
> >> This gives no reason to think there's anything wrong with adding the same
> >> file twice so long as you do so through different descriptors. (One can
> >> imagine an application that does this to segregate read and write
> >> operations
> >> to avoid a race where the descriptor is closed from under a writer due to
> >> handling a fatal read error.) Obviously, that won't work.
> >
> > I agree, that is confusing. However, you can safely add two different file
> > descriptors pointing to the same file*, with different event masks, and
> > that will work as expected.
>
> So can I summarize what I understand:
>
> a) Adding the same file descriptor twice to an epoll set will cause an
> error (EEXIST).
Yes.
> b) In a separate message to linux-man, Chris Heath says that two threads
> *can't* add the same fd twice to an epoll set, despite what the existing
> man page text says. I haven't tested that, but it sounds to me as though
> it is likely to be true. Can you comment please Davide?
Yes, you can't add the same fd twice. Think about a DB where "file*,fd" is
the key.
> c) It is possible to add duplicated file descriptors referring to the same
> underlying open file description ("file *"). As you note, this can be a
> useful filtering technique, if the two file descriptors specify different
> masks.
>
> Assuming that is all correct, for man-pages-2.79, I've reworked the text
> for Q1/A1 as follows:
>
>Q1 What happens if you add the same file descriptor
> to an epoll set twice?
>
>A1 You will probably get EEXIST. However, it is pos-
> sible to add a duplicate (dup(2), dup2(2),
> fcntl(2) F_DUPFD, fork(2)) descriptor to the same
> epoll set. This can be a useful technique for
> filtering events, if the duplicate file descrip-
> tors are registered with different events masks.
>
> Seem okay Davide?
Looks sane to me.
- Davide
--
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.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 08:00:35PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 25 Feb 2008, Lukas Hejtmanek wrote: > > volume keys work. But anything through acpid does not. Even AC/battery > > switch > > is not signalized. So the bug may be somewhere else? > > Yeah, there is an EC-related regression in 2.6.25-rc3 that bites your > thinkpad. I don't have a link to it right now, but if you look for the > messages to LKML on the last 48h, you will find it. this one fixes all my troubles with thinkpad hotkeys in rc3. http://lkml.org/lkml/2008/2/25/400 > > [ 418.816087] thinkpad_acpi: requested hot key mask 0x, but > > firmware forced it to 0x00ff > > Don't do this. Just let the driver select the default mask, unless you > *really* know better. OK, thanks. -- Lukáš Hejtmánek -- 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] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: >On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> >wrote: >> On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: >> >> > >> >If you can't support that in your hardware you're supposed >> >to clear it. >> >> Hmm! How would a hardware vendor do that? That doesn't seem to be clear in >> the BKDG. (Well, this is the problem with undocumented features :() >> >any good sign for APIC_clustered box? there is apicid between cpus >even all cpu are quadcore and fully populated? I would suggest checking the SLIT distances -- On AMD boxes, if you have three different distances between nodes, then that system would be multiboard, and there is no way TSCs can be synced. On Intel boxes, if there are two different distances between nodes, then this would be a multi board/multi chassi box and TSCs won't be synced. This is a more generic solution and should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for now. It might need the same treatment as AMD) Comments? Kiran -- 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: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3
Andre Noll wrote: we are experiencing massive performance problems with two of our Linux servers that contain 3ware controllers on a Tyan mainboard and a couple of 1T disks. During the daily cron job that uses rsync to sync a 500G file system from another machine to the raid on the 3ware controller the load jumps up, and the machine becomes sluggish as hell. For example, an ssh login to that machine takes minutes to complete and ldap becomes unreliable while the rsync job is running. Even Nagios complains about the machine being down while rsync is running. You're putting your box under astronomical load. This is generally regarded as a bad idea, regardless of how well your storage controller is performing. Can you measure the single-threaded throughput (say, coping one huge file, and then syncing) to give us a baseline performance figure? rsync will happily peg your box, your network, and your cat if you let it. -- Chris -- 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: + rcu-split-listh-and-move-rcu-protected-lists-into-rculisth.patch added to -mm tree
Hi, Josh Triplett wrote: > [I did not see this patch go by on any mailing list, so I replied to > the -mm mail and CCed LKML.] > Well I'm pretty sure to have always CC'ed LKML, see for example: http://lkml.org/lkml/2008/2/19/150 http://lkml.org/lkml/2008/2/19/151 Thanks, Franck -- 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/
(regression) kernel/timeconst.h bugs with HZ=128
I see these warnings on 32 bit ARM systems: CC kernel/time.o kernel/time.c: In function 'msecs_to_jiffies': kernel/time.c:472: warning: integer constant is too large for 'long' type kernel/time.c: In function 'usecs_to_jiffies': kernel/time.c:487: warning: integer constant is too large for 'long' type Line 472: return ((u64)MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32) line 487: return ((u64)USEC_TO_HZ_MUL32 * u + USEC_TO_HZ_ADJ32) The problem seems to be that these constants from kernel/timeconst.h have too many digits: #define ONLY_THIRTYTWO_BITS 0x01234567 #define MSEC_TO_HZ_ADJ320x3f7ced916 #define USEC_TO_HZ_ADJ320xfffbce4217d Those *_ADJ32 constants should have "ULL" suffixes, yes? Adding that by hand resolves the problem, but only until the next time that header file gets regenerated. Someone with observable Perl-fu should fix this ... - 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/
[PATCH 2/2] ib fmr pool: flush used clean entries
Commit a3cd7d9070be417a21905c997ee32d756d999b38 (IB/fmr_pool:
ib_fmr_pool_flush() should flush all dirty FMRs) caused a
regression for iSER and was reverted in
e5507736c6449b3253347eed6f8ea77a28cf688e.
This change attempts to redo the original patch so that all used
FMR entries are flushed when ib_flush_fmr_pool() is called,
and other FMR users are not affected. Simply move used entries
from the clean list onto the dirty list before letting the
cleanup thread do its job.
Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
---
drivers/infiniband/core/fmr_pool.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/fmr_pool.c
b/drivers/infiniband/core/fmr_pool.c
index 4044fdf..06d502c 100644
--- a/drivers/infiniband/core/fmr_pool.c
+++ b/drivers/infiniband/core/fmr_pool.c
@@ -398,8 +398,23 @@ EXPORT_SYMBOL(ib_destroy_fmr_pool);
*/
int ib_flush_fmr_pool(struct ib_fmr_pool *pool)
{
- int serial = atomic_inc_return(&pool->req_ser);
+ int serial;
+ struct ib_pool_fmr *fmr, *next;
+
+ /*
+* The free_list holds FMRs that may have been used
+* but have not been remapped enough times to be dirty.
+* Put them on the dirty list now so that the cleanup
+* thread will reap them too.
+*/
+ spin_lock_irq(&pool->pool_lock);
+ list_for_each_entry_safe(fmr, next, &pool->free_list, list) {
+ if (fmr->remap_count > 0)
+ list_move(&fmr->list, &pool->dirty_list);
+ }
+ spin_unlock_irq(&pool->pool_lock);
+ serial = atomic_inc_return(&pool->req_ser);
wake_up_process(pool->thread);
if (wait_event_interruptible(pool->force_wait,
--
1.5.4.1
--
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 1/2] Revert "IB/fmr_pool: ib_fmr_pool_flush() should flush all dirty FMRs"
This reverts commit a3cd7d9070be417a21905c997ee32d756d999b38.
The original commit breaks iSER reliably, making it complain:
iser: iser_reg_page_vec:ib_fmr_pool_map_phys failed: -11
The FMR cleanup thread runs ib_fmr_batch_release() as dirty
entries build up. This commit causes clean but used FMR
entries also to be purged. During that process, another thread
can see that there are no free FMRs and fail, even though
there should always have been enough available.
Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
---
drivers/infiniband/core/fmr_pool.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/core/fmr_pool.c
b/drivers/infiniband/core/fmr_pool.c
index 7f00347..4044fdf 100644
--- a/drivers/infiniband/core/fmr_pool.c
+++ b/drivers/infiniband/core/fmr_pool.c
@@ -139,7 +139,7 @@ static inline struct ib_pool_fmr
*ib_fmr_cache_lookup(struct ib_fmr_pool *pool,
static void ib_fmr_batch_release(struct ib_fmr_pool *pool)
{
int ret;
- struct ib_pool_fmr *fmr, *next;
+ struct ib_pool_fmr *fmr;
LIST_HEAD(unmap_list);
LIST_HEAD(fmr_list);
@@ -158,20 +158,6 @@ static void ib_fmr_batch_release(struct ib_fmr_pool *pool)
#endif
}
- /*
-* The free_list may hold FMRs that have been put there
-* because they haven't reached the max_remap count.
-* Invalidate their mapping as well.
-*/
- list_for_each_entry_safe(fmr, next, &pool->free_list, list) {
- if (fmr->remap_count == 0)
- continue;
- hlist_del_init(&fmr->cache_node);
- fmr->remap_count = 0;
- list_add_tail(&fmr->fmr->list, &fmr_list);
- list_move(&fmr->list, &unmap_list);
- }
-
list_splice(&pool->dirty_list, &unmap_list);
INIT_LIST_HEAD(&pool->dirty_list);
pool->dirty_len = 0;
@@ -384,6 +370,11 @@ void ib_destroy_fmr_pool(struct ib_fmr_pool *pool)
i = 0;
list_for_each_entry_safe(fmr, tmp, &pool->free_list, list) {
+ if (fmr->remap_count) {
+ INIT_LIST_HEAD(&fmr_list);
+ list_add_tail(&fmr->fmr->list, &fmr_list);
+ ib_unmap_fmr(&fmr_list);
+ }
ib_dealloc_fmr(fmr->fmr);
list_del(&fmr->list);
kfree(fmr);
--
1.5.4.1
--
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/2] (was Re: [ofa-general] fmr pool free_list empty)
[EMAIL PROTECTED] wrote on Mon, 25 Feb 2008 15:02 -0800:
> Ugh.
[pw wrote:]
> > Looking at the FMR dirty list unmapping code in
> > ib_fmr_batch_release(), there is a section that pulls all the dirty
> > entries onto a list that it will later unmap and put back on the
> > free list.
>
> > But it also plans to unmap all the free entries that have ever been
> > remapped:
>
> Yes, this came from a3cd7d90 ("IB/fmr_pool: ib_fmr_pool_flush() should
> flush all dirty FMRs"). That solved a real problem for Olaf, because
> otherwise dirty FMRs with not at the max map count might never get
> invalidated. It's not exactly an optimization but rather a
> correctness issue, because RDS relies on killing mapping eventually.
>
> On the other hand, this behavior clearly does lead to the possibility
> of leaving the free list temporarily empty for stupid reasons.
>
> I don't see a really good way to fix this at the momemnt, need to
> meditate a little.
Adding CCs in case some iser users are not on the openfabrics list.
Original message is here:
http://lists.openfabrics.org/pipermail/general/2008-February/047111.html
This quoted commit is a regression for iSER. Not sure if it causes
problems for the other FMR user, SRP. It went in after v2.6.24.
Following this mail are two patches. One to revert the change, and
one to attempt to do Olaf's patch in such a way that it does not
cause problems for other FMR users.
I haven't tested the patches with RDS. It apparently isn't in the
tree yet. In fact, there are no users of ib_flush_fmr_pool() in the
tree, which is the only function affected by the second patch. But
iSER is working again in my scenario.
As a side note, I don't remember seeing this patch on the
openfabrics mailing list. Perhaps I missed it. Sometimes these
sorts of interactions can be spotted if proposed changes get wider
attention.
-- Pete
--
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: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
On Tue, Feb 26, 2008 at 11:48:29PM +0530, Kamalesh Babulal wrote:
> Adrian Bunk wrote:
> > On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
> >> Hi,
> >>
> >> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config
> >> option,
> >> the .config has been attached.
> >> ...
> >
> > Builds fine here.
> >
> > Local problem (e.g. disk full) on your machine?
> >
> > cu
> > Adrian
> >
> Hi Adrain,
Hi Kamalseh, ;)
> It Builds fine on another powerpc box with the same .config file, the problem
> seems to be with the gcc
> on that box, the reported build failure might have been the side effect of
> the same.
>
>
> drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
> drivers/md/raid6int8.c:185: error: unable to find a register to spill in
> class `FLOAT_REGS'
> drivers/md/raid6int8.c:185: error: this is the insn:
> (insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI
> (reg/v/f:DI 122 [ p ])
> (reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
> (reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
> (expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
> (nil)))
> drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
> make[2]: *** [drivers/md/raid6int8.o] Error 1
> make[1]: *** [drivers/md] Error 2
> make: *** [drivers] Error 2
>
> # gcc --version
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
this means your quite old vendor gcc has a bug.
> Thanks & Regards,
> Kamalesh Babulal,
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: 2.6.24-git: kmap_atomic() WARN_ON()
On Tue, 26 Feb 2008 11:32:24 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > * Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > >> + unsigned long flags; > >> + > >> + local_irq_save(flags); > > > > hm, couldnt we attach the irq disabling to some spinlock, in a natural > > way? Explicit flags fiddling is a PITA once we do things like threaded > > irq handlers, -rt, etc. > > Attaching the irq disabling to some spinlock is what would be > artificial... See the ahci.c patch earlier in this thread. It is taken > without spin_lock_irqsave() in the interrupt handler, and there is no > reason to disable interrupts for the entirety of the interrupt handler > run -- only the part where we call kmap. > > This is only being done to satisfy kmap_atomic's requirements, not libata's. > > I could add a "kmap lock" but that just seems silly. > It's a bit sad to disable interupts across a memset (how big is it?) just for the small proportion of cases which are accessing a highmem page. What you could do is to add an `unsigned long *flags' arg to ata_scsi_rbuf_get() and ata_scsi_rbuf_put(), and then, in ata_scsi_rbuf_get() do if (PageHighmem(page)) local_irq_disable(*flags); -- 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue, Feb 26, 2008 at 07:16:11PM +0100, Pavel Machek wrote: > On Tue 2008-02-26 13:10:01, Dave Jones wrote: > > On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote: > > > > > > if by 'custom' you mean the solution everyone agreed to work > > > > toward at the power management summit several years ago > > > > (hal/pm-utils) then, yes. > > > > > > I must have been on different summit... I believe it is bad to tie > > > s2ram to hal, because it makes testing on minimal system hard. > > > > > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps > > > Fedora already has his machine whitelisted... > > > > There is no s2ram. pm-suspend uses the white/black-lists in pm-utils. > > Remember that? The cross-distro package everyone agreed was a good idea > > so that every distro didn't have their own magic utility ? > > Well, we have cross-distro package, it is at suspend.sf.net , and it > can bring up video - which is kind of important. (It is single binary, > so it can be pagelocked -- which is important for s2disk). > > Plus it does not depend on HAL. Neither does pm-utils. Once again for the hard of thinking.. The mechanism belongs in pm-utils. HAL is just a fancy wrapper around that. Don't want/like hal? fine, a smaller wrapper around pm-suspend and friends is trivial (or even unnecessary if you're happy with running pm-suspend by hand) 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/
RE: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
> "David Schwartz" <[EMAIL PROTECTED]> writes: > > I don't know who told you that or why, but it's obvious nonsense, > Correct. > > Exports should be marked GPL if and only if they cannot be used > > except in a derivative work. If it is possible to use them > > without taking > > sufficient protectable expression, they should not be marked GPL. > This isn't very obvious to me. It may not be obvious, but it is the design and purpose of marking exports GPL. > The licence doesn't talk about GPL or non-GPL exports. It doesn't > restrict the use, only distribution of the software. One is free to > remove _GPL from the code and distribute it anyway (except perhaps for > some DMCA nonsense). That's true. The DMCA doesn't prevent it, since marking symbols is *not* a license enforcement mechanism. > If a code is a derivative work it has to be distributed (use is not > restricted) under GPL, EXPORT _GPL or not _GPL. Of course. > One may say _GPL is a strong indication that all users are > automatically a derivative works, but it's only that - indication. It > doesn't mean they are really derivative works and it doesn't mean a > module not using any _GPL exports isn't a derivative. Of course. (The only people who argue otherwise are the 'linking makes a derivative work' idiots.) > I think introducing these _GPL symbols was a mistake in the first place. Perhaps, since people seem to be trying to refight the same battles again. The agreement made when the feature was added was that EXPORT_GPL was not a license enforcement mechanism but was an indication that someone believed that any use of the symbol was possible only a derivative work that would need to be distributed under the GPL. > Actually I think the _GPL exports are really harmful - somebody > distributing a binary module may claim he/she doesn't violate the GPL > because the module uses only non-GPL exports. Anyone can argue anything. That would be an obviously stupid argument. Perhaps clearer documentation might be helpful, but the GPL speaks for itself. > OTOH GPL symbols give > _us_ exactly nothing. They serve as a warning and, as a practical matter, may make it a bit more difficult to violate the license. 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/
Re: [BUILD_FAILURE] Linux 2.6.25-rc3 - various unexported functions () on powerpc
Adrian Bunk wrote:
> On Tue, Feb 26, 2008 at 07:59:08PM +0530, Kamalesh Babulal wrote:
>> Hi,
>>
>> The 2.6.25-rc3 kernel build fails on powerpc with allyesconfig config option,
>> the .config has been attached.
>> ...
>
> Builds fine here.
>
> Local problem (e.g. disk full) on your machine?
>
> cu
> Adrian
>
Hi Adrain,
It Builds fine on another powerpc box with the same .config file, the problem
seems to be with the gcc
on that box, the reported build failure might have been the side effect of the
same.
drivers/md/raid6int8.c: In function `raid6_int8_gen_syndrome':
drivers/md/raid6int8.c:185: error: unable to find a register to spill in class
`FLOAT_REGS'
drivers/md/raid6int8.c:185: error: this is the insn:
(insn:HI 619 799 638 4 drivers/md/raid6int8.c:168 (set (mem:DI (plus:DI
(reg/v/f:DI 122 [ p ])
(reg/v:DI 66 ctr [orig:124 d ] [124])) [0 S8 A64])
(reg/v:DI 129 [ wp0 ])) 320 {*movdi_internal64} (nil)
(expr_list:REG_DEAD (reg/v:DI 129 [ wp0 ])
(nil)))
drivers/md/raid6int8.c:185: confused by earlier errors, bailing out
make[2]: *** [drivers/md/raid6int8.o] Error 1
make[1]: *** [drivers/md] Error 2
make: *** [drivers] Error 2
# gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
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: epoll and shared fd's
Michael Kerrisk <[EMAIL PROTECTED]> wrote: > a) I did a > > s/internal kernel handle/open file description/ > > since that is the POSIX term for the internal handle. > > b) It seems to me that you text doesn't quite make the point explicit > enough. I've tried to rewrite it; could you please check: > >A6 Yes, but be aware of the following point. A file > descriptor is a reference to an open file descrip- > tion (see open(2)). Whenever a descriptor is > duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, > or fork(2), a new file descriptor referring to the > same open file description is created. An open > file description continues to exist until all file > descriptors referring to it have been closed. The > epoll interface automatically removes a file > descriptor from an epoll set only after all the > file descriptors referring to the underlying open > file handle have been closed. This means that > even after a file descriptor that is part of an > epoll set has been closed, events may be reported > for that file descriptor if other file descriptors > referring to the same underlying file description > remain open. > > Does that seem okay? I plan to include the text in man-pages-2.79. It's hard to read for me, and probably very hard to read for others. -- 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.6.25-rc2-mm1 - fix mcount GPL bogosity.
> > From what I've seen its helped make binary > > module abusers more cautious. > > Those not using _GPL exports? In general. To be honest there is very little binary only stuff left now -- 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/
-next build logs
Stephen, the allmodconfig builds at http://kisskb.ellerman.id.au/kisskb/branch/9/ seem to lack a few drivers even though they are properly enabled in the respective config. Is it simply because everything is rebuilt on top of a previous build? Do you mail only errors to maintainers or also compiler warnings? Thanks, -- Stefan Richter -=-==--- --=- ==-=- http://arcgraph.de/sr/ -- 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue 2008-02-26 13:10:01, Dave Jones wrote: > On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote: > > > > if by 'custom' you mean the solution everyone agreed to work > > > toward at the power management summit several years ago > > > (hal/pm-utils) then, yes. > > > > I must have been on different summit... I believe it is bad to tie > > s2ram to hal, because it makes testing on minimal system hard. > > > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps > > Fedora already has his machine whitelisted... > > There is no s2ram. pm-suspend uses the white/black-lists in pm-utils. > Remember that? The cross-distro package everyone agreed was a good idea > so that every distro didn't have their own magic utility ? Well, we have cross-distro package, it is at suspend.sf.net , and it can bring up video - which is kind of important. (It is single binary, so it can be pagelocked -- which is important for s2disk). Plus it does not depend on HAL. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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.25-rc2-mm1] Oops in __kmalloc
On Tue, 26 Feb 2008 16:18:55 +0100 Jiri Slaby <[EMAIL PROTECTED]> wrote: > Hi, > > while booting up a notebook on 32 bit, this oopses appeared on the console > after ext3 fsck: > http://www.fi.muni.cz/~xslaby/sklad/mem_oops/ > > It's 2.6.25-rc2-mm1, I can't find similar reports, is this known or hardware > issue (unlikely, 2.6.24.2 seems to be OK)? I don't recall seeing a similar report and yes, it'll be a kernel bug. We've fixed a few things and it could be that this will just go away in next -mm. If it doesn't, a bisection search would be good, thanks. -- 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote: > > if by 'custom' you mean the solution everyone agreed to work > > toward at the power management summit several years ago > > (hal/pm-utils) then, yes. > > I must have been on different summit... I believe it is bad to tie > s2ram to hal, because it makes testing on minimal system hard. > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps > Fedora already has his machine whitelisted... There is no s2ram. pm-suspend uses the white/black-lists in pm-utils. Remember that? The cross-distro package everyone agreed was a good idea so that every distro didn't have their own magic utility ? sigh, I give up. 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/
Re: [(RT RFC) PATCH v2 5/9] adaptive real-time lock support
>>> On Tue, Feb 26, 2008 at 1:06 PM, in message
<[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Tue 2008-02-26 08:03:43, Gregory Haskins wrote:
>> >>> On Mon, Feb 25, 2008 at 5:03 PM, in message
>> <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]> wrote:
>>
>> >> +static inline void
>> >> +prepare_adaptive_wait(struct rt_mutex *lock, struct adaptive_waiter
>> > *adaptive)
>> > ...
>> >> +#define prepare_adaptive_wait(lock, busy) {}
>> >
>> > This is evil. Use empty inline function instead (same for the other
>> > function, there you can maybe get away with it).
>> >
>>
>> I went to implement your suggested change and I remembered why I did it this
> way: I wanted a macro so that the "struct adaptive_waiter" local variable
> will fall away without an #ifdef in the main body of code. So I have left
> this logic alone for now.
>
> Hmm, but inline function will allow dead code elimination, too, no?
I was getting compile errors. Might be operator-error ;)
>
> Anyway non-evil way to do it with macro is
>
> #define prepare_adaptive_wait(lock, busy) do {} while (0)
>
> ...that behaves properly in complex statements.
Ah, I was wondering why people use that. Will do. Thanks!
-Greg
--
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: [(RT RFC) PATCH v2 5/9] adaptive real-time lock support
On Tue 2008-02-26 08:03:43, Gregory Haskins wrote:
> >>> On Mon, Feb 25, 2008 at 5:03 PM, in message
> <[EMAIL PROTECTED]>, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> >> +static inline void
> >> +prepare_adaptive_wait(struct rt_mutex *lock, struct adaptive_waiter
> > *adaptive)
> > ...
> >> +#define prepare_adaptive_wait(lock, busy) {}
> >
> > This is evil. Use empty inline function instead (same for the other
> > function, there you can maybe get away with it).
> >
>
> I went to implement your suggested change and I remembered why I did it this
> way: I wanted a macro so that the "struct adaptive_waiter" local variable
> will fall away without an #ifdef in the main body of code. So I have left
> this logic alone for now.
Hmm, but inline function will allow dead code elimination, too, no?
Anyway non-evil way to do it with macro is
#define prepare_adaptive_wait(lock, busy) do {} while (0)
...that behaves properly in complex statements.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 patch v2] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 07:47:03PM +0200, Adrian Bunk wrote: > This patch moves the cris defconfigs to arch/cris/configs/ where they > belong. > > As a side effect they can now be used directly through e.g. > make ARCH=cris artpec_3_defconfig > > The default defconfig is set through KBUILD_DEFCONFIG. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Patch updated after I discovered an additional defconfig in > arch/cris/arch-v10/defconfig That could probably have been nuked, it's ancient. I'll put this in my queue. Thanks! /^JN - Jesper Nilsson -- Jesper Nilsson -- [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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue 2008-02-26 12:46:13, Dave Jones wrote: > On Tue, Feb 26, 2008 at 11:11:17AM +0100, Pavel Machek wrote: > > Hi! > > > > Andrew is trying to get s2ram to work on Fedora: > > > > > > > Please try s2ram, there's good chance it will just work. > > > > > > > > configure: error: Required libx86 was not found > > > > > > apt-get install libx86-dev? > > > > > > Alternatively, can you post dmidecode? Thinkpads usually work with > > > acpi_sleep=s3_bios,s3_mode ; and I can look up whitelist manually. > > > > ...unfortunately, it does not ship s2ram by default, and does not even > > carry its dependencies. > > > > Is there some custom mechanism to get suspend-to-ram to work on > > Fedora? > > if by 'custom' you mean the solution everyone agreed to work > toward at the power management summit several years ago > (hal/pm-utils) then, yes. I must have been on different summit... I believe it is bad to tie s2ram to hal, because it makes testing on minimal system hard. Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps Fedora already has his machine whitelisted... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 00/28] Swap over NFS -v16
On Tue, 26 Feb 2008 11:50:42 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > On Tue, 2008-02-26 at 17:03 +1100, Neil Brown wrote: > > On Saturday February 23, [EMAIL PROTECTED] wrote: > > > > What is the NFS and net people's take on all of this? > > > > Well I'm only vaguely an NFS person, barely a net person, sporadically > > an mm person, but I've had a look and it seems to mostly make sense. > > Thanks for taking a look, and giving such elaborate feedback. I'll try > and address these issues asap, but first let me reply to a few points > here. Neil's overview of what-all-this-is and how-it-all-works is really good. I'd suggest that you take it over, flesh it out and attach it firmly to the patchset. It really helps. -- 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/6] mempolicy: add MPOL_F_STATIC_NODES flag
> return do_mbind(start, len, mode, mode_flags, &nodes, flags); The intermingling of 'flags', 'mode' and 'mode_flags' to refer to the low bits, the high bits or all the bits of the flags field is handled fairly carefully in your patch, but can still be a bit difficult to keep track of which is which when reading. I'll wager not many readers can immediately say what the 'mode', 'mode_flags' and 'flags' refer to, in the above code snippet, for example. Do you have any suggestions on how to further improve the clarity of this code? -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- 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: Proposal for "proper" durable fsync() and fdatasync()
Jamie Lokier wrote: Jeff Garzik wrote: Nick Piggin wrote: Anyway, the idea of making fsync/fdatasync etc. safe by default is a good idea IMO, and is a bad bug that we don't do that :( Agreed... it's also disappointing that [unless I'm mistaken] you have to hack each filesystem to support barriers. It seems far easier to make sync_blkdev() Do The Right Thing, and magically make all filesystems data-safe. Well, you need ordered metadata writes, barriers _and_ flushes with some filesystems. Merely writing all the data pages than issuing a drive cache flush won't Do The Right Thing with those filesystems - someone already mentioned Btrfs, where it won't. Oh certainly. That's why we have a VFS :) fsync for NFS will look quite different, too. But I agree that your suggestion would make a superb default, for filesystems which don't provide their own function. Yep. That would immediately cover a bunch of filesystems. It's not optimal even then. Devices: On a software RAID, you ideally don't want to issue flushes to all drives if your database did a 1 block commit entry. (But they probably use O_DIRECT anyway, changing the rules again). But all that can be optimised in generic VFS code eventually. It doesn't need filesystem assistance in most cases. My own idea is that we create a FLUSH command for blkdev request queues, to exist alongside READ, WRITE, and the current barrier implementation. Then FLUSH could be passed down through MD or DM. 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: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3
Hello Andre, On Tuesday 26 February 2008 18:43:14 Andre Noll wrote: > Hi > > we are experiencing massive performance problems with two of our > Linux servers that contain 3ware controllers on a Tyan mainboard and > a couple of 1T disks. > > During the daily cron job that uses rsync to sync a 500G file system > from another machine to the raid on the 3ware controller the load > jumps up, and the machine becomes sluggish as hell. For example, an > ssh login to that machine takes minutes to complete and ldap becomes > unreliable while the rsync job is running. Even Nagios complains > about the machine being down while rsync is running. do you have the write-back cache of the controller enabled for your disks? When you disable this cache, the controller will also disable the disks, cause a write-performance between 3 to 8MB/s per disks. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH -- 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 patch] cris: proper defconfig setup
On Tue, Feb 26, 2008 at 07:28:47PM +0200, Adrian Bunk wrote: > This patch moves the cris defconfigs to arch/cris/configs/ where they > belong. > > As a side effect they can now directly be used through e.g. > make ARCH=cris artpec_3_defconfig > > The default defconfig is set through KBUILD_DEFCONFIG. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Jesper Nilsson <[EMAIL PROTECTED]> Thanks! /^JN - Jesper Nilsson -- Jesper Nilsson -- [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: IDE cdrom problem with PLEXTOR DVDR PX-608AL
On Tue, Feb 26, 2008 at 06:32:41PM +1000, Brad Rosser wrote: Hi Brad, > Hello Boris, Bart, > > On Tue, Feb 26, 2008 at 12:45 AM, Borislav Petkov > <[EMAIL PROTECTED]> wrote: > > > > On Mon, Feb 25, 2008 at 03:57:06PM +1000, Brad Rosser wrote: > > > > > > ... it would suggest the option 'hda=noprobe' was entered correctly? > > > > ok, let's try something else: change the line "#if 0" to "#if 1" at the > > beginning of kernel/params.c, it looks like: > > > > #if 0 > > #define DEBUGP printk > > #else > > #define DEBUGP(fmt, a...) > > #endif > > > > rebuild your kernel, and reboot with it. Then, please send me that boot > > log to > > see whether the kernel command line is being received from the boot loader > > and > > what exactly is getting parsed. Thanks. > > Boris, I've done that; the output is in attached file dmesg.debug.out. it seems that your boot loader is not supplying the kernel with the boot params properly as can be seen from the excerpt below: ... Kernel command line: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe Parsing ARGS: BOOT_IMAGE=linux_2.6.25rc2 ro root=900 md=0,/dev/sda5,/dev/sdb5 hda=noprobe Unknown argument: calling c03670ce Unknown argument: calling c03670ce Unknown argument: calling c03670ce Unknown argument: calling c03670ce md: Will configure md0 (super-block) from /dev/sda5,/dev/sdb5, below. Unknown argument: calling c03670ce ... and, as a result, the probing of hda still takes place. > It looks to me that the kernel still found the IDE DVD drive (hda) ... > in addition > to the system messages when the system was up I found the ide_cd_mod > module loaded on top of 'cdrom' as normal. > > > Please see whether you can apply the patch Bart just sent and if that > > still gets > > mangled and cannot be applied, consider making those changes to ide-cd.c > > by hand > > - after all, there are only several lines that need to be changed so it > > won't > > take that long. > > Bart, I was able to apply that patch file you attached with no problems, and > the > behaviour of the patched kernel changed as follows: > > - no more 'confused' messages, nor the rush of other critical messages > that accompanied a system hang on one out of four tests yesterday. > > - However, a new message that popped up twice; once after a few seconds > of network activity, and then about 15-20 seconds afterwards: > > hda: ide_cd_check_ireason: wrong transfer direction! > hda: ide_cd_check_ireason: wrong transfer direction! Bart, can we assume here that some of the nic interrupts somehow get handled by ide-cd or something gets mixed up there? > - also, I'm pretty sure that performance of both network and DVD drive > suffered. > > As to the last ... my new PC, on which I'm doing all this testing, has a > gigabit > Realtek NIC. It's hooked up via null UTP cable to my older machine which has > a 100Mb/s card. ethtool shows that they both auto-negotiate to run at 100Mb/s > full duplex. When I run my network test (pumping through /dev/zero across ssh > from the old machine to the new) the network stats tell me that I'm getting > 10MB/s out of the link, which is what I would expect. > > With the patched 2.6.25-rc2 kernel running with no activity reading the DVD > but the network going flat out (on the old PC's end) I noted that I was only > getting only 8.0 or 8.1 MB/sec, rather than the 10 MB/sec I've seen in the > other > tests.. There was no other network traffic or cpu load on the machine(s). > > Then, when I mounted a DVD disc and did a 'wc /mnt/*' of its contents > an iostat showed me that I was getting only about 6MB/sec out of the DVD > drive, which is less than I'd expect. As soon as I killed the network send > iostat's report zoomed up to roughly 10MB/sec. So it seemed to me that, > in addition to the 'wrong direction' messages, I was losing some performance > on both the NIC and the DVD drive. -- Regards/Gruß, Boris. -- 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: broken suspend in .2.6.25-rc3 on T61p (was Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p)
On Tue, Feb 26, 2008 at 11:11:17AM +0100, Pavel Machek wrote: > Hi! > > Andrew is trying to get s2ram to work on Fedora: > > > > > Please try s2ram, there's good chance it will just work. > > > > > > configure: error: Required libx86 was not found > > > > apt-get install libx86-dev? > > > > Alternatively, can you post dmidecode? Thinkpads usually work with > > acpi_sleep=s3_bios,s3_mode ; and I can look up whitelist manually. > > ...unfortunately, it does not ship s2ram by default, and does not even > carry its dependencies. > > Is there some custom mechanism to get suspend-to-ram to work on > Fedora? if by 'custom' you mean the solution everyone agreed to work toward at the power management summit several years ago (hal/pm-utils) then, yes. 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/
Re: arcmsr & areca-1660 - strange behaviour under heavy load
On Tue, 26 Feb 2008 10:35:31 +0100 (CET) Nikola Ciprich <[EMAIL PROTECTED]> wrote: > Hi > > On Sun, 24 Feb 2008, Andrew Morton wrote: > > Hi Andrew, > thanks a lot for reply, I'm attaching requested information. > please let me know if You need more information/testing, whatever. > I'll be glad to help. > BR > nik > > >> Areca support doesn't seem to be very interested in the problem :-( > > > > (cc's added) > > > > Please get the machine into this state of memory exhaustion then take > > copies of the output of the following, and send them via reply-to-all to > > this email: > > > > - cat /proc/meminfo > > > > - cat /proc/slabinfo > > > > - dmesg -c > /dev/null ; echo m > /proc/sysrq-trigger ; dmesg -c > > > > Thanks. Alas, that all looks OK to me. You never get any out-of-memory messages, and no oom-killing messages? Possibly what is happening here is that in this low-memory condition, some of the driver's internal memory-allocation attempts are failing, and the driver isn't correctly handling this. This is a rare situation which may well not have been hit in anyone else's testing. I expect that the Areca engineers will be able to reproduce this with a suitably small "mem=" kernel boot option. If not, they could perhaps investigate the kernel's fault-injection framework, which permits simulation of page allocation failures. -- 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 5/6] mempolicy: add MPOL_F_RELATIVE_NODES flag
David, Perhaps I missed it, but could you elaborate on what sort of testing these patches for MPOL_F_RELATIVE_NODES and MPOL_F_STATIC_NODES have received? The main reason I didn't push my version of these patches in December was I figured it would take a week or three of obsessive-compulsive testing to verify that we didn't break various corner cases of the mbind/mempolicy system call interface. In particular, do we know that Oracle works with this? At least in years past, when Andi was the primary developer here, he had some good and detailed awareness of what it took to keep Oracle happy with this NUMA memory policy apparatus. I don't know if we still have that awareness. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- 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.6.25-rc2-mm1 - fix mcount GPL bogosity.
Alan Cox <[EMAIL PROTECTED]> writes: >> Actually I think the _GPL exports are really harmful - somebody >> distributing a binary module may claim he/she doesn't violate the GPL >> because the module uses only non-GPL exports. OTOH GPL symbols give > > They can claim that anyway. The can claim to be alien life forms too. Claim > is not the same as legal decision. Sure but it may be now easier to convince the judge they are right. Of course if they aren't using GPL exports - if they are, perhaps harder. > From what I've seen its helped make binary > module abusers more cautious. Those not using _GPL exports? -- Krzysztof Halasa -- 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 2.6.22.19
On Tue, 26 Feb 2008 18:26:05 +0100 Oliver Pinter wrote: > Thank for your work in this serie or tree. Please edit your replies so that you don't send a 40 KB message that is actually only one line. --- ~Randy -- 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.25-rc1/2 CD/DVD burning broken
On Tue, Feb 26, 2008 at 03:52:13PM +0100, Andreas Schwab wrote: > Borislav Petkov <[EMAIL PROTECTED]> writes: > > > On Mon, Feb 25, 2008 at 11:08:55PM +0100, Andreas Schwab wrote: > >> Borislav Petkov <[EMAIL PROTECTED]> writes: > >> > >> > On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote: > >> >> "Kiyoshi Ueda" <[EMAIL PROTECTED]> writes: > >> >> > >> >> > I'm looking at this problem, but currently no idea why the conversion > >> >> > to blk_end_request causes it. > >> >> > >> >> cdrom_newpc_intr apparently never sets rq->sense_len. > >> >> > >> > > >> > actually it does, see the code chunk around line 1188 in 2.6.25-rc2, for > >> > example. > >> > >> Yes, it does, but it always adds zero. > > > > yep, true. Does that fix your dvd burning problem? > > Yes, sure. > > Andreas. Bart, please apply the enclosed patch since it fixes dvd burning with growisofs on Pioneer drives as reported by Andreas. Thanks. --- From: Andreas Schwab <[EMAIL PROTECTED]> Move counting of sense bytes into the transfer loop. Signed-off-by: Andreas Schwab <[EMAIL PROTECTED]> Acked-by: Borislav Petkov <[EMAIL PROTECTED]> --- drivers/ide/ide-cd.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- linux-2.6.25-rc3.orig/drivers/ide/ide-cd.c 2008-02-25 01:03:31.0 +0100 +++ linux-2.6.25-rc3/drivers/ide/ide-cd.c 2008-02-25 22:54:42.0 +0100 @@ -1182,11 +1182,10 @@ static ide_startstop_t cdrom_newpc_intr( else rq->data += blen; } + if (!write && blk_sense_request(rq)) + rq->sense_len += blen; } - if (write && blk_sense_request(rq)) - rq->sense_len += thislen; - /* * pad, if necessary */ -- Regards/Gruß, Boris. -- 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: Proposal for "proper" durable fsync() and fdatasync()
On Tue, 26 February 2008 17:29:13 +, Jamie Lokier wrote: > > You're right. Though, doesn't normal page writeback enqueue the COW > metadata changes? If not, how do they get written in a timely > fashion? It does. But this is not sufficient to guarantee that the pages in question have been safely committed to the device by the time sync_file_range() has returned. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.html -- 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/
h8300 drivers/serial/sh-sci.c compile error
Commit e108b2ca2349f510ce7d7f910eda89f71d710d84 broke the compilation of drivers/serial/sh-sci.c on h8300: <-- snip --> ... CC drivers/serial/sh-sci.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/serial/sh-sci.c:57:21: error: asm/sci.h: No such file or directory ... make[3]: *** [drivers/serial/sh-sci.o] Error 1 <-- snip --> 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 6/6] mempolicy: update NUMA memory policy documentation
+ MPOL_F_RELATIVE_NODES: This flag specifies that the nodemask passed + by the user should remain in the same context as it is for the + current task or VMA's set of accessible nodes after the memory + policy has been defined. + + Without this flag (and without MPOL_F_STATIC_NODES), anytime a + mempolicy is rebound because of a change in the set of + accessible nodes, the node (Preferred) or nodemask (Bind, + Interleave) is remapped to the new set of accessible nodes. + With this flag, the remap is done to ensure the context of the + previous nodemask with its set of allowed mems is preserved. Hmmm ... I've read this several times now ... still can't figure out what it's saying ;). And it doesn't really explain key aspects of MPOL_F_RELATIVE_NODES, such as that it provides cpuset relative numbering (use nodes 0..N-1, regardless of your current cpuset, to refer to the first N nodes in whatever is your current cpuset.) Perhaps we'd be further ahead of the game if you started with the documentation changes to Documentation/vm/numa_memory_policy.txt, in my patch: Date: Sun, 23 Dec 2007 22:24:02 -0600 From: Paul Jackson <[EMAIL PROTECTED]> To: David Rientjes <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [RFC] cpuset relative memory policies - second choice Message-Id: <[EMAIL PROTECTED]> Change MPOL_MASK_REL to MPOL_F_RELATIVE_NODES and similar changes. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.940.382.4214 -- 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: boot_delay broken ?
On Tue, 26 Feb 2008 17:09:48 +0800 Dave Young wrote:
> On Tue, Feb 26, 2008 at 01:59:31PM +0800, Dave Young wrote:
> > On Tue, Feb 26, 2008 at 1:48 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> > > On Tue, Feb 26, 2008 at 1:22 PM, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 25 Feb 2008 10:14:36 +0800 Dave Young wrote:
> > > >
> > > > > On Sun, Feb 24, 2008 at 8:46 AM, Dave Jones <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > The boot_delay switch seems to be behaving strangely in the
> > > > > > current -git. Setting it to =10 makes the output 'bursty'
> > > > > > it becomes slow for some printk's whilst others scroll by
> > > > > > at regular speed.
> > > > > > Setting it any higher than that seems to make it pause for
> > > > > > a really long time before it outputs any text at all.
> > > > >
> > > > > On my side there's this issue for a long time
> > > > > http://lkml.org/lkml/2007/8/8/79
> > > >
> > > > [http://marc.info/?l=linux-kernel&m=118655896515049&w=2]
> > > >
> > > > You asked questions and they were answered. Perhaps you didn't like
> > > > the answers.
> > >
> > > No, I like it. Thanks.
> > >
> > > But I still want to know why mdelay can not be used.
> > > is it not available for all archs or something else?
> > >
> > >
> > > >
> > > > Here's a question for you. What kernel boot options did you use?
> > > > Specifically, for lpj= and boot_delay= ?
> > >
> > > I tried boot_delay=100 and boot_delay=200 without lpj set, The result
> > > was really slow. It was better with lpj copied from dmesg, but was
> > > still slower then mdelay.
> >
> > Especially at the very beginning after the message "Booting the kernel",
> > I need to wait several minutes to see the afterwards messages
> >
> > >
> > > I think we can firstly use preset lpj, after delay calibrating just
> > > use the system lpj
> > >
> > >
> > >
> > > >
> > > > > >
> > > > > > x86 timer changes perhaps ?
> > > >
> > > >
> > > > ---
> > > > ~Randy
> > > >
> > >
>
> How about use loops_per_jiffy as following? With this patch at least
> for me the very long delay at the very begining does not occur.
>
> kernel/printk.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff -upr linux/kernel/printk.c linux.new/kernel/printk.c
> --- linux/kernel/printk.c 2008-02-26 16:54:23.0 +0800
> +++ linux.new/kernel/printk.c 2008-02-26 16:59:02.0 +0800
> @@ -173,24 +173,14 @@ __setup("log_buf_len=", log_buf_len_setu
> #ifdef CONFIG_BOOT_PRINTK_DELAY
>
> static unsigned int boot_delay; /* msecs delay after each printk during
> bootup */
> -static unsigned long long printk_delay_msec; /* per msec, based on
> boot_delay */
>
> static int __init boot_delay_setup(char *str)
> {
> - unsigned long lpj;
> - unsigned long long loops_per_msec;
> -
> - lpj = preset_lpj ? preset_lpj : 100;/* some guess */
> - loops_per_msec = (unsigned long long)lpj / 1000 * HZ;
> -
> get_option(&str, &boot_delay);
> if (boot_delay > 10 * 1000)
> boot_delay = 0;
>
> - printk_delay_msec = loops_per_msec;
> - printk(KERN_DEBUG "boot_delay: %u, preset_lpj: %ld, lpj: %lu, "
> - "HZ: %d, printk_delay_msec: %llu\n",
> - boot_delay, preset_lpj, lpj, HZ, printk_delay_msec);
> + printk(KERN_DEBUG "boot_delay: %u\n", boot_delay);
> return 1;
> }
> __setup("boot_delay=", boot_delay_setup);
> @@ -199,6 +189,9 @@ static void boot_delay_msec(void)
> {
> unsigned long long k;
> unsigned long timeout;
> + unsigned long long printk_delay_msec;
> +
> + printk_delay_msec = (unsigned long long)loops_per_jiffy / 1000 * HZ;
>
> if (boot_delay == 0 || system_state != SYSTEM_BOOTING)
> return;
> --
Hi Dave,
That might work, but IMO it requires someone to audit all
architectures to make sure that loops_per_jiffy has been calibrated
at that point in time (as I mentioned in http://lkml.org/lkml/2007/8/11/153).
I didn't do that and you said that you tested i386 only.
Maybe you can get Andrew to merge it into -mm for testing...
However, setting boot_delay=N without setting lpj=M is just not
advisable. The Kconfig help text for BOOT_PRINTK_DELAY tries to
say that. Maybe it needs to be stronger?
It is likely that you would also need to use "lpj=M" to preset
the "loops per jiffie" value.
See a previous boot log for the "lpj" value to use for your
system, and then set "lpj=M" before setting "boot_delay=N".
---
~Randy
--
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/
linux v2.6.22.20-op1-rc1
linux v2.6.22.20-op1-rc1 "stable" review patch what is this tree? it is my long term supported kernel, when i have time for it, i backported the most important fixes. http://repo.or.cz/w/linux-2.6.22.y-op.git rc -- Makefile | 2 +- arch/x86_64/mm/pageattr.c | 2 +- include/linux/page-flags.h | 4 ++-- kernel/irq/chip.c | 20 +++- mm/vmscan.c | 41 + 5 files changed, 64 insertions(+), 5 deletions(-) -- David Howells (1): MM: Fix macro argument substitution in PageHead() and PageTail() Ingo Molnar (1): x86_64: CPA, fix cache attribute inconsistency bug, v2.6.22 backport Kurt Garloff (1): make (low) swappiness safer to use Oliver Pinter (1): linux v2.6.22.20-op1-rc1 Thomas Gleixner (1): genirq: do not leave interupts enabled on free_irq -- Thanks, Oliver -- 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] x86: add the debugfs interface for the sysprof tool
On Tue, 26 Feb 2008 10:02:23 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > Anton - who has used oprofile to analyse and tune databases, JVMs, > > compilers and operating systems. Maybe I've been missing out on > > the killer app for all this time!!! > > it's OK if you use it full time and if you are amongst the 0.001% of the > developer population we call "the best kernel hackers on the planet" ;-) > > It sucks badly if you use it occasionally and have to re-learn its > non-trivial usage and its quirks every time. As it happens, most > userspace developers are in this second category. Nobody has in any way demonstrated that this is due to the design or implementation of oprofile's kernel component. -- 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: Proposal for "proper" durable fsync() and fdatasync()
Jörn Engel wrote: > On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote: > > > > > One interesting aspect of this comes with COW filesystems like btrfs or > > > logfs. Writing out data pages is not sufficient, because those will get > > > lost unless their referencing metadata is written as well. So either we > > > have to call fsync for those filesystems or add another callback and let > > > filesystems override the default implementation. > > > > Doesn't the ->fsync callback get called in the sys_fdatasync() case, > > with appropriate arguments? > > My paragraph above was aimed at the sync_file_range() case. fsync and > fdatasync do the right thing within the limitations you brought up in > this thread. sync_file_range() without further changes will only write > data pages, not the metadata required to actually access those data > pages. This works just fine for non-COW filesystems, which covers all > currently merged ones. > > With COW filesystems it is currently impossible to do sync_file_range() > properly. The problem is orthogonal to your's, I just brought it up > since you were already mentioning sync_file_range(). You're right. Though, doesn't normal page writeback enqueue the COW metadata changes? If not, how do they get written in a timely fashion? -- Jamie -- 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] x86_64: remove wrong setting about CONSTANT_TSC for intel cpu
On Mon, Feb 25, 2008 at 11:33 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > Yinghai Lu wrote: > >> which is the same. set_cpu_cap() is indeed the cleaner form to do this > >> so your patch is correct as a cleanup. > > set_cpu_cap is right > > == > > set_bit(X86_FEATURE_CONSTANT_TSC, &c->x86_capability); ===> is wrong > > should be > > set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); > > > > x86_capability is a array ... > > > > For an array, the & is optional and has no effect. good to know. YH -- 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.6.25-rc2-mm1 - fix mcount GPL bogosity.
On Tue, Feb 26, 2008 at 06:04:51PM +0100, Krzysztof Halasa wrote: > Actually I think the _GPL exports are really harmful - somebody > distributing a binary module may claim he/she doesn't violate the GPL > because the module uses only non-GPL exports. OTOH GPL symbols give They can claim that anyway. The can claim to be alien life forms too. Claim is not the same as legal decision. From what I've seen its helped make binary module abusers more cautious. Alan -- 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 2.6.22.19
Thank for your work in this serie or tree.
On 2/26/08, Greg KH <[EMAIL PROTECTED]> wrote:
> diff --git a/Makefile b/Makefile
> index 99c5e87..27acaf4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 22
> -EXTRAVERSION = .18
> +EXTRAVERSION = .19
> NAME = Holy Dancing Manatees, Batman!
>
> # *DOCUMENTATION*
> diff --git a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
> index 3c3c220..b7be5cf 100644
> --- a/arch/i386/kernel/entry.S
> +++ b/arch/i386/kernel/entry.S
> @@ -409,8 +409,6 @@ restore_nocheck_notrace:
> 1: INTERRUPT_RETURN
> .section .fixup,"ax"
> iret_exc:
> - TRACE_IRQS_ON
> - ENABLE_INTERRUPTS(CLBR_NONE)
> pushl $0# no error code
> pushl $do_iret_error
> jmp error_code
> diff --git a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
> index 0c0ceec..120a63b 100644
> --- a/arch/i386/kernel/ptrace.c
> +++ b/arch/i386/kernel/ptrace.c
> @@ -164,14 +164,22 @@ static unsigned long convert_eip_to_linear(struct
> task_struct *child, struct pt_
> u32 *desc;
> unsigned long base;
>
> - down(&child->mm->context.sem);
> - desc = child->mm->context.ldt + (seg & ~7);
> - base = (desc[0] >> 16) | ((desc[1] & 0xff) << 16) | (desc[1] &
> 0xff00);
> + seg &= ~7UL;
>
> - /* 16-bit code segment? */
> - if (!((desc[1] >> 22) & 1))
> - addr &= 0x;
> - addr += base;
> + down(&child->mm->context.sem);
> + if (unlikely((seg >> 3) >= child->mm->context.size))
> + addr = -1L; /* bogus selector, access would fault */
> + else {
> + desc = child->mm->context.ldt + seg;
> + base = ((desc[0] >> 16) |
> + ((desc[1] & 0xff) << 16) |
> + (desc[1] & 0xff00));
> +
> + /* 16-bit code segment? */
> + if (!((desc[1] >> 22) & 1))
> + addr &= 0x;
> + addr += base;
> + }
> up(&child->mm->context.sem);
> }
> return addr;
> diff --git a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c
> index 90da057..4995b92 100644
> --- a/arch/i386/kernel/traps.c
> +++ b/arch/i386/kernel/traps.c
> @@ -517,10 +517,12 @@ fastcall void do_##name(struct pt_regs * regs, long
> error_code) \
> do_trap(trapnr, signr, str, 0, regs, error_code, NULL); \
> }
>
> -#define DO_ERROR_INFO(trapnr, signr, str, name, sicode, siaddr) \
> +#define DO_ERROR_INFO(trapnr, signr, str, name, sicode, siaddr, irq) \
> fastcall void do_##name(struct pt_regs * regs, long error_code) \
> { \
> siginfo_t info; \
> + if (irq) \
> + local_irq_enable(); \
> info.si_signo = signr; \
> info.si_errno = 0; \
> info.si_code = sicode; \
> @@ -560,13 +562,13 @@ DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
> #endif
> DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
> DO_VM86_ERROR( 5, SIGSEGV, "bounds", bounds)
> -DO_ERROR_INFO( 6, SIGILL, "invalid opcode", invalid_op, ILL_ILLOPN,
> regs->eip)
> +DO_ERROR_INFO( 6, SIGILL, "invalid opcode", invalid_op, ILL_ILLOPN,
> regs->eip, 0)
> DO_ERROR( 9, SIGFPE, "coprocessor segment overrun",
> coprocessor_segment_overrun)
> DO_ERROR(10, SIGSEGV, "invalid TSS", invalid_TSS)
> DO_ERROR(11, SIGBUS, "segment not present", segment_not_present)
> DO_ERROR(12, SIGBUS, "stack segment", stack_segment)
> -DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN,
> 0)
> -DO_ERROR_INFO(32, SIGSEGV, "iret exception", iret_error, ILL_BADSTK, 0)
> +DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN,
> 0, 0)
> +DO_ERROR_INFO(32, SIGSEGV, "iret exception", iret_error, ILL_BADSTK, 0, 1)
>
> fastcall void __kprobes do_general_protection(struct pt_regs * regs,
> long error_code)
> diff --git a/arch/x86_64/kernel/ptrace.c b/arch/x86_64/kernel/ptrace.c
> index 8d89d8c..7fc0e73 100644
> --- a/arch/x86_64/kernel/ptrace.c
> +++ b/arch/x86_64/kernel/ptrace.c
> @@ -102,16 +102,25 @@ unsigned long convert_rip_to_linear(struct task_struct
> *child, struct pt_regs *r
> u32 *desc;
> unsigned long base;
>
> - down(&child->mm->context.sem);
> - desc = child->mm->context.ldt + (seg & ~7);
> - base = (desc[0] >> 16) | ((desc[1] & 0xff) << 16) | (desc[1] &
> 0xff00);
> + seg &= ~7UL;
>
> - /* 16-bit code segment? */
> - if (!((desc[1] >> 22) & 1))
> - addr &= 0x;
> - addr += base;
> + down(&child->mm->context.sem);
> + if (unlikely((seg >> 3) >= child->mm->context.size))
> + addr = -1L; /* bogus selector, access would fault */
>
Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?
On Tuesday 26 February 2008 06:10:34 Jiri Kosina wrote:
> On Mon, 25 Feb 2008, Jan Kara wrote:
> > Yes, exactly two of them. One is non-trivial to get rid of - it's
> > used for encoding of filename before we write it,
>
> Why can't we do just
>
>
>
> UDF: Optimize stack usage
>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
>
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index 112a5fb..706a2b5 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -336,7 +336,7 @@ static struct fileIdentDesc *udf_add_entry(struct inode
> *dir, {
> struct super_block *sb = dir->i_sb;
> struct fileIdentDesc *fi = NULL;
> - char name[UDF_NAME_LEN], fname[UDF_NAME_LEN];
> + char *name, *fname;
> int namelen;
> loff_t f_pos;
> int flen;
> @@ -352,6 +352,14 @@ static struct fileIdentDesc *udf_add_entry(struct
> inode *dir, struct extent_position epos = {};
> struct udf_inode_info *dinfo;
>
> + name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> + fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> +
> + if (!name || !fname) {
> + *err = -ENOMEM;
> + return NULL;
> + }
> +
Wouldn't it be better to check each individually, so you do wind up leaking a
buffer here if one gets allocated and the other doesn't ?
> if (dentry) {
> if (!dentry->d_name.len) {
> *err = -EINVAL;
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index f3ac4ab..42e3ba8 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -1345,7 +1345,7 @@ static void udf_load_logicalvolint(struct super_block
> *sb, kernel_extent_ad loc) * July 1, 1997 - Andrew E. Mileski
> * Written, tested, and released.
> */
> -static int udf_process_sequence(struct super_block *sb, long block,
> +static int noinline udf_process_sequence(struct super_block *sb, long
> block, long lastblock, kernel_lb_addr *fileset)
> {
> struct buffer_head *bh = NULL;
> --
> 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/
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
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.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
* Adrian Bunk <[EMAIL PROTECTED]> [2008-02-26 17:34]: > > MODPOST 759 modules > > ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! > > Fix below. Tested-by: Martin Michlmayr <[EMAIL PROTECTED]> -- Martin Michlmayr http://www.cyrius.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: [RFC] mmiotrace full patch, preview 1
Hey, Pekka,
A couple of little things I noticed...
> +static int post_kmmio_handler(unsigned long condition, struct pt_regs *regs)
> +{
> + int ret = 0;
> + struct kmmio_probe *probe;
> + struct kmmio_fault_page *faultpage;
> + struct kmmio_context *ctx = &get_cpu_var(kmmio_ctx);
> +
> + if (!ctx->active)
> + goto out;
Should that text read something like:
if (condition != DIE_TRAP || !ctx->active)
Presumably you won't be active if something else is going wrong, but one
never knows.
> +int register_kmmio_probe(struct kmmio_probe *p)
> +{
> + int ret = 0;
> + unsigned long size = 0;
> +
> + spin_lock_irq(&kmmio_lock);
> + kmmio_count++;
> + if (get_kmmio_probe(p->addr)) {
> + ret = -EEXIST;
> + goto out;
> + }
That only checks the first page; if the probed region partially overlaps
another one found later in memory, the registration will succeed.
Maybe you want to decrement kmmio_count if you decide to return -EEXIST
(or hold off on the increment until after the test)?
In general, I worry about what happens if an interrupt handler generates
traced MMIO traffic while a fault handler is active. It looks a lot
like the "all hell breaks loose" scenario mentioned in the comments. Is
there some way of preventing that which I missed? Otherwise, maybe,
should the ioremap() wrappers take an additional argument, being an IRQ
to disable while trace handlers are active?
jon
--
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.2-rt2
Steven Rostedt wrote: > > On Tue, 26 Feb 2008, Jan Kiszka wrote: >>> What's the NUMA topology? >> 4 nodes. I'm not sure if it is really NUMA related, but the same kernel >> runs that test as expected on a non-NUMA 2x2 box. >> >>> What tasks are running, and at what priorities? >> 40 pthreads, created with default parameters from a main thread which >> runs with default parameters as well. The threads simply run endless loops. >> >>> Those three idle CPUS, should they have tasks running on them? >> For sure, given the overload situation of the system (40x full load vs. >> 16 cores). Neither did we fiddle with any parameter of the system >> (knowingly, its a standard openSUSE 10.3 underneath) nor did we set >> thread affinities. >> > > Do you get different behaviour with 2.6.24.2? Last time I checked mainline (I think 2.6.24), it was fine. It was definitely fine for 2.6.23. But I'm going to revalidate this once the machine is free again (tomorrow). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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/
[demo patch/RFC] sleepy linux
Sleepy linux support, demo version, but it works on my thinkpad x60 ;-).
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/Documentation/power/sleepy.txt b/Documentation/power/sleepy.txt
new file mode 100644
index 000..a9caf05
--- /dev/null
+++ b/Documentation/power/sleepy.txt
@@ -0,0 +1,55 @@
+ Sleepy Linux
+
+
+Copyright 2007 Pavel Machek <[EMAIL PROTECTED]>
+ GPLv2
+
+Current Linux versions can enter suspend-to-RAM just fine, but only
+can do it on explicit request. But suspend-to-RAM is important, eating
+something like 10% of power needed for idle system. Starting suspend
+manually is not too convinient; it is not an option on multiuser
+machine, and even on single user machine, some things are not easy:
+
+1) Download this big chunk in mozilla, then go to sleep
+
+2) Compile this, then go to sleep
+
+3) You can sleep now, but wake me up in 8:30 with mp3 player
+
+Todays hardware is mostly capable of doing better: with correctly set
+up wakeups, machine can sleep and successfully pretend it is not
+sleeping -- by waking up whenever something interesting happens. Of
+course, it is easier on machines not connected to the network, and on
+notebook computers.
+
+Requirements:
+
+0) Working suspend-to-RAM, with kernel being able to bring video back.
+
+1) RTC clock that can wake up system
+
+2) Lid that can wake up a system,
+ or keyboard that can wake up system and does not loose keypress
+ or special screensaver setup
+
+3) Network card that is either down
+ or can wake up system on any packet (and not loose too many packets)
+
+How to use it
+~
+
+First, make sure your config is tiny enough that cpu sleeps at least
+five or so seconds between wakeups. You'll probably need to disable
+USB, make some kernel timers way longer than default and boot with
+init=/bin/bash.
+
+Then, enable SCSI powersave by something like:
+
+mount /sys
+echo auto >
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/level
+echo 3 >
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/power/autosuspend
+echo adisk > /sys/power/state
+mount / -oremount,commit=900
+
+Then, echo auto > /sys/power/state should enable sleepy support. Do it
+twice, and it will ignore open lid and sleep anyway.
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index a7d50a5..4c25613 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -187,6 +187,7 @@ void cpu_idle(void)
/* endless idle loop with no priority at all */
while (1) {
tick_nohz_stop_sched_tick();
+ detect_idle();
while (!need_resched()) {
void (*idle)(void);
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..0197b1f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -32,6 +32,7 @@
*
*/
+#define DEBUG
#include
#include
#include
@@ -259,8 +260,8 @@ static void ahci_fill_cmd_slot(struct ah
u32 opts);
#ifdef CONFIG_PM
static int ahci_port_suspend(struct ata_port *ap, pm_message_t mesg);
-static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
-static int ahci_pci_device_resume(struct pci_dev *pdev);
+int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
+int ahci_pci_device_resume(struct pci_dev *pdev);
#endif
static struct class_device_attribute *ahci_shost_attrs[] = {
@@ -268,6 +269,41 @@ static struct class_device_attribute *ah
NULL
};
+struct pci_dev *my_pdev;
+int autosuspend_enabled;
+
+struct sleep_disabled_reason ahci_active = {
+"ahci"
+};
+
+/* The host and its devices are all idle so we can autosuspend */
+static int autosuspend(struct Scsi_Host *host)
+{
+ if (my_pdev && autosuspend_enabled) {
+ printk("ahci: should autosuspend\n");
+ ahci_pci_device_suspend(my_pdev, PMSG_SUSPEND);
+ enable_auto_sleep(&ahci_active);
+ return 0;
+ }
+ printk("ahci: autosuspend disabled\n");
+ return -EINVAL;
+}
+
+/* The host needs to be autoresumed */
+static int autoresume(struct Scsi_Host *host)
+{
+ if (my_pdev && autosuspend_enabled) {
+ printk("ahci: should autoresume\n");
+ disable_auto_sleep(&ahci_active);
+ ahci_pci_device_resume(my_pdev);
+ return 0;
+ }
+ printk("ahci: autoresume disabled\n");
+ return -EINVAL;
+}
+
+
+
static struct scsi_host_template ahci_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -286,6 +322,8 @@ static struct scsi_host_template ahci_sh
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
.shost_attrs= ahci_shost_attrs,
+ .autosuspend= autosuspend,
+ .autoresume
Re: [RFC] mmiotrace full patch, preview 1
On Mon, Feb 25, 2008 at 09:42:00PM -0500, Pavel Roskin wrote: > It looks like a mutex, it acts like a mutex, but it isn't a mutex, it's a > trap for the unwary. Weird. I was annoyed by it before; now I see a > fellow developer actually getting into that trap. > > I'd say, rename DECLARE_MUTEX to DECLARE_SEMAPHORE and let external code be > fixed one way or another (i.e. stick with the "mutex" name or stick with > the semaphore functionality if it's really needed). It's a semaphore used as mutex. Until we got struct mutex this was perfectly fine and now we're phasing it out and will hopefully get rid of it soon. It just takes some time to convert all users. -- 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] ext3 freeze feature ver 0.2
On Feb 26, 2008 08:39 -0800, Eric Sandeen wrote:
> Takashi Sato wrote:
>
> > o Elevate XFS ioctl numbers (XFS_IOC_FREEZE and XFS_IOC_THAW) to the VFS
> > As Andreas Dilger and Christoph Hellwig advised me, I have elevated
> > them to include/linux/fs.h as below.
> > #define FIFREEZE_IOWR('X', 119, int)
> > #define FITHAW _IOWR('X', 120, int)
> > The ioctl numbers used by XFS applications don't need to be changed.
> > But my following ioctl for the freeze needs the parameter
> > as the timeout period. So if XFS applications don't want the timeout
> > feature as the current implementation, the parameter needs to be
> > changed 1 (level?) into 0.
>
> So, existing xfs applications calling the xfs ioctl now will behave
> differently, right? We can only keep the same ioctl number if the
> calling semantics are the same. Keeping the same number but changing
> the semantics is harmful, IMHO
Do we know what this parameter was supposed to mean?
We could special case "1" if needed to keep compatibility (documenting
this clearly), either making it == 0, or some very long timeout (1h
or whatever). A relatively minor wart I think.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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.25-rc1 xen pvops regression
On Fri, 2008-02-22 at 07:25 +, Ian Campbell wrote:
> On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
> >
> > Which it is on real hardware, because although it's not *reserved*
> > (type 2), it is certainly not made available as *normal memory* (type
> > 1). If Xen maps this as type 1 then I definitely see the problem.
> >
> > We can exclude type 1 memory from DMI scan, certainly.
>
> I'd been meaning to ask this. So the machines you have which don't
> describe 0xf as reserved also don't describe it as RAM? (I guess
> it's either a hole in the table or one of the other e820 types).
> Ian.
...
> >From 13bdb4ee9d80b83a81c3dbefa52464e511d1b4df Mon Sep 17 00:00:00 2001
> From: Ian Campbell <[EMAIL PROTECTED]>
> Date: Fri, 22 Feb 2008 07:17:14 +
> Subject: [PATCH] x86: Do not scan for DMI if the DMI region is marked as RAM
> by e820.
>
> Under Xen the memory at 0xf is regular RAM and so can potentially contain
> a
> page table and hence cannot be mapped. The e820 map given to guest reflects
> this.
>
> Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
...
> @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
> }
> }
> else {
> + if (e820_all_mapped(0xF, 0xF+0x1, E820_RAM))
> + goto out;
One issue with using the e820 map for this is that a Xen Dom0 will also
have this region marked as RAM in the e820 map, but will set up a fixmap
for it, allowing dmi_scan_machine() to map the region.
Cheers,
Mark.
--
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: Proposal for "proper" durable fsync() and fdatasync()
On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote: > > > One interesting aspect of this comes with COW filesystems like btrfs or > > logfs. Writing out data pages is not sufficient, because those will get > > lost unless their referencing metadata is written as well. So either we > > have to call fsync for those filesystems or add another callback and let > > filesystems override the default implementation. > > Doesn't the ->fsync callback get called in the sys_fdatasync() case, > with appropriate arguments? My paragraph above was aimed at the sync_file_range() case. fsync and fdatasync do the right thing within the limitations you brought up in this thread. sync_file_range() without further changes will only write data pages, not the metadata required to actually access those data pages. This works just fine for non-COW filesystems, which covers all currently merged ones. With COW filesystems it is currently impossible to do sync_file_range() properly. The problem is orthogonal to your's, I just brought it up since you were already mentioning sync_file_range(). Jörn -- Joern's library part 10: http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx -- 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.6.25-rc2-mm1 - fix mcount GPL bogosity.
> One may say _GPL is a strong indication that all users are > automatically a derivative works, but it's only that - indication. It > doesn't mean they are really derivative works and it doesn't mean a > module not using any _GPL exports isn't a derivative. Actually I think the _GPL exports are really harmful - somebody distributing a binary module may claim he/she doesn't violate the GPL because the module uses only non-GPL exports. OTOH GPL symbols give _us_ exactly nothing. -- Krzysztof Halasa -- 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: Proposal for "proper" durable fsync() and fdatasync()
Jeff Garzik wrote: > Nick Piggin wrote: > >Anyway, the idea of making fsync/fdatasync etc. safe by default is > >a good idea IMO, and is a bad bug that we don't do that :( > > Agreed... it's also disappointing that [unless I'm mistaken] you have > to hack each filesystem to support barriers. > > It seems far easier to make sync_blkdev() Do The Right Thing, and > magically make all filesystems data-safe. Well, you need ordered metadata writes, barriers _and_ flushes with some filesystems. Merely writing all the data pages than issuing a drive cache flush won't Do The Right Thing with those filesystems - someone already mentioned Btrfs, where it won't. But I agree that your suggestion would make a superb default, for filesystems which don't provide their own function. It's not optimal even then. Devices: On a software RAID, you ideally don't want to issue flushes to all drives if your database did a 1 block commit entry. (But they probably use O_DIRECT anyway, changing the rules again). But all that can be optimised in generic VFS code eventually. It doesn't need filesystem assistance in most cases. Apps: don't always want a full flush; sometimes a barrier would do. -- Jamie -- 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.2-rt2
On Tue, 26 Feb 2008, Jan Kiszka wrote: > >> > > > > What's the NUMA topology? > > 4 nodes. I'm not sure if it is really NUMA related, but the same kernel > runs that test as expected on a non-NUMA 2x2 box. > > > What tasks are running, and at what priorities? > > 40 pthreads, created with default parameters from a main thread which > runs with default parameters as well. The threads simply run endless loops. > > > > > Those three idle CPUS, should they have tasks running on them? > > For sure, given the overload situation of the system (40x full load vs. > 16 cores). Neither did we fiddle with any parameter of the system > (knowingly, its a standard openSUSE 10.3 underneath) nor did we set > thread affinities. > Do you get different behaviour with 2.6.24.2? -- Steve -- 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/
