Re: plain 2.6.21-rc5 (1) vs amanda (0)
* Gene Heskett <[EMAIL PROTECTED]> wrote: > Hi Ingo; > > Running 2.6.21-rc5 tonight. > > It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in > its version string) amanda is still a loser. [...] here 'is a loser' means: "tries to back up way too much stuff instead of doing a nice incremental backup like it does on 2.6.20.4", correct? since it appears to be caused by a kernel change, this is a serious regression in v2.6.21-to-be. > Good, 2.6.20.4 was running > sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting size via > gnutar for /usr/music level 0 > sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music > level 0: 1.239 > sendsize.20070331000507.debug:sendsize[762]: estimate size for /usr/music > level 0: 2466050 KB > sendsize.20070331000507.debug:sendsize[762]: time 249.605: getting size via > gnutar for /usr/music level 1 > sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music > level 1: 0.027 > sendsize.20070331000507.debug:sendsize[762]: estimate size for /usr/music > level 1: 80 KB > > Bad, 2.6.21-rc5 is running > sendsize.20070401000504.debug:sendsize[18465]: time 167.371: getting size via > gnutar for /usr/music level 0 > sendsize.20070401000504.debug:sendsize[18465]: estimate time for /usr/music > level 0: 0.398 > sendsize.20070401000504.debug:sendsize[18465]: estimate size for /usr/music > level 0: 2466050 KB > sendsize.20070401000504.debug:sendsize[18465]: time 167.773: getting size via > gnutar for /usr/music level 1 > sendsize.20070401000504.debug:sendsize[18465]: estimate time for /usr/music > level 1: 0.049 > sendsize.20070401000504.debug:sendsize[18465]: estimate size for /usr/music > level 1: 2448290 KB > > Yesterdays run, dated 20070331000507 were correct as that directory > hasn't been write accessed in a couple of months. > > Today's, dated 20070401000504, shows totally bogus figures for exactly > the same data. 'totally bogus figures' needs to be analyzed further. What system call or library calls returns incorrect data? > This effect I have isolated down to something in the 31 patches from > 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in > setting up the bisect to find it. If indeed its a kernel problem. > > This same effect has been present in any and every 2.6.21.* release. maybe it's some sort of timestamp problem, on the FS level? Ingo - 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: [-mm3 patch]Warning fix: check the return value of kobject_add etc.
2007/4/1, Andrew Morton <[EMAIL PROTECTED]>: On Sun, 1 Apr 2007 14:20:46 +0800 "Cong WANG" <[EMAIL PROTECTED]> wrote: > > > > > Also, please always prepare patches in `patch -p1' form, as per > > http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks. > > > > > > Sorry. I am confused with this. Does that mean I should make patches > _upon_ the root kernel source directory or first make a copy of the > original source code and then diff against the two dirs? But I was > told that "patches should be based _in_ the root kernel source > directory" and when only one file was modified just to diff it with > the original single file. (See Documentation/SubmittingPatches.) The headers should look like: --- a/arch/cris/kernel/crisksyms.c +++ a/arch/cris/kernel/crisksyms.c I don't know how people do that. One obvious way is to do cd /usr/src diff -u linux-orig/arch/cris/kernel/crisksyms.c linux-new/arch/cris/kernel/crisksyms.c other people probably alter the diff headers. Oh, thanks. I know. > And should I remake this patch? Sure, but please change it to perform correct error handling first. And test that error handling, if you can. That will involve adding artificial errors. I will remake it soon and send it again. In fact, I have just tested it roughly. And I don't how to produce artificial errors. Sorry, I hope someone can help me to test it carefully. - 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: [ck] [PATCH] sched: staircase deadline misc fixes
Am Mittwoch 28 März 2007 schrieb Prakash Punnoor: > Am Mittwoch 28 März 2007 schrieb Con Kolivas: > > I'm cautiously optimistic that we're at the thin edge of the bugfix wedge > > now. > > > > --- > > set_load_weight() should be performed after p->quota is set. This fixes a > > large SMP performance regression. > > Hi, I am using 2.6.21-rc5 with rsdl 0.37 and think I still see a regression > with my Athlon X2. Namely using this ac3 encoder > (http://aften.sourceforge.net/), which I parallelized in a simple way, with > my test sample I remember having encoding times of ~5.4sec with vanilla and > ~5.8 sec with rsdl - once the whole test wave is in cache. Otherwise you > can easily I/O limit the encoder. ;-) You need to get sources from svn > though. The current 0.06 release doesn't have threads support. BTW, I confirmed this regression. With vanilla 2.76.21-rc5 I get back my 5.4 secs with the test sample and two threads. Furtmermore for me vanilla actually feels nicer on my dual core, even with load - just subjectively that's why I ditched rsdl... Cheers, -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V pgpRah6vrej2y.pgp Description: PGP signature
Re: [KJ] my first janitorial
Pedram M wrote:
How about this one? Am I doing it right now?
If not, please try to explain more to me what I am
doing wrong.
You need a changelog entry (or explanation of what you're doing). You
need a signed-off-by line and your patch needs to apply to the root of
the kernel tree with -p1, something like:
-
Replace deprecated pci_find_device call with pci_get_device.
Signed-Off-By: Pedram M <[EMAIL PROTECTED]>
--- linux-2.6.20.3.orig/path/to/file.c 2006-06-24 09:41:08.0
+0200
+++ linux-2.6.20.3/path/to/file.c 2006-07-15 21:01:57.0 +0200
@@ -4760,7 +4760,7 @@
for (i = 0; i < NR_CARDS; i++) {
/* look for a Cyclades card by vendor and device id */
while ((device_id = cy_pci_dev_id[dev_index]) != 0) {
- if ((pdev = pci_find_device(PCI_VENDOR_ID_CYCLADES,
+ if ((pdev = pci_get_device(PCI_VENDOR_ID_CYCLADES,
device_id, pdev)) == NULL) {
dev_index++;/* try next device id */
} else {
-
And your subject needs to please include the string "[PATCH]", something
like: [PATCH] path/to/file.c: pci_find_device cleanup
However, as pointed out, the code itself is incorrect, for every
pci_get_device there also needs to be a call to pci_put_device in order
to maintain reference counts.
Your client does not seem to be clobbering the patch itself and
maintains tabs and line wrapping (unlike my client).
Jaco
-
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: [-mm3 patch]Warning fix: check the return value of kobject_add etc.
On Sun, 1 Apr 2007 14:20:46 +0800 "Cong WANG" <[EMAIL PROTECTED]> wrote: > > > > > Also, please always prepare patches in `patch -p1' form, as per > > http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks. > > > > > > Sorry. I am confused with this. Does that mean I should make patches > _upon_ the root kernel source directory or first make a copy of the > original source code and then diff against the two dirs? But I was > told that "patches should be based _in_ the root kernel source > directory" and when only one file was modified just to diff it with > the original single file. (See Documentation/SubmittingPatches.) The headers should look like: --- a/arch/cris/kernel/crisksyms.c +++ a/arch/cris/kernel/crisksyms.c I don't know how people do that. One obvious way is to do cd /usr/src diff -u linux-orig/arch/cris/kernel/crisksyms.c linux-new/arch/cris/kernel/crisksyms.c other people probably alter the diff headers. > And should I remake this patch? Sure, but please change it to perform correct error handling first. And test that error handling, if you can. That will involve adding artificial errors. - 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.21-rc5-mm3 - no boot, "address not 2M aligned"
On Sun, 01 Apr 2007 00:15:51 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > Does anyone know how to express the constraint of a 2M aligned number in > Kconfig? Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which would be a bit hard to use. Adding a BUILD_BUG_ON which checks this constraint might help. Plus a useful comment right at the BUILD_BUG_ON site explaining what to do about it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5: Thinkpad X60 gets critical thermal shutdowns
Alexey Starikovskiy wrote: > Could you try to unload or disable hardware sensors and check if it > helps? > CONFIG_I2C=m > CONFIG_I2C_ALGOBIT=m > CONFIG_I2C_ALGOPCA=m > CONFIG_I2C_I810=m > CONFIG_I2C_PIIX4=m > CONFIG_SENSORS_DS1337=m > CONFIG_SENSORS_DS1374=m > CONFIG_SENSORS_EEPROM=m > CONFIG_SENSORS_PCF8574=m > CONFIG_SENSORS_PCA9539=m > CONFIG_SENSORS_PCF8591=m > CONFIG_SENSORS_MAX6875=m That seems to have helped. If I watch /proc/acpi/thermal_zone/THM?/temperature, it seems stable even under load. I didn't try watching the thermal_zones when these options were enabled, but I presume the temperature was not controlled for it to hit 128 degC. What's going on here? Does reading an i2c sensor from the kernel prevent something else from doing it? 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: [-mm3 patch]Warning fix: check the return value of kobject_add etc.
2007/4/1, Andrew Morton <[EMAIL PROTECTED]>:
On Sat, 31 Mar 2007 10:30:31 +0800 "Cong WANG" <[EMAIL PROTECTED]> wrote:
> Since kobject_add, sysfs_create_link and sysfs_create_file are marked
> as '__must_check', so we must always check their return values, or gcc
> will give us warnings.
>
> Signed-off-by: Cong WANG <[EMAIL PROTECTED]>
>
> ---
> --- fs/partitions/check.c.orig2007-03-30 21:35:45.0 +0800
> +++ fs/partitions/check.c 2007-03-30 21:49:53.0 +0800
> @@ -385,10 +385,16 @@ void add_partition(struct gendisk *disk,
> p->kobj.parent = >kobj;
> p->kobj.ktype = _part;
> kobject_init(>kobj);
> - kobject_add(>kobj);
> + if (kobject_add(>kobj)) {
> + kfree(p);
> + return;
> + }
> if (!disk->part_uevent_suppress)
> kobject_uevent(>kobj, KOBJ_ADD);
> - sysfs_create_link(>kobj, _subsys.kset.kobj, "subsystem");
> + if (sysfs_create_link(>kobj, _subsys.kset.kobj, "subsystem")) {
> + kfree(p);
> + return;
> + }
> if (flags & ADDPART_FLAG_WHOLEDISK) {
> static struct attribute addpartattr = {
> .name = "whole_disk",
> @@ -396,7 +402,10 @@ void add_partition(struct gendisk *disk,
> .owner = THIS_MODULE,
> };
>
> - sysfs_create_file(>kobj, );
> + if (sysfs_create_file(>kobj, )) {
> + kfree(p);
> + return;
> + }
> }
> partition_sysfs_add_subdir(p);
> disk->part[part-1] = p;
Well yes, but the point here it to fix kernel bugs, not to just make the
warnings go away.
The bugs here are that the effects of the kobject_add() and the
sysfs_create_link() are not undone on the error path.
Thanks for your point.
Also, please always prepare patches in `patch -p1' form, as per
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks.
Sorry. I am confused with this. Does that mean I should make patches
_upon_ the root kernel source directory or first make a copy of the
original source code and then diff against the two dirs? But I was
told that "patches should be based _in_ the root kernel source
directory" and when only one file was modified just to diff it with
the original single file. (See Documentation/SubmittingPatches.)
Can you help out? And should I remake this patch? Thanks again!
-
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: my first janitorial
Hi,
On Sat, Mar 31, 2007 at 10:24:12PM -0700, Pedram M wrote:
> How about this one? Am I doing it right now?
> If not, please try to explain more to me what I am
> doing wrong.
You have made several mistakes :
- you must select an appropriate subject for your mail. Nobody cares
that it is your first mail, what they care about is the problem you
are trying to fix and what it applies to. Preferably start your
subject with [PATCH] so that people can quickly notice it without
having to open it first.
- you did not send a description of your patch. It is important to
have a full description, it can be from 1 line to 1 page depending
on the complexity of the issue. It is important to explain why you
think you are right so that people can argue if they don't agree.
Please also try to be as factual as possible, because your message
will become the commit message. It means that sentences such as
"I think that ..." are not the best we can write.
- you must sign your patch. For this, add a "Signed-Off-By:" footer.
Take a look at other patches for this.
- your patch was cut and cannot apply to anything. A proper patch starts
with line beginning with "---" line, followed by a line with "+++",
both indicating the file your patch is supposed to apply to. Make your
patch with one level directory for the kernel so that it can apply with
"patch -p1". For instance:
$ diff -u linux-2.6.20/Makefile linux-2.6.20-mine/Makefile
Another solution is to use '.' as the directory, in order to add one
directory level for "patch -p1" to be happy :
$ diff -u ./Makefile.orig ./Makefile
Hoping this helps,
Willy
> @@ -4760,7 +4760,7 @@
> for (i = 0; i < NR_CARDS; i++) {
> /* look for a Cyclades card by vendor and device id */
> while ((device_id = cy_pci_dev_id[dev_index]) != 0) {
> - if ((pdev = pci_find_device(PCI_VENDOR_ID_CYCLADES,
> + if ((pdev = pci_get_device(PCI_VENDOR_ID_CYCLADES,
> device_id, pdev)) ==
> NULL) {
> dev_index++;/* try next device id */
> } else {
> -
> 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: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
[EMAIL PROTECTED] writes: > I had the same with this .config from 2.6.21-rc3-mm2 after running 'make > oldconfig' and answering N to all new questions. Then, I tweaked some > items, mostly to see if there was an 'align kernel' item in there > somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this > 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted > 'CONFIG_PHYSICAL_START', maybe that's it? That looks like it. Does anyone know how to express the constraint of a 2M aligned number in Kconfig? The original plan was to remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE on x86_64 because after this series they have no cost and thus just lead to a little more confusion. However because we don't tag vmlinux as ET_DYN and Xen has some use for kernel built at different physical addresses (or at least loaded at them), and because Xen directly loads vmlinux he kept those options. If we can find a place to stick it into the build doing a little post processing of vmlinux so that it has the proper ELF header type (ET_DYN not ET_EXEC) would be useful and allow us to remove those extra confusing options. If I have a spare moment I will take a look. Since there is confusion it is probably worth removing the unnecessary confusing options if we can instead of supporting the full confusion. Doing the same for i386 would be a little harder but with Dave Miller's suggestions for Xen and leaving the functions to be replaced unlinked so the compiler generates efficient calls and then doing linking magic to fill in the pieces at boot looks about as tricky as moving the relocation logic for i386 into vmlinux as well. So it seems feasible and possibly worth doing. 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: [patch 3/13] signal/timer/event fds v9 - signalfd wire up i386 arch ...
On Sat, 31 Mar 2007 13:09:29 -0700 Davide Libenzi wrote: > This patch wire the signalfd system call to the i386 architecture. > all your x86 syscall numbers got incremented due to lutiemsat(). The revoke sycalls got incremented by three. - 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] VMI paravirt-ops bugfix for 2.6.21
Andi Kleen wrote: I think I would prefer you touch the generic code. This new hook is ugly. What new hook? The hook has been there for sometime, and now we are using it to fix a bug. I do not want to touch generic or arch code at this point in the 2.6.21 release. And the lazy mode is currently only used by VMI anyways, isn't it? So you shouldn't impact anybody else Yes, but if I don't touch arch code, I won't even affect native. I do not want to risk any instability, despite how easy it would be to do what you and others have asked, I don't think it is appropriate at -rc5 stage. Thanks, Zach - 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.21-rc5-mm3 - no boot, "address not 2M aligned"
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sat, Mar 31, 2007 at 12:53:03AM -0700 > On Sat, 31 Mar 2007 09:12:20 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote: > > > A new error for me: > > > > loading 2.6.21rc5mm3 > > Bios data check successful > > Destination address not 2M aligned > > -- System halted > > > > > > This is using the same lilo that loads 2.6.18rc5mm1 fine. > > x86-64 > > > > That's new. Does changing the value of CONFIG_RELOCATABLE change anything? > > Please send the .config. > I had the same with this .config from 2.6.21-rc3-mm2 after running 'make oldconfig' and answering N to all new questions. Then, I tweaked some items, mostly to see if there was an 'align kernel' item in there somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted 'CONFIG_PHYSICAL_START', maybe that's it? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc3-mm2 # Tue Mar 13 18:35:46 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set 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_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # 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 is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=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=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_NR_CPUS=2 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x10 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set #
Re: [3/4] 2.6.21-rc5: known regressions (v2)
Adrian Bunk wrote: > Subject: ThinkPad X60: resume no longer works (PCI related?) > References : http://lkml.org/lkml/2007/3/13/3 > Submitter : Dave Jones <[EMAIL PROTECTED]> > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Caused-By : PCI merge > commit 78149df6d565c36675463352d0bfeb02b7a7 > Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> > Rafael J. Wysocki <[EMAIL PROTECTED]> > Status : problem is being debugged > I know this is currently a subject of discussion on lkml, but I wanted to confirm that booting with "hpet=disable" fixes this, and resume works for me. It ends up using acpi_pm as the clocksource. 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: [-mm3 patch]Warning fix: check the return value of kobject_add etc.
On Sat, 31 Mar 2007 10:30:31 +0800 "Cong WANG" <[EMAIL PROTECTED]> wrote:
> Since kobject_add, sysfs_create_link and sysfs_create_file are marked
> as '__must_check', so we must always check their return values, or gcc
> will give us warnings.
>
> Signed-off-by: Cong WANG <[EMAIL PROTECTED]>
>
> ---
> --- fs/partitions/check.c.orig2007-03-30 21:35:45.0 +0800
> +++ fs/partitions/check.c 2007-03-30 21:49:53.0 +0800
> @@ -385,10 +385,16 @@ void add_partition(struct gendisk *disk,
> p->kobj.parent = >kobj;
> p->kobj.ktype = _part;
> kobject_init(>kobj);
> - kobject_add(>kobj);
> + if (kobject_add(>kobj)) {
> + kfree(p);
> + return;
> + }
> if (!disk->part_uevent_suppress)
> kobject_uevent(>kobj, KOBJ_ADD);
> - sysfs_create_link(>kobj, _subsys.kset.kobj, "subsystem");
> + if (sysfs_create_link(>kobj, _subsys.kset.kobj, "subsystem")) {
> + kfree(p);
> + return;
> + }
> if (flags & ADDPART_FLAG_WHOLEDISK) {
> static struct attribute addpartattr = {
> .name = "whole_disk",
> @@ -396,7 +402,10 @@ void add_partition(struct gendisk *disk,
> .owner = THIS_MODULE,
> };
>
> - sysfs_create_file(>kobj, );
> + if (sysfs_create_file(>kobj, )) {
> + kfree(p);
> + return;
> + }
> }
> partition_sysfs_add_subdir(p);
> disk->part[part-1] = p;
Well yes, but the point here it to fix kernel bugs, not to just make the
warnings go away.
The bugs here are that the effects of the kobject_add() and the
sysfs_create_link() are not undone on the error path.
Also, please always prepare patches in `patch -p1' form, as per
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, 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: [PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)
On Sat, 31 Mar 2007 01:08:14 +0200 "Paolo 'Blaisorblade' Giarrusso" <[EMAIL
PROTECTED]> wrote:
> set_up_list3s is not __init and references initkmem_list3.
>
> Also, kmem_cache_create calls setup_cpu_cache which calls set_up_list3s. The
> state machine _may_ prevent the code from accessing this data after freeing
> initdata (it makes sure it's used only up to boot), so this warning may be a
> false positive.
>
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> ---
>
> mm/slab.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 0934f8d..0772faf 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -305,7 +305,7 @@ struct kmem_list3 {
> * Need this for bootstrapping a per node allocator.
> */
> #define NUM_INIT_LISTS (2 * MAX_NUMNODES + 1)
> -struct kmem_list3 __initdata initkmem_list3[NUM_INIT_LISTS];
> +struct kmem_list3 initkmem_list3[NUM_INIT_LISTS];
> #define CACHE_CACHE 0
> #define SIZE_AC 1
> #define SIZE_L3 (1 + MAX_NUMNODES)
Yes, I think this is a flase positive - we'll never touch initkmem_list3[]
after free_initmem() because of the transitions of g_cpucache_up.
(In which case set_up_list3s() shoud be __init, too?)
Christoph, I think you looked at this previously?
-
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: my first janitorial
How about this one? Am I doing it right now?
If not, please try to explain more to me what I am
doing wrong.
@@ -4760,7 +4760,7 @@
for (i = 0; i < NR_CARDS; i++) {
/* look for a Cyclades card by vendor and device id */
while ((device_id = cy_pci_dev_id[dev_index]) != 0) {
- if ((pdev = pci_find_device(PCI_VENDOR_ID_CYCLADES,
+ if ((pdev = pci_get_device(PCI_VENDOR_ID_CYCLADES,
device_id, pdev)) == NULL) {
dev_index++;/* try next device id */
} else {
-
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/
plain 2.6.21-rc5 (1) vs amanda (0)
Hi Ingo; Running 2.6.21-rc5 tonight. It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in its version string) amanda is still a loser. >From an amstatus report as the back up is just getting started, and amanda has completed the estimates: [EMAIL PROTECTED] Daily]# amstatus Daily Using /usr/local/var/amanda/Daily/amdump from Sun Apr 1 00:05:04 EDT 2007 coyote:/GenesAmandaHelper-0.5 1 planner: [dumps way too big, 156684 KB, must skip incremental dumps] coyote:/GenesAmandaHelper-0.6 4 planner: [dumps way too big, 780226 KB, must skip incremental dumps] coyote:/bin 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/boot 13m wait for dumping coyote:/dev 00m wait for dumping coyote:/etc 2 planner: [dumps way too big, 18533 KB, must skip incremental dumps] coyote:/home 0 858m wait for dumping coyote:/lib 1 planner: [dumps way too big, 100080 KB, must skip incremental dumps] coyote:/opt 1 2192m wait for dumping coyote:/root 2 planner: [dumps way too big, 1684448 KB, must skip incremental dumps] coyote:/sbin 10m wait for dumping coyote:/tmp 1 planner: [dumps way too big, 8972 KB, must skip incremental dumps] coyote:/usr/X11R6 1 planner: [dumps way too big, 232 KB, must skip incremental dumps] coyote:/usr/bin 1 planner: [dumps way too big, 26030 KB, must skip incremental dumps] coyote:/usr/dlds 1 planner: [dumps way too big, 93030 KB, must skip incremental dumps] coyote:/usr/dlds-misc 2 155m wait for dumping coyote:/usr/dlds-rpms 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/usr/dlds-tgzs 10m wait for dumping coyote:/usr/games 00m wait for dumping coyote:/usr/include 1 85m wait for dumping coyote:/usr/kerberos 1 planner: [dumps way too big, 1360 KB, must skip incremental dumps] coyote:/usr/lib 3 planner: [dumps way too big, 337013 KB, must skip incremental dumps] coyote:/usr/libexec 1 planner: [dumps way too big, 20138 KB, must skip incremental dumps] coyote:/usr/local 1 planner: [dumps way too big, 42374 KB, must skip incremental dumps] coyote:/usr/man 1 planner: [dumps way too big, 710 KB, must skip incremental dumps] coyote:/usr/movies1 7271m dumping 5298m ( 72.87%) (0:12:48) coyote:/usr/music 1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps] coyote:/usr/pix 1 planner: [dumps way too big, 856480 KB, must skip incremental dumps] coyote:/usr/sbin 1 planner: [dumps way too big, 2305 KB, must skip incremental dumps] coyote:/usr/share 2 planner: [dumps way too big, 348843 KB, must skip incremental dumps] coyote:/usr/src 1 planner: [dumps way too big, 2519056 KB, must skip incremental dumps] coyote:/var 3 3774m wait for dumping SUMMARY part real estimated size size partition : 32 estimated : 3242307m flush : 0 0m failed : 2127964m ( 66.10%) wait for dumping: 10 7070m ( 16.71%) dumping to tape : 00m ( 0.00%) dumping : 1 5298m 7271m ( 72.87%) ( 12.52%) dumped : 0 0m 0m ( 0.00%) ( 0.00%) wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) wait to flush : 0 0m 0m (100.00%) ( 0.00%) writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) taped : 0 0m 0m ( 0.00%) ( 0.00%) tape 1: 0 0m 0m ( 0.00%) Dailys-17 8 dumpers idle : not-idle taper idle network free kps: 6800 holding space : 66234m (100.00%) dumper0 busy : 0:00:00 ( 0.00%) 0 dumpers busy : 0:00:00 ( 0.00%) 1 dumper busy : 0:00:00 ( 0.00%) [EMAIL PROTECTED] Daily]# Anything above that's 'way too big' is within a percent or so, regardless of the level, of a full, every byte backup. The number in column 31 above is the backup level that disklist entry is getting right now. As a sample of how it is being messed with, for a single, approximately 2.5GB collection of music I have, are the outputs of the sendsize function for the last 2 runs, yesterdays dated files were obtained running 2.6.20.4 and todays were obtained with 2.6.21-rc5. Good, 2.6.20.4 was running sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting size via gnutar for /usr/music level 0 sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music level
Re: [PATCH] Fix build error due to not including
> From: Andrew Morton > Newsgroups: gmane.linux.kernel > Subject: Re: [PATCH] Fix build error due to not including > Date: Sun, 18 Mar 2007 22:01:48 -0800 > > If is a bit of a pain to maintain CONFIG_SYSFS=n. But then, it's > realtively easy to fix things when they do break, and sysfs does consume > rather a lot of memory at runtime. Hopefully someone out there is finding > SYSFS=n to be useful for deeply embedded applications. Actually i've managed to build and run rc5 for five days now. Not so embedded amd64 laptop. Kudos and thanks to Ralf. After splitting kobject from sysfs, as it was commented Tejun Heo in the [RFD driver-core] Lifetime problems of the current driver model maybe something lightweight can emerge, without current 'features' and going-to-be sysfs-v1,v2,v3 thing... - 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: Silent corruption on AMD64
On Sat, Mar 31, 2007 at 08:03:16PM -0700, Jim Paris wrote: > Since it shows up under heavy load that includes unrelated devices, I > think ruling out hardware problems is important. Some suggestions: I've been able to narrow it down to the Realtek Ethernet card. I can't reproduce the problem using onboard Ethernet, whereas the Realtek card causes trouble in any slot. However, I still don't know whether it's a hardware or software issue, or whether it's caused directly or indirectly by the Realtek card. - 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] remove artificial software max_loop limit
On 3/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Yes, the distros do, and they recommend it to their users a lot.
Thanks. In that case I think we should retain the max_loop module parameter
for now.
Ken, when you respin that patch could you restore max_loop, and make its
use trigger a warning along the lines of "loop: the max_loop option is obsolete
and will be removed in March 2008"?
OK, here is a re-spin patch that I tested as module or
link-in-vmlinux. Both produce satisfactory result for me. I also
enclosed the patch as an attachment just in case my email client
decide to eat away white spaces for the in-line text.
--
Subject: remove artificial software max_loop limit
From: "Ken Chen" <[EMAIL PROTECTED]>
Remove artificial maximum 256 loop device that can be created due to a
legacy device number limit. Searching through lkml archive, there are
several instances where users complained about the artificial limit
that the loop driver impose. There is no reason to have such limit.
This patch rid the limit entirely and make loop device and associated
block queue instantiation on demand. With on-demand instantiation, it
also gives the benefit of not wasting memory if these devices are not
in use (compare to current implementation that always create 8 loop
devices), a net improvement in both areas. This version is both
tested with creation of large number of loop devices and is compatible
with existing losetup/mount user land tools.
There are a number of people who worked on this and provided valuable
suggestions, in no particular order, by:
Jens Axboe
Jan Engelhardt
Christoph Hellwig
Thomas M
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
Cc: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6b5b642..605c1d3 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -77,9 +77,8 @@
#include
-static int max_loop = 8;
-static struct loop_device *loop_dev;
-static struct gendisk **disks;
+static LIST_HEAD(loop_devices);
+static DEFINE_MUTEX(loop_devices_mutex);
/*
* Transfer functions
@@ -183,7 +182,7 @@ figure_loop_size(struct loop_device *lo)
if (unlikely((loff_t)x != size))
return -EFBIG;
- set_capacity(disks[lo->lo_number], x);
+ set_capacity(lo->lo_disk, x);
return 0;
}
@@ -812,7 +811,7 @@ static int loop_set_fd
lo->lo_queue->queuedata = lo;
lo->lo_queue->unplug_fn = loop_unplug;
- set_capacity(disks[lo->lo_number], size);
+ set_capacity(lo->lo_disk, size);
bd_set_size(bdev, size << 9);
set_blocksize(bdev, lo_blocksize);
@@ -832,7 +831,7 @@ out_clr:
lo->lo_device = NULL;
lo->lo_backing_file = NULL;
lo->lo_flags = 0;
- set_capacity(disks[lo->lo_number], 0);
+ set_capacity(lo->lo_disk, 0);
invalidate_bdev(bdev, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask);
@@ -918,7 +917,7 @@ static int loop_clr_fd
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
invalidate_bdev(bdev, 0);
- set_capacity(disks[lo->lo_number], 0);
+ set_capacity(lo->lo_disk, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(filp->f_mapping, gfp);
lo->lo_state = Lo_unbound;
@@ -1322,6 +1321,18 @@ static long lo_compat_ioctl
}
#endif
+static struct loop_device *loop_find_dev(int number)
+{
+ struct loop_device *lo;
+
+ list_for_each_entry(lo, _devices, lo_list) {
+ if (lo->lo_number == number)
+ return lo;
+ }
+ return NULL;
+}
+
+static struct loop_device *loop_init_one(int i);
static int lo_open(struct inode *inode, struct file *file)
{
struct loop_device *lo = inode->i_bdev->bd_disk->private_data;
@@ -1330,6 +1341,11 @@ static int lo_open
lo->lo_refcnt++;
mutex_unlock(>lo_ctl_mutex);
+ mutex_lock(_devices_mutex);
+ if (!loop_find_dev(lo->lo_number + 1))
+ loop_init_one(lo->lo_number + 1);
+ mutex_unlock(_devices_mutex);
+
return 0;
}
@@ -1357,8 +1373,9 @@ static struct block_device_operations lo_fops = {
/*
* And now the modules code and kernel interface.
*/
+static int max_loop;
module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
+MODULE_PARM_DESC(max_loop, "obsolete, loop device is created on-demand");
MODULE_LICENSE("GPL");
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);
@@ -1383,7 +1400,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = _dev[0]; lo < _dev[max_loop]; lo++) {
+ list_for_each_entry(lo, _devices, lo_list) {
mutex_lock(>lo_ctl_mutex);
if (lo->lo_encryption == xfer)
@@ -1398,91 +1415,110 @@ int
Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET
On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote: > On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote: > > for those will all get grouped together ... suspended "very late" and > > resumed "very early", regardless of when they get registered. Pretty > > much the driver model parts of what Linus was suggesting; clockevent > > bits would still be needed. > > I tested your patch with CONFIG_NO_HZ=y, but it still hangs while > suspending to disk (before the percent saving). Of course. No clockevent updates... - 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: Silent corruption on AMD64
Aaron Lehmann wrote: > I discovered a reproducible way of causing silent file corruption. ... > 1. Heavy Ethernet load (nc remotehost < /dev/zero) > 2. Heavy disk write load on any non-sata_sil drive (cat /dev/zero > /path) > 3. Heavy disk read load on any other drive (tar c /path | cat > /dev/null) Since it shows up under heavy load that includes unrelated devices, I think ruling out hardware problems is important. Some suggestions: - Use mcelog to see if you're getting any machine check exceptions that would indicate hardware error: http://freshmeat.net/projects/mcelog/ - Use the edac module to turn on pci parity and memory error checks: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/drivers/edac/edac.txt - Run memtest86+ for several loops to make sure your RAM is ok - Try moving the SiI card to a different slot - Try running the SATA drives from a separate power supply - Move disks and cables around to see whether the problem follows the disks, the cables, or the controllers - Try enabling the "spread spectrum" clock option in your BIOS to reduce EMI -jim - 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: Silent corruption on AMD64
On Sat, Mar 31, 2007 at 07:52:36PM -0700, Andrew Morton wrote: > Are you able to provide us with some before-and-after data so we > can see this corruption. > > See, if it's dropped-bits or shifted-data or eight-byte-aligned > kernel addresses or whatever, that helps us generate theories.. Sure. I created a large file containing the repeating ASCII string "abcdefgh", and subjected it to the corruption I described earlier. The correct hex sequence is: 61 62 63 64 65 66 67 68 Here were some of the permutations that I found in corrupted copies: 61 62 63 64 92 57 5C 0A 61 62 63 64 A2 2D E1 C7 61 62 63 64 11 38 0E B6 61 62 63 64 57 B1 EE 1F 61 62 63 64 E0 3D 10 21 61 62 63 64 97 E1 C0 F5 I did not observe any errors other than replacements of four-byte blocks. These errors always started at addresses in the file that had a remainder of 12 modulo 16 (i.e. the hex addresses always ended in 'C'). There was an average about one error per 300MB. - 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-pm] [PATCH v2] Add suspend/resume for HPET
On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote: for those will all get grouped together ... suspended "very late" and resumed "very early", regardless of when they get registered. Pretty much the driver model parts of what Linus was suggesting; clockevent bits would still be needed. I tested your patch with CONFIG_NO_HZ=y, but it still hangs while suspending to disk (before the percent saving). But one discovery. I get tired of all these hangs, so I decided to press some keys and the power button. Accidentally, the suspend proceeded and successfully suspended! I tried many more times, and discovered that to proceed with the suspend, hit any 4 keys slowly. (e.g. "F1 F2 F3 F4", or "1 2 3 4"). My .config has CONFIG_NO_HZ=y and CONFIG_HIGH_RES_TIMERS=y, but I suppose CONFIG_HIGH_RES_TIMERS=y gots nothing to do with the hang. I went back with my vanilla 2.6.21-rc5 with Maxim's patch, and with hitting the keys, I could suspend to disk with CONFIG_NO_HZ=y and CONFIG_HIGH_RES_TIMERS=y. 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: cannot add device to partitioned raid6 array
On Saturday March 31, [EMAIL PROTECTED] wrote: > hi list! > > in short: > I created a partitioned raid6 array with 2 missing drives. Now, I want to add > a device. It fails with: > flockmock ~ # mdadm -a /dev/md_d4 /dev/sdb2 > mdadm: add new device failed for /dev/sdb2 as 4: Invalid argument Thanks for the detailed problem report. I think the cause of the error is that /dev/sdb2 is too small. It needs to be at least 490030594 sectors. How big is it? Yes, both the kernel an mdadm should handle this case better. I have made a note to look into this. NeilBrown - 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] hid: add two led codes to hid input mapping
From: Daniel P. Engel <[EMAIL PROTECTED]>
Add the "Off-hook" and "Speaker" LED codes 0xb and 0xc to the hid-input
configuration,
mapping them to the 0x17 and 0x1e usages in the HID usage table.
Signed-off-by: Daniel P. Engel <[EMAIL PROTECTED]>
---
This patch is really being offered because it's what's needed to make the
operation
of the Belkin Flip USB KVM switch avaiable to user-space programs through the
HID input
event interface. The Belkin Flip KVM overloads LED usages to give software
control
over the device, providing options to flip either audio, video or both. However,
without an input mapping to the Off-hook and Speaker LED usages, this
functionality
isn't available.
It's a minor patch, adding two led codes to the EV_LED type, and mapping them to
corresponding HID usages.
This patch was created against kernel version 2.6.20.4.
diff -uprN -X linux-2.6.20.4-vanilla/Documentation/dontdiff
linux-2.6.20.4-vanilla/drivers/hid/hid-input.c linux-2.6/drivers/hid/hid-input.c
--- linux-2.6.20.4-vanilla/drivers/hid/hid-input.c 2007-03-23
15:52:51.0 -0400
+++ linux-2.6/drivers/hid/hid-input.c 2007-03-31 13:43:46.0 -0400
@@ -381,6 +381,8 @@ static void hidinput_configure_usage(str
case 0x4b: map_led (LED_MISC); break;
/* "Generic Indicator"*/
case 0x19: map_led (LED_MAIL); break;
/* "Message Waiting" */
case 0x4d: map_led (LED_CHARGING); break;
/* "External Power Connected" */
+ case 0x17: map_led (LED_OFFHOOK); break;
/* "Off Hook" */
+ case 0x1e: map_led (LED_SPEAKER); break;
/* "Speaker" */
default: goto ignore;
}
diff -uprN -X linux-2.6.20.4-vanilla/Documentation/dontdiff
linux-2.6.20.4-vanilla/include/linux/input.h linux-2.6/include/linux/input.h
--- linux-2.6.20.4-vanilla/include/linux/input.h2007-03-23
15:52:51.0 -0400
+++ linux-2.6/include/linux/input.h 2007-03-31 13:42:22.0 -0400
@@ -630,6 +630,8 @@ struct input_absinfo {
#define LED_MISC 0x08
#define LED_MAIL 0x09
#define LED_CHARGING 0x0a
+#define LED_OFFHOOK0x0b
+#define LED_SPEAKER0x0c
#define LED_MAX0x0f
/*
-
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: Silent corruption on AMD64
> On Sat, 31 Mar 2007 18:27:36 -0700 Aaron Lehmann <[EMAIL PROTECTED]> wrote: > I have spent a lot of time trying to find a simpler test case. So far, > as far as I can tell, there are three conditions that must be > satisfied for corruption to occur: > > 1. Heavy Ethernet load (nc remotehost < /dev/zero) > 2. Heavy disk write load on any non-sata_sil drive (cat /dev/zero > /path) > 3. Heavy disk read load on any other drive (tar c /path | cat > /dev/null) > > With these conditions satisfied, data read off sda or sdb (the drives > associated with sata_sil) is often corrupted. Since I can only see > this problem with files on those two drives, I'm inclined to suspect > the sata_sil driver, but I really have no idea what's going on. I know > this is not a recent issue - I experienced very similar corruption at > least a year ago. I wasn't able to reproduce it at the time, because > it only appeared in the backups I was restoring from. Are you able to provide us with some before-and-after data so we can see this corruption. See, if it's dropped-bits or shifted-data or eight-byte-aligned kernel addresses or whatever, that helps us generate theories.. - 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 device locking, sg vs. sg_io on block devices
> From: Alan Cox > Newsgroups: gmane.linux.kernel > Subject: Re: broken device locking, sg vs. sg_io on block devices > Date: Sun, 1 Apr 2007 01:14:52 +0100 > [] >> Again, it doesn't have to. It can pass the locking operations to the >> related block device driver. > > No it can't. The driver has no idea what the locking rules are for > arbitary command blocks send to arbitary devices. /dev/sg is a *raw* > interface. You can send anything to anyone, and the locking rules for > that are far too complex for a giant morass of kernel code to get added. > > The mess begins because you use /dev/sg and put it in a cdrom group > instead of using SG_IO on the /dev/sr device. (offtop: 'cdrom' is as ugly as 'floppy' for anything like usb, firewire connected storage, why not use 'optics' and 'external' or something?) > The mess continues because of the user of O_EXCL locking thus forcing > re-open/close by HAL Manpage states something bad about it also... > instead of fcntl based co-operative locking. > > > getty/modem/uucp/terminal emulator/slip/ppp/.. Programs you've mentioned may have co-operative locking, but 'dd' or 'cat' have no knowledge of it for sure. Yet nothing prevents allowed user program to use this tools on /dev/tty*. AFAIK kernel developers are always ready for very broken userspace, yet co-operative locking is a job of the userspace programmers of very different tools. > The job of the kernel is not and never has been to anticipate and correct > everything stupid someone tries to do in user space. > As I said before the people wanting to arbitrate serial ports got this > right in the mid 1970's your situation is not much more complicated, Do you mean co-operative locking or carrier detection as a pre-hotplug thing (:? Tell me, please, somebody, why non-exclusive co-operative locking (if it was implemented anyways), racy and already used in userspace applications O_EXCL are better than _mandatory locking_? I've found this helpful against any broken userspace, trying hijack my device and read or write bytes to it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Silent corruption on AMD64
Hello, I discovered a reproducible way of causing silent file corruption. Unfortunately, this method happens to me my backup procedure :(. Background: I have five hard drives. sda and sdb are on a SiI 3112 card. sdc and sdd use onboard sata_via. hda uses onboard VIA VT8237 IDE. All filesystems are ext3. Ethernet is PCI RTL8169. My kernel is 2.6.20.1, configured for SMP and PREEMPT, but I was able to confirm that this corruption happens without SMP or PREEMPT (though it's rarer). The following simultaneous actions result in corrupt data being read from one of the sata_sil drives: 1. rsync files from sdd to sdc 2. rsync files from sdb to a remote host If I run md5sum on a few hundred megabytes on sdb while doing these things, the md5sum computed will usually be wrong. I believe the data getting rsynced off sdb is also corrupt. I have spent a lot of time trying to find a simpler test case. So far, as far as I can tell, there are three conditions that must be satisfied for corruption to occur: 1. Heavy Ethernet load (nc remotehost < /dev/zero) 2. Heavy disk write load on any non-sata_sil drive (cat /dev/zero > /path) 3. Heavy disk read load on any other drive (tar c /path | cat > /dev/null) With these conditions satisfied, data read off sda or sdb (the drives associated with sata_sil) is often corrupted. Since I can only see this problem with files on those two drives, I'm inclined to suspect the sata_sil driver, but I really have no idea what's going on. I know this is not a recent issue - I experienced very similar corruption at least a year ago. I wasn't able to reproduce it at the time, because it only appeared in the backups I was restoring from. dmesg and .config follow. Linux version 2.6.20.1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP PREEMPT Sat Feb 24 11:41:46 PST 2007 Command line: root=/dev/sda1 notsc ro BIOS-provided physical RAM map: BIOS-e820: - 0009ec00 (usable) BIOS-e820: 0009ec00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 5fee (usable) BIOS-e820: 5fee - 5fee3000 (ACPI NVS) BIOS-e820: 5fee3000 - 5fef (ACPI data) BIOS-e820: 5fef - 5ff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 158) 0 entries of 256 used Entering add_active_range(0, 256, 392928) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 K8T890) @ 0x000f7920 ACPI: RSDT (v001 K8T890 AWRDACPI 0x42302e31 AWRD 0x) @ 0x5fee3040 ACPI: FADT (v001 K8T890 AWRDACPI 0x42302e31 AWRD 0x) @ 0x5fee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x5feea800 ACPI: SRAT (v001 AMDHAMMER 0x0001 AMD 0x0001) @ 0x5feeaa40 ACPI: MCFG (v001 K8T890 AWRDACPI 0x42302e31 AWRD 0x) @ 0x5feeab40 ACPI: MADT (v001 K8T890 AWRDACPI 0x42302e31 AWRD 0x) @ 0x5feea740 ACPI: DSDT (v001 K8T890 AWRDACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 158) 0 entries of 256 used Entering add_active_range(0, 256, 392928) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 158 0: 256 -> 392928 On node 0 totalpages: 392830 DMA zone: 56 pages used for memmap DMA zone: 972 pages reserved DMA zone: 2970 pages, LIFO batch:0 DMA32 zone: 5316 pages used for memmap DMA32 zone: 383516 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfecc] gsi_base[24]) IOAPIC[1]: apic_id 3, address 0xfecc, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009e000 - 0009f000 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 6000 (gap: 5ff0:8010) PERCPU: Allocating
Re: [PATCH] fbdev sysfs imrovements
> On Sun, 1 Apr 2007 01:56:28 +0100 (BST) James Simmons <[EMAIL PROTECTED]> > wrote: > > I can't seem to duplicate this error. OK, I'll poke at it some more. > Do you have any patches applied to > the nvidia driver? I don't think so - whatever's in -mm. > On Mon, 26 Mar 2007, Andrew Morton wrote: > > > On Tue, 20 Mar 2007 14:25:49 + (GMT) James Simmons <[EMAIL PROTECTED]> > > wrote: > > > > > This patch does several things to allow the underlying hardware to be > > > shared amount many devices. The most important thing is the use of > > > the created device via device_create instead of the hardware device. No > > > longer should fbdev drivers use the xxx_set_drvdata with the parent > > > bus device. The second change is having a bus independent power management > > > for the framebuffer driver. The final change is using the release method > > > to cleanup the device. The reason again is to make the fbdev driver > > > independent of the bus parent device. Feedback is welcomed. > > > > Causes an early crash on the powermac G5. > > > > http://userweb.kernel.org/~akpm/s5000489.jpg (the oops is the usual powerpc > > mess) > > > > config at http://userweb.kernel.org/~akpm/config-g5.txt > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev sysfs imrovements
I can't seem to duplicate this error. Do you have any patches applied to the nvidia driver? On Mon, 26 Mar 2007, Andrew Morton wrote: > On Tue, 20 Mar 2007 14:25:49 + (GMT) James Simmons <[EMAIL PROTECTED]> > wrote: > > > This patch does several things to allow the underlying hardware to be > > shared amount many devices. The most important thing is the use of > > the created device via device_create instead of the hardware device. No > > longer should fbdev drivers use the xxx_set_drvdata with the parent > > bus device. The second change is having a bus independent power management > > for the framebuffer driver. The final change is using the release method > > to cleanup the device. The reason again is to make the fbdev driver > > independent of the bus parent device. Feedback is welcomed. > > Causes an early crash on the powermac G5. > > http://userweb.kernel.org/~akpm/s5000489.jpg (the oops is the usual powerpc > mess) > > config at http://userweb.kernel.org/~akpm/config-g5.txt > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5 from fc7-rc2 problems
Andrew Morton wrote: On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark <[EMAIL PROTECTED]> wrote: Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 That's regression #1. Are you able to take a photograph of the screen when it has crashed? Setting the display to 50 rows would make that more useful. (serial console would be better, but I assume that thing has no serial port). The other laptop is a hp n5430 it fail in the ali-pata driver not being able to read the cdrom, timeing out and dropping into a bash shell telling me to tell it where the root filesystem is. That's #2, I guess. Also it sets my hard drive to udma/33 when it run find at udma/66 under 2.6.20.1. #3. Hopefully it's related to #2. Please send the full dmesg output for 2.6.20.1 on the n5430. It would really be nice if the people makeing all these changes would at least keep things compatible with what they were before. These are regressions guys! We try ;) This hp n5430 system works fine with 2.6.20.1. Thanks, it helps. I'll see if I can get a serial port console setup on each laptop, failing that I'll take a photo. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - 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] UML kernel & rootfs bundle with every kernel release ?
Hi web.de> writes: > Whenever you want to test some new kernel (feature), you may put you main system at risk, exactly know what > you`re doing - or - use UserModeLinux. Why won't qemu work better in this case? I generally keep a debian testing installation on disk and when I compile a new kernel I just point qemu to load it with the debian root fs. It's fast enough (even the kernel mode accelerator module is GPLed now) and you don't need to mess around with your main system's kernel. You can even test different arches - like both x86_64 and i386 on one x64 box for example. It doesn't work for any particular driver related testing but UML won't either. And it won't benefit UML development but I don't know if that was your main objective as opposed to general kernel experimentation and testing. Parag - 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/
cannot add device to partitioned raid6 array
hi list! in short: I created a partitioned raid6 array with 2 missing drives. Now, I want to add a device. It fails with: flockmock ~ # mdadm -a /dev/md_d4 /dev/sdb2 mdadm: add new device failed for /dev/sdb2 as 4: Invalid argument I think it is the same problem as in: http://marc.info/?l=linux-raid=115316147716600=2 details: kernel 2.6.20.4 mdadm-2.6.1 the raid6 array: flockmock ~ # mdadm --detail /dev/md_d4 /dev/md_d4: Version : 00.90.03 Creation Time : Sat Mar 31 19:48:58 2007 Raid Level : raid6 Array Size : 490030464 (467.33 GiB 501.79 GB) Used Dev Size : 245015232 (233.66 GiB 250.90 GB) Raid Devices : 4 Total Devices : 2 Preferred Minor : 4 Persistence : Superblock is persistent Update Time : Sat Mar 31 23:28:37 2007 State : clean, degraded Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 32K UUID : dfb5e536:2447b984:b7699fd8:8ba37cbf Events : 0.2972 Number Major Minor RaidDevice State 0 820 active sync /dev/sda2 1 8 341 active sync /dev/sdc2 2 002 removed 3 003 removed the device, which I want to add: flockmock ~ # mdadm -E /dev/sdb2 /dev/sdb2: Magic : a92b4efc Version : 00.90.00 UUID : dfb5e536:2447b984:b7699fd8:8ba37cbf Creation Time : Sat Mar 31 19:48:58 2007 Raid Level : raid6 Used Dev Size : 245015232 (233.66 GiB 250.90 GB) Array Size : 490030464 (467.33 GiB 501.79 GB) Raid Devices : 4 Total Devices : 2 Preferred Minor : 4 Update Time : Sat Mar 31 23:29:23 2007 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 2 Spare Devices : 0 Checksum : 8aeeef56 - correct Events : 0.2974 Chunk Size : 32K Number Major Minor RaidDevice State this 4 8 18 -1 spare /dev/sdb2 0 0 820 active sync /dev/sda2 1 1 8 341 active sync /dev/sdc2 2 2 002 faulty removed 3 3 003 faulty removed dmesg shows such error mesgs: [ 220.681135] md: sdb2 has invalid sb, not importing! [ 220.681186] md: md_import_device returned -22 [ 220.681435] md: sdb2 has invalid sb, not importing! [ 220.681463] md: md_import_device returned -22 any idea how to resolve this? thanks, florian PS: please cc me in replies, 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: [PATCH] Fix microcode-related suspend problem
On Saturday, 31 March 2007 23:23, Adrian Bunk wrote:
> On Sat, Mar 31, 2007 at 01:35:32PM -0700, Andrew Morton wrote:
> > On Sat, 31 Mar 2007 22:04:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > This patch appeard on LMKL six days ago and there have not been any
> > > negative
> > > comments since then, so I think I can try to make it official.
> > >
> > > ---
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Fix the regression resulting from the recent change of suspend code
> > > ordering
> > > that causes systems based on Intel x86 CPUs using the microcode driver to
> > > hang during the resume.
> > >
> > > The problem occurs since the microcode driver uses request_firmware() in
> > > its
> > > CPU hotplug notifier, which is called after tasks has been frozen and
> > > hangs.
> > > It can be fixed by telling the microcode driver to use the microcode
> > > stored in
> > > memory during the resume instead of trying to load it from disk.
> >
> > CONFIG_SMP=n:
> >
> > arch/i386/kernel/microcode.c: In function 'microcode_init_cpu':
> > arch/i386/kernel/microcode.c:628: error: 'suspend_cpu_hotplug' undeclared
> > (first use in this function)
> > arch/i386/kernel/microcode.c:628: error: (Each undeclared identifier is
> > reported only once
> > arch/i386/kernel/microcode.c:628: error: for each function it appears in.)
> > arch/i386/kernel/microcode.c: In function 'mc_sysdev_add':
> > arch/i386/kernel/microcode.c:717: error: 'suspend_cpu_hotplug' undeclared
> > (first use in this function)
> > arch/i386/kernel/microcode.c: In function 'mc_sysdev_remove':
> > arch/i386/kernel/microcode.c:745: error: 'suspend_cpu_hotplug' undeclared
> > (first use in this function)
> >
> > Given this, and the overall intrusiveness of the change, I'd worry about
> > trying to get this into 2.6.21.
>
> It fixes a regression, and we are still at least one month away from the
> release of 2.6.21.
>
> 2.6.20 was released with too many known regressions [1], let's not
> repeat this mistake with 2.6.21.
Okay, the appended version of the patch compiles with CONFIG_SMP unset too.
I think it could be done in a more elegant way, but that would require some
additional infrastructure, which definitely is not 2.6.21 material.
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix the regression resulting from the recent change of suspend code ordering
that causes systems based on Intel x86 CPUs using the microcode driver to
hang during the resume.
The problem occurs since the microcode driver uses request_firmware() in its
CPU hotplug notifier, which is called after tasks has been frozen and hangs.
It can be fixed by telling the microcode driver to use the microcode stored in
memory during the resume instead of trying to load it from disk.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/i386/kernel/microcode.c | 71 ---
include/linux/cpu.h |4 ++
kernel/cpu.c | 32 +--
3 files changed, 87 insertions(+), 20 deletions(-)
Index: linux-2.6.21-rc5/arch/i386/kernel/microcode.c
===
--- linux-2.6.21-rc5.orig/arch/i386/kernel/microcode.c
+++ linux-2.6.21-rc5/arch/i386/kernel/microcode.c
@@ -567,6 +567,53 @@ static int cpu_request_microcode(int cpu
return error;
}
+static int apply_microcode_on_cpu(int cpu)
+{
+ struct cpuinfo_x86 *c = cpu_data + cpu;
+ struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+ cpumask_t old;
+ unsigned int val[2];
+ int err = 0;
+
+ if (!uci->mc)
+ return -EINVAL;
+
+ old = current->cpus_allowed;
+ set_cpus_allowed(current, cpumask_of_cpu(cpu));
+
+ /* Check if the microcode we have in memory matches the CPU */
+ if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6 ||
+ cpu_has(c, X86_FEATURE_IA64) || uci->sig != cpuid_eax(0x0001))
+ err = -EINVAL;
+
+ if (!err && ((c->x86_model >= 5) || (c->x86 > 6))) {
+ /* get processor flags from MSR 0x17 */
+ rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
+ if (uci->pf != (1 << ((val[1] >> 18) & 7)))
+ err = -EINVAL;
+ }
+
+ if (!err) {
+ wrmsr(MSR_IA32_UCODE_REV, 0, 0);
+ /* see notes above for revision 1.07. Apparent chip bug */
+ sync_core();
+ /* get the current revision from MSR 0x8B */
+ rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
+ if (uci->rev != val[1])
+ err = -EINVAL;
+ }
+
+ if (!err)
+ apply_microcode(cpu);
+ else
+ printk(KERN_ERR "microcode: Could not apply microcode to CPU%d:"
+ " sig=0x%x, pf=0x%x, rev=0x%x\n",
+ cpu, uci->sig, uci->pf, uci->rev);
+
+
Re: broken device locking, sg vs. sg_io on block devices
> > > The use of /dev/sg* is still common practice, its invention predates > > > > The /dev/sg interface cannot do the locking. If you use /dev/sg you are > > Again, it doesn't have to. It can pass the locking operations to the > related block device driver. No it can't. The driver has no idea what the locking rules are for arbitary command blocks send to arbitary devices. /dev/sg is a *raw* interface. You can send anything to anyone, and the locking rules for that are far too complex for a giant morass of kernel code to get added. The mess begins because you use /dev/sg and put it in a cdrom group instead of using SG_IO on the /dev/sr device. The mess continues because of the user of O_EXCL locking thus forcing re-open/close by HAL instead of fcntl based co-operative locking. The job of the kernel is not and never has been to anticipate and correct everything stupid someone tries to do in user space. As I said before the people wanting to arbitrate serial ports got this right in the mid 1970's your situation is not much more complicated, unless you persist in using /dev/sg - which yes does make it hard, but so does writing it in COBOL, or while standing on your head. And the solution to all three cases is the same *DONT DO IT* 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/
[RFC] UML kernel & rootfs bundle with every kernel release ?
Hello ! i`m not very much into UML for the last months, but while playing around with dm-loop i just got one idea i`d like to share. Whenever you want to test some new kernel (feature), you may put you main system at risk, exactly know what you`re doing - or - use UserModeLinux. The "problem" with UML is: - you needs to compile an UML kernel first. - you needs some "basic" knowlege about UML to get things running. - you need to create an appropriate filesystem image for UML - or find some for download - you need to copy appropriate kernel modules inside - you need to put kernel sources inside, have compiler.. - you may need appropriate modle-init-tools,initrd, kernel specific tools (updated dmsetup, updatedwhatever) in short: it`s quite some work to be done to have your uml 2.6.21 with root-fs up and running and working cleanly. whenever i search the net for some appropriate UML fs image, those i find are very often old and outdated... is there a project/website which is offering such ready to run "UML kernel+rootfs release bundles" for download (i.e. new kernel,generic root-fs, modules inside, sources inside, compiler inside - in sync with the latest stable vanilla) , or , would it make sense to establish such project ? i.e. besides releasing the kernel, also releasing sort of a kernel "runtime kit" and/or "devkit" ? i think this could be very helpful for linux-kernel, because it could be tested by more people more quickly, more easily and thus, more often. just download, do few steps for setup, start up that virtual machine and there you go testing, hacking into the sources, do all that things you never would do on your main system, whatever it would probably also add benefit to UML itself. does this sound dumb? i don`t know, so please comment. regards roland PS: ok, this would be some 500M to 1G download, but there`s lot`s of bandwidth today - and P2P/Bittorrent. ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 - 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: usb hid: reset NumLock
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Fri, 30 Mar 2007, Pete Zaitcev wrote: > I think I see an issue here. Imagine that you boot a system initially with > one keyboard connected (usb, ps/2, doesn't matter), and after some time > you connect second USB keyboard (the NumLock is 'on' on the first keyboard > when you connect the second one). > > Without your patch, the NumLock led will be OK on the second keyboard > immediately. With your patch, the NumLock will be forced to 'off' and it > will be out of sync with the first keyboard. The leds will get in sync > later when any change occurs. Oh, right, I missed it. The difficulty is how I rely on usages and fields being already mapped by hidinput_configure_usage(). Thanks for letting me know, I'll think about it. -- 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: [linux-usb-devel] [RFC] HID bus design overview.
On Fri, 30 Mar 2007, Dmitry Torokhov wrote:
> There should be one device and your driver should simply do:
> static void my_driver_hid_event(struct hid_device *hid, struct hid_field
> *field,
> struct hid_usage *usage, __s32 value)
> {
> if (special_processing_needed(usage)) {
> do_special_processing(...);
> input_event(field->hidinput->input, XXX, YYY, ZZZ);
> ...
>
> } else
> hidinput_hid_event(hid, field, usage, value);
> }
Hi,
in fact I am not entirely sure that the specialized drivers hooked to the
HID bus should be passed individual fields/usages by the generic HID
driver. That would imply that generic HID layer would have to parse the
received report using information retrieved from the report descriptor of
the device. But this is in some way in contrary to one of the features
this effort should be heading to, isn't it? We want to provide means how
to bypass possible errors in HID descriptor of the device (or do any other
possible quirky handling) - we want to be able to allow for completely
different interpretation of fields than the generic HID parser would do,
right?
So I guess the above should rather be
static void my_driver_hid_report(struct hid_device *hid, u8 *data,
int size)
{
if (special_processing_needed(data)) {
do_special_processing(...);
input_event(field->hidinput->input, XXX, YYY, ZZZ);
...
} else
hid_input_report(hid, data, size);
}
Such driver will register itself onto a HID bus. Both USB and BT
transports could provide VID and PID which could then be easily matched
against by the bus code to easily check whether processing by specialized
driver is needed or handling by (existing) generic HID layer is enough.
As an added value, hooking the hidraw code to this architecture would then
be rather a trivial task.
Thanks,
--
Jiri Kosina
-
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 device locking, sg vs. sg_io on block devices
#include * Alan Cox [Sat, Mar 31 2007, 11:20:02PM]: > > But the desktop needs some means to deal with that. AFAICS the only > > feasible way for applications to communicate about device usage policy > > is locking with O_EXCL. Many people do not realize that even read-only > > serial ports and mail both use fcntl file locking , which is much more > flexible. Again, what does that have to do with the problem at hand? Our problem is not about locking on a single file (no matter which mechanism is used) but the coordination of locks _behind_ the userspace access. Or alternatively reassigning all access to one device file. > > > The kernel does not have sufficient information to handle /dev/sg locking > > > > But the kernel knows already that there is a block device behind it. It > > is displayed in sysfs. It shall "just" reuse the lock mechanism of that > > device, not more and not less. Naturally this "just" definition is > > bendable and that is why I initially asked here. > > This doesn't help. There are legitimate reasons to use /dev/sg on a > device which is active. For most subsystems this actually makes a lot of > sense when doing things like enclosure control. For such uses one can omit the locking. Problem solved. > > The sad thing is, this is just another assumption. At least on Debian > > /dev/sgX belongs to the cdrom group when it's a cdrom device and the > > permissions do just invite to work with it. > > Which means it is privilegded. So? Then let's make /etc/shadow privilegded too: chmod a+r /etc/shadow > > > The desktop user space should really know what it is doing with the CD > > > device if it wants to do things like CD burning. If the serial port > > > people could get this right in 1977 then there is no excuse fo the CD > > > > Serial port? Do we have multiple drivers with multiple interfaces > > accessing the same hardware simultaneously and independently? I don't > > think so. > > getty/modem/uucp/terminal emulator/slip/ppp/.. > > I do think so. Nice try, but where are the different conflicting drivers with different userspace interfaces? Do you have some more flawed comparisons of that kind? > > The use of /dev/sg* is still common practice, its invention predates > > The /dev/sg interface cannot do the locking. If you use /dev/sg you are Again, it doesn't have to. It can pass the locking operations to the related block device driver. The alternative is finding a mapping to the correct block device and act on this one (with O_EXCL or with fcntl, or both). Sysfs looks like a good method to get information for such mapping but unfortunately you (kernel developers) are going to cut even this last path soon (see CONFIG_SYSFS_DEPRECATED and its bold description). Is there any other way I need to know about? Some Voodoo ioctl? Regards, Eduard. -- hm, was kann man denn so aus brot machen ... knusprige ente (mit etwas geduld) - 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.6.21-rc5-git 1/2] fix hotplug for legacy platform drivers
We've had various reports of some legacy "probe the hardware" style platform
drivers having nasty problems with hotplug support.
The core issue is that those legacy drivers don't fully conform to the driver
model. They assume a role that should be the responsibility of infrastructure
code: creating device nodes.
The "modprobe" step in hotplugging relies on drivers to have split those
roles into different modules. The lack of this split causes the problems.
When a driver creates nodes for devices that don't exist (sending a hotplug
event), then exits (aborting one modprobe) before the "modprobe $MODALIAS"
step completes (by failing, since it's in the middle of a modprobe), the
result can be an endless loop of modprobe invocations ... badness.
This fix uses the newish per-device flag controlling issuance of "add" events.
(A previous version of this patch used a per-device "driver can hotplug" flag,
which only scrubbed $MODALIAS from the environment rather than suppressing the
entire hotplug event.) It also shrinks that flag to one bit, saving a word in
"struct device".
So the net of this patch is removing some nasty failures with legacy drivers,
while retaining hotplug capability for the majority of platform drivers.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- g26.orig/include/linux/device.h 2007-03-30 16:44:04.0 -0700
+++ g26/include/linux/device.h 2007-03-31 14:39:35.0 -0700
@@ -395,12 +395,13 @@ struct device {
struct klist_node knode_parent; /* node in sibling list
*/
struct klist_node knode_driver;
struct klist_node knode_bus;
- struct device * parent;
+ struct device *parent;
struct kobject kobj;
charbus_id[BUS_ID_SIZE];/* position on parent bus */
struct device_type *type;
unsignedis_registered:1;
+ unsigneduevent_suppress:1;
struct device_attribute uevent_attr;
struct device_attribute *devt_attr;
@@ -441,7 +442,6 @@ struct device {
struct class*class;
dev_t devt; /* dev_t, creates the sysfs
"dev" */
struct attribute_group **groups; /* optional groups */
- int uevent_suppress;
void(*release)(struct device * dev);
};
--- g26.orig/drivers/base/platform.c2007-03-30 16:44:04.0 -0700
+++ g26/drivers/base/platform.c 2007-03-31 14:23:02.0 -0700
@@ -160,6 +160,11 @@ static void platform_device_release(stru
*
* Create a platform device object which can have other objects attached
* to it, and which will have attached objects freed when it is released.
+ *
+ * This device will be marked as not supporting hotpluggable drivers; in
+ * the unusual case that the device isn't being dynamically allocated as
+ * of a legacy "probe the hardware" driver, infrastructure code should
+ * reverse this marking.
*/
struct platform_device *platform_device_alloc(const char *name, unsigned int
id)
{
@@ -172,6 +177,12 @@ struct platform_device *platform_device_
pa->pdev.id = id;
device_initialize(>pdev.dev);
pa->pdev.dev.release = platform_device_release;
+
+ /* prevent hotplug "modprobe $(MODALIAS)" from causing trouble
in
+* legacy probe-the-hardware drivers, which don't properly split
+* out enumeration logic from drivers.
+*/
+ pa->pdev.dev.uevent_suppress = 1;
}
return pa ? >pdev : NULL;
@@ -349,6 +360,13 @@ EXPORT_SYMBOL_GPL(platform_device_unregi
* memory allocated for the device allows drivers using such devices
* to be unloaded iwithout waiting for the last reference to the device
* to be dropped.
+ *
+ * This interface is primarily intended for use with legacy drivers
+ * which probe hardware directly. Because such drivers create device
+ * nodes themselves, rather than letting system infrastructure handle
+ * such device enumeration tasks, they don't fully conform to the Linux
+ * driver model. In particular, when such drivers are built as modules,
+ * they can't be "hotplugged".
*/
struct platform_device *platform_device_register_simple(char *name, unsigned
int id,
struct resource *res,
unsigned int num)
--- g26.orig/drivers/pcmcia/pxa2xx_sharpsl.c2007-03-30 16:44:04.0
-0700
+++ g26/drivers/pcmcia/pxa2xx_sharpsl.c 2007-03-31 14:26:04.0 -0700
@@ -261,6 +261,8 @@ static int __init sharpsl_pcmcia_init(vo
if (!sharpsl_pcmcia_device)
return -ENOMEM;
+ /* REVISIT just statically allocate the device */
+ sharpsl_pcmcia_device->dev.uevent_suppress = 0;
sharpsl_pcmcia_device->dev.platform_data = _pcmcia_ops;
[patch 2.6.21-rc5-git 2/2] update Documentation/driver-model/platform.txt
Make note of the legacy "probe-the-hardware" drivers, and some APIs that are mostly unused except by such drivers. We probably can't escape having legacy drivers for a while (e.g. old ISA drivers), but we can at least discourage this style code for new drivers, and unless it's unavoidable. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- g26.orig/Documentation/driver-model/platform.txt2007-03-31 14:26:14.0 -0700 +++ g26/Documentation/driver-model/platform.txt 2007-03-31 14:49:42.0 -0700 @@ -96,6 +96,46 @@ System setup also associates those clock calls to clk_get(>dev, clock_name) return them as needed. +Legacy Drivers: Device Probing +~~~ +Some drivers are not fully converted to the driver model, because they take +on a non-driver role: the driver registers its platform device, rather than +leaving that for system infrastructure. Such drivers can't be hotplugged +or coldplugged, since those mechanisms require device creation to be in a +different system component than the driver. + +The only "good" reason for this is to handle older system designs which, like +original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware +configuration. Newer systems have largely abandoned that model, in favor of +bus-level support for dynamic configuration (PCI, USB), or device tables +provided by the boot firmware (e.g. PNPACPI on x86). There are too many +conflicting options about what might be where, and even educated guesses by +an operating system will be wrong often enough to make trouble. + +This style of driver is discouraged. If you're updating such a driver, +please try to move the device enumeration to a more appropriate location, +outside the driver. This will usually be cleanup, since such drivers +tend to already have "normal" modes, such as ones using device nodes that +were created by PNP or by platform device setup. + +None the less, there are some APIs to support such legacy drivers. Avoid +using these calls except with such hotplug-deficient drivers. + + struct platform_device *platform_device_alloc( + char *name, unsigned id); + +You can use platform_device_alloc() to dynamically allocate a device, which +you will then initialize with resources and platform_device_register(). +A better solution is usually: + + struct platform_device *platform_device_register_simple( + char *name, unsigned id, + struct resource *res, unsigned nres); + +You can use platform_device_register_simple() as a one-step call to allocate +and register a device. + + Device Naming and Driver Binding The platform_device.dev.bus_id is the canonical name for the devices. - 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 2.6.16.46
Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.45:
Adrian Bunk (2):
Linux 2.6.16.46-rc1
Linux 2.6.16.46
Akinbou Mita (1):
md: fix /proc/mdstat refcounting
Alan Stern (10):
usb-storage: unusual_devs entry for Nikon DSC D70s
USB: unusual_devs entry for Nokia N80
USB: unusual_devs entry for Nokia N91
USB: unusual_devs entry for Nokia E61
USB: unusual_devs entry for Lacie DVD+-RW
USB: unusual-devs entry for Nokia E60
USB: unusual_devs entry for Nokia 6131
USB: unusual_devs entry for Nokia 6234
unusual_devs update for UCR-61S2B
USB: unusual_devs update for Sony P990i phone
Amol Lad (1):
sound/pci/au88x0/au88x0.c: ioremap balanced with iounmap
Andrew Nayenko (1):
USB storage: Nokia 6288 unusual_devs entry
Andy Isaacson (1):
fix read past end of array in md/linear.c
Clemens Ladisch (1):
usb-audio: work around wrong frequency in CM6501 descriptors
David Kuehling (1):
USB: unusual_devs entry for A-VOX WSX-300ER MP3 player
Davide Perini (1):
usb-storage: unusual_devs entry for Motorola RAZR V3x
Dylan Taft (1):
USB Storage: US_FL_IGNORE_RESIDUE needed for Aiptek MP3 Player
Eric Sesterhenn (1):
[ALSA] fix NULL pointer dereference in sound/synth/emux/soundfont.c
Ernis (1):
USB: unusual_devs entry for Samsung MP3 player
Florin Malita (1):
[ALSA] Dereference after free in snd_hwdep_release()
Guennadi Liakhovetski (1):
[PPP]: Don't leak an sk_buff on interface destruction.
Jaco Kroon (1):
USB: add Digitech USB-Storage to unusual_devs.h
Jürgen Mell (1):
USB floppy drive SAMSUNG SFD-321U/EP was detected 8 times
Lars Ellenberg (1):
md: pass down BIO_RW_SYNC in raid{1,10}
Lars Jacob (1):
USB: unusual_devs entry for Sony DSC-H5
Luiz Fernando N. Capitulino (1):
USB: unusual_devs.h for Sony floppy
Manuel Osdoba (1):
USB: unusual_devs.h entry for nokia 6233
Mario Rettig (1):
USB: unusual_devs entry for Nokia 3250
Mikko Honkala (1):
USB: Nokia E70 is an unusual device
Neil Brown (2):
MD: Fix problem where hot-added drives are not resynced.
md: Fix bug where spares don't always get rebuilt properly when they
become live
Nick Piggin (1):
mm: fix madvise infinine loop
Olivier Blondeau (1):
USB: storage: atmel unusual dev update
Patrick McHardy (3):
[NET_SCHED]: Fix endless loops caused by inaccurate qlen counters
[NET_SCHED]: cls_basic: fix NULL pointer dereference
[NET_SCHED]: Fix ingress locking
Pete Zaitcev (3):
USB storage: fix ipod ejecting issue
USB: unusual_devs.h for 0x046b:ff40
USB: RAZR v3i unusual_devs
Phil Dibowitz (11):
USB: storage: sandisk unusual_devices entry
USB: storage: another unusual_devs.h entry
USB: storage: unusual_devs.h entry 0420:0001
USB: Storage: unusual devs update
USB Storage: US_FL_MAX_SECTORS_64 flag
USB: another unusual device
USB Storage: unusual_devs.h for Sony Ericsson M600i
USB: unusual_dev entry for Sony P990i
USB: usb-storage: Unusual_dev update
USB Storage: unusual_devs: add supertop drives
USB: Fix UCR-61S2B unusual_dev entry
Rodolfo Quesada (1):
USB: storage: new unusual_devs.h entry: Mitsumi 7in1 Card Reader
Russell King (1):
[SERIAL] Fix oops when removing suspended serial port
Stefan Richter (1):
ieee1394: dv1394: fix CardBus card ejection
Takashi Iwai (6):
[ALSA] hda-codec - Don't return error at initialization of modem codec
[ALSA] hda-intel - Don't try to probe invalid codecs
[ALSA] Fix invalid assignment of PCI revision
[ALSA] cmipci - Fix a typo in 'PC Speaker Playback Switch' control
[ALSA] cs4281 - Fix the check of right channel
[ALSA] ca0106 - Add missing sysfs device assignment
Tobias Lorenz (1):
USB: Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
YOSHIFUJI Hideaki (1):
[IPV6] HASHTABLES: Use appropriate seed for caluculating ehash index.
Makefile |2
drivers/ieee1394/dv1394.c | 17 -
drivers/md/linear.c|2
drivers/md/md.c|3
drivers/md/raid1.c | 13 -
drivers/md/raid10.c| 11 -
drivers/net/ppp_generic.c |3
drivers/serial/serial_core.c |9
drivers/usb/storage/scsiglue.c | 12 -
drivers/usb/storage/unusual_devs.h | 285 +++--
drivers/usb/storage/usb.h |4
include/linux/serial_core.h|1
include/linux/usb_usual.h |2
include/net/sch_generic.h |4
include/sound/ymfpci.h |2
mm/madvise.c
Re: 2.6.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Saturday March 31, [EMAIL PROTECTED] wrote: > On Sat, 31 Mar 2007 17:36:47 + Bernhard Rosenkraenzer <[EMAIL PROTECTED]> > wrote: > > > I'm getting this Oops when booting an 2.6.21-rc5-mm1 or 2.6.21-rc5-mm2 on > > an > > Acer Aspire 1501 LMi in 32 bit mode (2.6.21-rc4-mm1 + hotfixes works > > perfectly): > > > > xor: automatically using best checksumming function: pIII_sse Hmmm... I've seen that before > > Code: 44 89 74 24 48 0f 20 c6 0f 06 0f 11 04 24 0f 11 4c 24 10 0f 11 54 24 > > 20 > > 0f > > 11 5c 24 30 0f 18 82 00 01 00 00 0f 18 82 20 01 00 00 <00> 00 00 00 > > 00 > > 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > - Them bytes that look like '00' are mostly supposed to look like 'F0' - an x86 'noop'. Apparently a bin-utils bug. An alpha of OpenSUSE-10.3 was compiling kernels like this. I'm told it has been fixed. What distro/gcc version/binutils version was this compiled on? It is possible that we should change the ".align 32" in include/asm-i386/xor.h to ".align 32, 0xf0" or similar, but my assembler knowledge stopped growing when it reached 6809, so I'd rather someone who knew something about it did anything that was required > > Dan, I'm assuming your changes in there are the cause of this. AFAICT all > you're doing is moving code around, so it's a bit odd. > > Bernhard, the config would be useful please. > > Neil, is calibrate_xor_block() being rational? > > b1 = (void *) __get_free_pages(GFP_KERNEL, 2); > ... > b2 = b1 + 2*PAGE_SIZE + BENCH_SIZE; > > Is it correct to add BENCH_SIZE to b2 here? I think it is intentional. I cannot say if it is correct. The purpose is to defeat cache effects somehow. The result of that code together with the value of BENCH_SIZE being PAGE_SIZE is that 4 pages are allocated, and the first and last are used. I have no idea how any cache would treat this, but that seems to be the intent of the code. NeilBrown - 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 32/37] CRYPTO: api: scatterwalk_copychunks() fails to advance through scatterlist
On Sat, Mar 31, 2007 at 12:14:37PM +1000, Herbert Xu wrote: > Indeed. That patch was buggy. Sorry for not catching this earlier. Yep, thanks for the fix. I used the wrong length, then tested with a case where nbytes would always be less than PAGE_SIZE, which doesn't hit this problem. Apologies! --b. - 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] Fix microcode-related suspend problem
On Sat, Mar 31, 2007 at 01:35:32PM -0700, Andrew Morton wrote: > On Sat, 31 Mar 2007 22:04:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > This patch appeard on LMKL six days ago and there have not been any negative > > comments since then, so I think I can try to make it official. > > > > --- > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Fix the regression resulting from the recent change of suspend code ordering > > that causes systems based on Intel x86 CPUs using the microcode driver to > > hang during the resume. > > > > The problem occurs since the microcode driver uses request_firmware() in its > > CPU hotplug notifier, which is called after tasks has been frozen and hangs. > > It can be fixed by telling the microcode driver to use the microcode stored > > in > > memory during the resume instead of trying to load it from disk. > > CONFIG_SMP=n: > > arch/i386/kernel/microcode.c: In function 'microcode_init_cpu': > arch/i386/kernel/microcode.c:628: error: 'suspend_cpu_hotplug' undeclared > (first use in this function) > arch/i386/kernel/microcode.c:628: error: (Each undeclared identifier is > reported only once > arch/i386/kernel/microcode.c:628: error: for each function it appears in.) > arch/i386/kernel/microcode.c: In function 'mc_sysdev_add': > arch/i386/kernel/microcode.c:717: error: 'suspend_cpu_hotplug' undeclared > (first use in this function) > arch/i386/kernel/microcode.c: In function 'mc_sysdev_remove': > arch/i386/kernel/microcode.c:745: error: 'suspend_cpu_hotplug' undeclared > (first use in this function) > > Given this, and the overall intrusiveness of the change, I'd worry about > trying to get this into 2.6.21. It fixes a regression, and we are still at least one month away from the release of 2.6.21. 2.6.20 was released with too many known regressions [1], let's not repeat this mistake with 2.6.21. cu Adrian [1] at least the CONFIG_USB_SUSPEND powerdown regression and the pktcdvd+libata not working regression shouldn't have been in a released kernel -- "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 patch] remove the config option for the cs5530a_warm_reset() quirk
Adrian Bunk wrote: > I have no strong opinion regarding this - if it's agreed upon that it's > unlikely it will ever grow, I can also send an additional patch > simplifying it. I haven't got any response from the original person who submitted this patch. It isn't clear to me whether this is a fix for some machine that's in wide use, or a workaround for a prototype sitting on someone's bench. Andi has already accepted my more general patch which allows intercepting the halt/reboot process in arbitrary ways (the machine_ops patch), so that would seem to be a better way of handling this problem if more cases arise. 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: broken device locking, sg vs. sg_io on block devices
> But the desktop needs some means to deal with that. AFAICS the only > feasible way for applications to communicate about device usage policy > is locking with O_EXCL. Many people do not realize that even read-only serial ports and mail both use fcntl file locking , which is much more flexible. > > The kernel does not have sufficient information to handle /dev/sg locking > > But the kernel knows already that there is a block device behind it. It > is displayed in sysfs. It shall "just" reuse the lock mechanism of that > device, not more and not less. Naturally this "just" definition is > bendable and that is why I initially asked here. This doesn't help. There are legitimate reasons to use /dev/sg on a device which is active. For most subsystems this actually makes a lot of sense when doing things like enclosure control. > The sad thing is, this is just another assumption. At least on Debian > /dev/sgX belongs to the cdrom group when it's a cdrom device and the > permissions do just invite to work with it. Which means it is privilegded. > IIRC there were similar issues with the SCSI command filtering with > both but I am not sure on that. SG_IO does command filtering, /dev/sg is intended to be assigned correctly. > > The desktop user space should really know what it is doing with the CD > > device if it wants to do things like CD burning. If the serial port > > people could get this right in 1977 then there is no excuse fo the CD > > Serial port? Do we have multiple drivers with multiple interfaces > accessing the same hardware simultaneously and independently? I don't > think so. getty/modem/uucp/terminal emulator/slip/ppp/.. I do think so. > The use of /dev/sg* is still common practice, its invention predates The /dev/sg interface cannot do the locking. If you use /dev/sg you are telling the kernel you what you are doing. If you don't then you'll make coasters or even bigger messes. If you are prepared to fix the apps then I'd suggest fixing them to use fcntl locks with exclusive lock/shared lock according to their need for exclusivity. That would fix some of the HAL problems (open has side effects relocking doesnt), but there are still corner cases with mounted file systems that need handling and I can see those might need some kernel helping hands. 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: [2.6 patch] remove the config option for the cs5530a_warm_reset() quirk
On Sat, Mar 31, 2007 at 02:05:23PM -0700, Jeremy Fitzhardinge wrote: > Adrian Bunk wrote: > > Instead of cleaning up this mess, please replace this patch with the > > patch below. > > > > Yeah, I considered that patch as a placeholder; I'd been wondering if it > can be completely removed. > > But this patch looks fine, though I'd go further - the lookup table of > pci ids is overkill since it only has one entry (and doesn't look likely > to grow any more). I have no strong opinion regarding this - if it's agreed upon that it's unlikely it will ever grow, I can also send an additional patch simplifying it. > J 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 2/13] signal/timer/event fds v9 - signalfd core ...
On Sat, 31 Mar 2007, Davide Libenzi wrote: > +config SIGNALFD > + bool "Eanble signalfd() system call" if EMBEDDED ^^ Alright ... - 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 patch] remove the config option for the cs5530a_warm_reset() quirk
Adrian Bunk wrote: > Instead of cleaning up this mess, please replace this patch with the > patch below. > Yeah, I considered that patch as a placeholder; I'd been wondering if it can be completely removed. But this patch looks fine, though I'd go further - the lookup table of pci ids is overkill since it only has one entry (and doesn't look likely to grow any more). 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: 2.6.21-rc5 from fc7-rc2 problems
On Sat, Mar 31, 2007 at 01:46:10PM -0700, Andrew Morton wrote: > On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark <[EMAIL PROTECTED]> wrote: >... > > Also it sets my hard > > drive to udma/33 when it run find at udma/66 under 2.6.20.1. > > #3. Hopefully it's related to #2. >... No, this sounds like Subject: libata: PATA UDMA/100 configured as UDMA/33 References : http://lkml.org/lkml/2007/2/20/294 http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html http://bugzilla.kernel.org/show_bug.cgi?id=8133 http://bugzilla.kernel.org/show_bug.cgi?id=8164 http://lkml.org/lkml/2007/3/21/330 Submitter : Fabio Comolli <[EMAIL PROTECTED]> Plamen Petrov <[EMAIL PROTECTED]> Laurent Riffard <[EMAIL PROTECTED]> Lukas Hejtmanek <[EMAIL PROTECTED]> Fixed-By : Tejun Heo <[EMAIL PROTECTED]> Commit : 8c3c52a8f00536ce55dafa055b4a211f878f3901 Status : fixed in -rc6 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/
[-mm patch] make struct proc_fdinfo_file_operations static
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc5-mm2:
>...
> +add-file-position-info-to-proc.patch
>
> /proc feature work
>...
This patch makes the needlessly global
struct proc_fdinfo_file_operations static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5-mm3/fs/proc/base.c.old 2007-03-31 22:07:21.0
+0200
+++ linux-2.6.21-rc5-mm3/fs/proc/base.c 2007-03-31 22:07:30.0 +0200
@@ -1515,7 +1515,7 @@
return err;
}
-const struct file_operations proc_fdinfo_file_operations = {
+static const struct file_operations proc_fdinfo_file_operations = {
.open = nonseekable_open,
.read = proc_fdinfo_read,
};
-
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/
[-mm patch] make drivers/net/qla3xxx.c:PHY_DEVICES[] static
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc5-mm2:
>...
> git-netdev-all.patch
>...
> git trees
>...
This patch makes the needlessly global PHY_DEVICES[] static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
BTW: Why is the name uppercase?
--- linux-2.6.21-rc5-mm3/drivers/net/qla3xxx.c.old 2007-03-31
21:30:20.0 +0200
+++ linux-2.6.21-rc5-mm3/drivers/net/qla3xxx.c 2007-03-31 22:02:00.0
+0200
@@ -88,7 +88,7 @@
char*name;
} PHY_DEVICE_INFO_t;
-const PHY_DEVICE_INFO_t PHY_DEVICES[] =
+static const PHY_DEVICE_INFO_t PHY_DEVICES[] =
{{PHY_TYPE_UNKNOWN,0x00, 0x0, "PHY_TYPE_UNKNOWN"},
{PHY_VITESSE_VSC8211, 0x0003f1, 0xb, "PHY_VITESSE_VSC8211"},
{PHY_AGERE_ET1011C, 0x00a0bc, 0x1, "PHY_AGERE_ET1011C"},
-
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] remove the config option for the cs5530a_warm_reset() quirk
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc5-mm2:
>...
> +x86_64-mm-clean-up-mach_reboot_fixups.patch
>...
> A few x86 updates
>...
OMG - I'll never understand how someone could initially start doing this
hiding of a small fixup behind a config option.
Instead of cleaning up this mess, please replace this patch with the
patch below.
cu
Adrian
<-- snip -->
A config option for hiding one small hardware specific fixup is overkill.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/i386/Kconfig| 18 --
arch/i386/kernel/Makefile|1
arch/i386/kernel/reboot.c| 43 +++-
arch/i386/kernel/reboot_fixups.c | 55 ---
include/linux/reboot_fixups.h| 10 -
5 files changed, 42 insertions(+), 85 deletions(-)
--- linux-2.6.21-rc5-mm3/arch/i386/Kconfig.old 2007-03-31 20:50:28.0
+0200
+++ linux-2.6.21-rc5-mm3/arch/i386/Kconfig 2007-03-31 20:50:43.0
+0200
@@ -426,24 +426,6 @@
Say Y if you intend to run this kernel on a Dell Inspiron 8000.
Say N otherwise.
-config X86_REBOOTFIXUPS
- bool "Enable X86 board specific fixups for reboot"
- depends on X86
- default n
- ---help---
- This enables chipset and/or board specific fixups to be done
- in order to get reboot to work correctly. This is only needed on
- some combinations of hardware and BIOS. The symptom, for which
- this config is intended, is when reboot ends with a stalled/hung
- system.
-
- Currently, the only fixup is for the Geode GX1/CS5530A/TROM2.1.
- combination.
-
- Say Y if you want to enable the fixup. Currently, it's safe to
- enable this option even if you don't need it.
- Say N otherwise.
-
config MICROCODE
tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support"
select FW_LOADER
--- linux-2.6.21-rc5-mm3/arch/i386/kernel/Makefile.old 2007-03-31
20:51:03.0 +0200
+++ linux-2.6.21-rc5-mm3/arch/i386/kernel/Makefile 2007-03-31
20:51:28.0 +0200
@@ -23,7 +23,6 @@
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
obj-$(CONFIG_X86_IO_APIC) += io_apic.o
-obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups.o
obj-$(CONFIG_KEXEC)+= machine_kexec.o relocate_kernel.o crash.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_X86_NUMAQ)+= numaq.o
--- linux-2.6.21-rc5-mm3/arch/i386/kernel/reboot.c.old 2007-03-31
20:52:12.0 +0200
+++ linux-2.6.21-rc5-mm3/arch/i386/kernel/reboot.c 2007-03-31
21:20:18.0 +0200
@@ -13,11 +13,11 @@
#include
#include
#include
+#include
#include
#include
#include
#include "mach_reboot.h"
-#include
/*
* Power off function, if any
@@ -314,6 +314,47 @@
#endif
}
+static void cs5530a_warm_reset(struct pci_dev *dev)
+{
+ /* writing 1 to the reset control register, 0x44 causes the
+ cs5530a to perform a system warm reset */
+ pci_write_config_byte(dev, 0x44, 0x1);
+ udelay(50); /* shouldn't get here but be safe and spin-a-while */
+ return;
+}
+
+struct device_fixup {
+ unsigned int vendor;
+ unsigned int device;
+ void (*reboot_fixup)(struct pci_dev *);
+};
+
+static struct device_fixup fixups_table[] = {
+{ PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5530_LEGACY, cs5530a_warm_reset },
+};
+
+/*
+ * we see if any fixup is available for our current hardware. if there
+ * is a fixup, we call it and we expect to never return from it. if we
+ * do return, we keep looking and then eventually fall back to the
+ * standard mach_reboot on return.
+ */
+static void mach_reboot_fixups(void)
+{
+ struct device_fixup *cur;
+ struct pci_dev *dev;
+ int i;
+
+ for (i=0; i < ARRAY_SIZE(fixups_table); i++) {
+ cur = &(fixups_table[i]);
+ dev = pci_get_device(cur->vendor, cur->device, NULL);
+ if (!dev)
+ continue;
+
+ cur->reboot_fixup(dev);
+ }
+}
+
void machine_emergency_restart(void)
{
if (!reboot_thru_bios) {
--- linux-2.6.21-rc5-mm3/include/linux/reboot_fixups.h 2007-03-31
20:45:40.0 +0200
+++ /dev/null 2006-09-19 00:45:31.0 +0200
@@ -1,10 +0,0 @@
-#ifndef _LINUX_REBOOT_FIXUPS_H
-#define _LINUX_REBOOT_FIXUPS_H
-
-#ifdef CONFIG_X86_REBOOTFIXUPS
-extern void mach_reboot_fixups(void);
-#else
-#define mach_reboot_fixups() ((void)(0))
-#endif
-
-#endif /* _LINUX_REBOOT_FIXUPS_H */
--- linux-2.6.21-rc5-mm3/arch/i386/kernel/reboot_fixups.c 2007-03-31
20:45:40.0 +0200
+++ /dev/null 2006-09-19 00:45:31.0 +0200
@@ -1,55 +0,0 @@
-/*
- * linux/arch/i386/kernel/reboot_fixups.c
- *
- * This is a good place to put board specific reboot fixups.
- *
- * List of supported fixups:
-
[2.6 patch] bonding/bond_main.c: make 2 functions static
This patch makes two needleesly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c |5 +++--
drivers/net/bonding/bonding.h |2 --
2 files changed, 3 insertions(+), 4 deletions(-)
--- linux-2.6.21-rc5-mm3/drivers/net/bonding/bonding.h.old 2007-03-31
21:12:31.0 +0200
+++ linux-2.6.21-rc5-mm3/drivers/net/bonding/bonding.h 2007-03-31
21:12:42.0 +0200
@@ -301,13 +301,11 @@
void bond_destroy_slave_symlinks(struct net_device *master, struct net_device
*slave);
int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
-int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev);
void bond_mii_monitor(struct net_device *bond_dev);
void bond_loadbalance_arp_mon(struct net_device *bond_dev);
void bond_activebackup_arp_mon(struct net_device *bond_dev);
void bond_set_mode_ops(struct bonding *bond, int mode);
int bond_parse_parm(char *mode_arg, struct bond_parm_tbl *tbl);
-const char *bond_mode_name(int mode);
void bond_select_active_slave(struct bonding *bond);
void bond_change_active_slave(struct bonding *bond, struct slave *new_active);
void bond_register_arp(struct bonding *);
--- linux-2.6.21-rc5-mm3/drivers/net/bonding/bond_main.c.old2007-03-31
21:12:50.0 +0200
+++ linux-2.6.21-rc5-mm3/drivers/net/bonding/bond_main.c2007-03-31
21:13:16.0 +0200
@@ -187,7 +187,7 @@
/* General routines -*/
-const char *bond_mode_name(int mode)
+static const char *bond_mode_name(int mode)
{
switch (mode) {
case BOND_MODE_ROUNDROBIN :
@@ -1224,7 +1224,8 @@
/*-- IOCTL --*/
-int bond_sethwaddr(struct net_device *bond_dev, struct net_device *slave_dev)
+static int bond_sethwaddr(struct net_device *bond_dev,
+ struct net_device *slave_dev)
{
dprintk("bond_dev=%p\n", bond_dev);
dprintk("slave_dev=%p\n", slave_dev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc5 from fc7-rc2 problems
On Sat, 31 Mar 2007 16:14:01 -0400 Stephen Clark <[EMAIL PROTECTED]> wrote: > Hello, > > I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it > failed on both. > > Laptop 1 is an asus vbi s96f that get a panic that says exception in > interrupt routine > for my rtl8139. > > This device works fine in 2.6.20.2 That's regression #1. Are you able to take a photograph of the screen when it has crashed? Setting the display to 50 rows would make that more useful. (serial console would be better, but I assume that thing has no serial port). > > The other laptop is a hp n5430 it fail in the ali-pata driver not being > able to read the cdrom, timeing out > and dropping into a bash shell telling me to tell it where the root > filesystem is. That's #2, I guess. > Also it sets my hard > drive to udma/33 when it run find at udma/66 under 2.6.20.1. #3. Hopefully it's related to #2. Please send the full dmesg output for 2.6.20.1 on the n5430. > It would > really be nice if the people makeing > all these changes would at least keep things compatible with what they > were before. These are regressions > guys! We try ;) > This hp n5430 system works fine with 2.6.20.1. Thanks, it 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/
[-mm patch] make drivers/ata/pata_ali.c:ali_tf_load() static
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc5-mm2:
>...
> +testing-patch-for-ali-pata-fixes-hopefully-for-the-problems-with-atapi-dma.patch
>
> pata experiment
>...
This patch makes the needlesly global ali_tf_load() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.21-rc5-mm3/drivers/ata/pata_ali.c.old 2007-03-31
21:06:19.0 +0200
+++ linux-2.6.21-rc5-mm3/drivers/ata/pata_ali.c 2007-03-31 21:06:33.0
+0200
@@ -288,7 +288,7 @@
* Inherited from caller.
*/
-void ali_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
+static void ali_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
{
struct ata_ioports *ioaddr = >ioaddr;
unsigned int is_addr = tf->flags & ATA_TFLAG_ISADDR;
-
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] Fix microcode-related suspend problem
On Saturday, 31 March 2007 22:35, Andrew Morton wrote: > On Sat, 31 Mar 2007 22:04:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> > wrote: > > > This patch appeard on LMKL six days ago and there have not been any negative > > comments since then, so I think I can try to make it official. > > > > --- > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Fix the regression resulting from the recent change of suspend code ordering > > that causes systems based on Intel x86 CPUs using the microcode driver to > > hang during the resume. > > > > The problem occurs since the microcode driver uses request_firmware() in its > > CPU hotplug notifier, which is called after tasks has been frozen and hangs. > > It can be fixed by telling the microcode driver to use the microcode stored > > in > > memory during the resume instead of trying to load it from disk. > > CONFIG_SMP=n: Ah, sorry. I tend to forget about it ... > arch/i386/kernel/microcode.c: In function 'microcode_init_cpu': > arch/i386/kernel/microcode.c:628: error: 'suspend_cpu_hotplug' undeclared > (first use in this function) > arch/i386/kernel/microcode.c:628: error: (Each undeclared identifier is > reported only once > arch/i386/kernel/microcode.c:628: error: for each function it appears in.) > arch/i386/kernel/microcode.c: In function 'mc_sysdev_add': > arch/i386/kernel/microcode.c:717: error: 'suspend_cpu_hotplug' undeclared > (first use in this function) > arch/i386/kernel/microcode.c: In function 'mc_sysdev_remove': > arch/i386/kernel/microcode.c:745: error: 'suspend_cpu_hotplug' undeclared > (first use in this function) > > Given this, and the overall intrusiveness of the change, I'd worry about > trying to get this into 2.6.21. Well, in that case I'll try to fix it later in a slightly different way. - 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.20.4 crashes
On Sat, 31 Mar 2007 20:44:58 +0200 Maciej Soltysiak <[EMAIL PROTECTED]> wrote: > Hi, > > here's more... > > BUG: unable to handle kernel NULL pointer dereference at virtual address > > printing eip: > > *pde = > Oops: [#1] > Modules linked in: binfmt_misc sit nfs lockd nfs_acl sunrpc ipt_ECN > iptable_mangle w83627ehf i2c_isa i2c_viapro i2c_core via_agp agpgart rtc > CPU:0 > EIP:0060:[<>]Not tainted VLI > EFLAGS: 00010016 (2.6.20.3-cks1 #4) That's not 2.6.20.4. > EIP is at 0x0 > eax: e94a5e6c ebx: e94a5e6c ecx: edx: 0001 > esi: edi: e94a5e84 ebp: e94a5e6c esp: e94a5e4c > ds: 007b es: 007b ss: 0068 > Process grep (pid: 9156, ti=e94a4000 task=f4569a90 task.ti=e94a4000) > Stack: c0116429 0001 0001 ec7da800 0286 > >e94a5e84 c0117802 ec7da800 ec7da800 ec7da85c > c015c622 > e9d02b40 e94a5f60 f77b6ac0 0400 c0313e6c > 1000 > Call Trace: > [] __wake_up_common+0x39/0x70 > [] __wake_up+0x22/0x30 > [] pipe_write+0x222/0x4b0 > [] do_sync_write+0xc7/0x110 > [] autoremove_wake_function+0x0/0x50 > [] vfs_write+0xa6/0x160 > [] do_sync_write+0x0/0x110 > [] sys_write+0x41/0x70 > [] sysenter_past_esp+0x5f/0x85 > [] ipv6_flowlabel_opt+0x193/0x730 > === > Code: Bad EIP value. > EIP: [<>] 0x0 SS:ESP 0068:e94a5e4c __wake_up() did a jump-to-zero. Is it repeatable? Does removal of Con's patchset fix it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix microcode-related suspend problem
On Sat, 31 Mar 2007 22:04:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > This patch appeard on LMKL six days ago and there have not been any negative > comments since then, so I think I can try to make it official. > > --- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Fix the regression resulting from the recent change of suspend code ordering > that causes systems based on Intel x86 CPUs using the microcode driver to > hang during the resume. > > The problem occurs since the microcode driver uses request_firmware() in its > CPU hotplug notifier, which is called after tasks has been frozen and hangs. > It can be fixed by telling the microcode driver to use the microcode stored in > memory during the resume instead of trying to load it from disk. CONFIG_SMP=n: arch/i386/kernel/microcode.c: In function 'microcode_init_cpu': arch/i386/kernel/microcode.c:628: error: 'suspend_cpu_hotplug' undeclared (first use in this function) arch/i386/kernel/microcode.c:628: error: (Each undeclared identifier is reported only once arch/i386/kernel/microcode.c:628: error: for each function it appears in.) arch/i386/kernel/microcode.c: In function 'mc_sysdev_add': arch/i386/kernel/microcode.c:717: error: 'suspend_cpu_hotplug' undeclared (first use in this function) arch/i386/kernel/microcode.c: In function 'mc_sysdev_remove': arch/i386/kernel/microcode.c:745: error: 'suspend_cpu_hotplug' undeclared (first use in this function) Given this, and the overall intrusiveness of the change, I'd worry about trying to get this into 2.6.21. - 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/13] signal/timer/event fds v9 - signalfd core ...
This patch series implements the new signalfd() system call.
I took part of the original Linus code (and you know how
badly it can be broken :), and I added even more breakage ;)
Signals are fetched from the same signal queue used by the process,
so signalfd will compete with standard kernel delivery in dequeue_signal().
If you want to reliably fetch signals on the signalfd file, you need to
block them with sigprocmask(SIG_BLOCK).
This seems to be working fine on my Dual Opteron machine. I made a quick
test program for it:
http://www.xmailserver.org/signafd-test.c
The signalfd() system call implements signal delivery into a file
descriptor receiver. The signalfd file descriptor if created with the
following API:
int signalfd(int ufd, const sigset_t *mask, size_t masksize);
The "ufd" parameter allows to change an existing signalfd sigmask, w/out
going to close/create cycle (Linus idea). Use "ufd" == -1 if you want a
brand new signalfd file.
The "mask" allows to specify the signal mask of signals that we are
interested in. The "masksize" parameter is the size of "mask".
The signalfd fd supports the poll(2) and read(2) system calls. The poll(2)
will return POLLIN when signals are available to be dequeued. As a direct
consequence of supporting the Linux poll subsystem, the signalfd fd can use
used together with epoll(2) too.
The read(2) system call will return a "struct signalfd_siginfo" structure
in the userspace supplied buffer. The return value is the number of bytes
copied in the supplied buffer, or -1 in case of error. The read(2) call
can also return 0, in case the sighand structure to which the signalfd
was attached, has been orphaned. The O_NONBLOCK flag is also supported, and
read(2) will return -EAGAIN in case no signal is available.
If the size of the buffer passed to read(2) is lower than
sizeof(struct signalfd_siginfo), -EINVAL is returned. A read from the
signalfd can also return -ERESTARTSYS in case a signal hits the process.
The format of the struct signalfd_siginfo is, and the valid fields depends
of the (->code & __SI_MASK) value, in the same way a struct siginfo would:
struct signalfd_siginfo {
__u32 signo;/* si_signo */
__s32 err; /* si_errno */
__s32 code; /* si_code */
__u32 pid; /* si_pid */
__u32 uid; /* si_uid */
__s32 fd; /* si_fd */
__u32 tid; /* si_fd */
__u32 band; /* si_band */
__u32 overrun; /* si_overrun */
__u32 trapno; /* si_trapno */
__s32 status; /* si_status */
__s32 svint;/* si_int */
__u64 svptr;/* si_ptr */
__u64 utime;/* si_utime */
__u64 stime;/* si_stime */
__u64 addr; /* si_addr */
};
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/fs/signalfd.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21-rc5.fds/fs/signalfd.c 2007-03-31 12:29:28.0 -0700
@@ -0,0 +1,357 @@
+/*
+ * fs/signalfd.c
+ *
+ * Copyright (C) 2003 Linus Torvalds
+ *
+ * Mon Mar 5, 2007: Davide Libenzi
+ * Changed ->read() to return a siginfo strcture instead of signal number.
+ * Fixed locking in ->poll().
+ * Added sighand-detach notification.
+ * Added fd re-use in sys_signalfd() syscall.
+ * Now using anonymous inode source.
+ * Thanks to Oleg Nesterov for useful code review and suggestions.
+ * More comments and suggestions from Arnd Bergmann.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+
+struct signalfd_ctx {
+ struct list_head lnk;
+ wait_queue_head_t wqh;
+ sigset_t sigmask;
+ struct task_struct *tsk;
+};
+
+struct signalfd_lockctx {
+ struct task_struct *tsk;
+ unsigned long flags;
+};
+
+
+/*
+ * Tries to acquire the sighand lock. We do not increment the sighand
+ * use count, and we do not even pin the task struct, so we need to
+ * do it inside an RCU read lock, and we must be prepared for the
+ * ctx->tsk going to NULL (in signalfd_deliver()), and for the sighand
+ * being detached. We return 0 if the sighand has been detached, or
+ * 1 if we were able to pin the sighand lock.
+ */
+static int signalfd_lock(struct signalfd_ctx *ctx, struct signalfd_lockctx *lk)
+{
+ struct sighand_struct *sighand = NULL;
+
+ rcu_read_lock();
+ lk->tsk = rcu_dereference(ctx->tsk);
+ if (likely(lk->tsk != NULL))
+ sighand = lock_task_sighand(lk->tsk, >flags);
+ rcu_read_unlock();
+
+ if (sighand && !ctx->tsk) {
+ unlock_task_sighand(lk->tsk, >flags);
+ sighand = NULL;
+ }
+
+ return sighand != NULL;
+}
+
+static void signalfd_unlock(struct signalfd_lockctx *lk)
+{
+ unlock_task_sighand(lk->tsk, >flags);
+}
+
+/*
[patch 8/13] signal/timer/event fds v9 - timerfd wire up x86_64 arch ...
This patch wire the timerfd system call to the x86_64 architecture. Signed-off-by: Davide Libenzi - Davide Index: linux-2.6.21-rc5.fds/arch/x86_64/ia32/ia32entry.S === --- linux-2.6.21-rc5.fds.orig/arch/x86_64/ia32/ia32entry.S 2007-03-31 12:30:10.0 -0700 +++ linux-2.6.21-rc5.fds/arch/x86_64/ia32/ia32entry.S 2007-03-31 12:45:32.0 -0700 @@ -720,4 +720,5 @@ .quad sys_getcpu .quad sys_epoll_pwait .quad sys_signalfd /* 320 */ + .quad sys_timerfd ia32_syscall_end: Index: linux-2.6.21-rc5.fds/include/asm-x86_64/unistd.h === --- linux-2.6.21-rc5.fds.orig/include/asm-x86_64/unistd.h 2007-03-31 12:30:10.0 -0700 +++ linux-2.6.21-rc5.fds/include/asm-x86_64/unistd.h2007-03-31 12:45:32.0 -0700 @@ -621,8 +621,10 @@ __SYSCALL(__NR_move_pages, sys_move_pages) #define __NR_signalfd 280 __SYSCALL(__NR_signalfd, sys_signalfd) +#define __NR_timerfd 281 +__SYSCALL(__NR_timerfd, sys_timerfd) -#define __NR_syscall_max __NR_signalfd +#define __NR_syscall_max __NR_timerfd #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 7/13] signal/timer/event fds v9 - timerfd wire up i386 arch ...
This patch wire the timerfd system call to the i386 architecture. Signed-off-by: Davide Libenzi - Davide Index: linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S === --- linux-2.6.21-rc5.fds.orig/arch/i386/kernel/syscall_table.S 2007-03-31 12:30:07.0 -0700 +++ linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S 2007-03-31 12:45:35.0 -0700 @@ -320,3 +320,4 @@ .long sys_getcpu .long sys_epoll_pwait .long sys_signalfd /* 320 */ + .long sys_timerfd Index: linux-2.6.21-rc5.fds/include/asm-i386/unistd.h === --- linux-2.6.21-rc5.fds.orig/include/asm-i386/unistd.h 2007-03-31 12:30:07.0 -0700 +++ linux-2.6.21-rc5.fds/include/asm-i386/unistd.h 2007-03-31 12:45:35.0 -0700 @@ -326,10 +326,11 @@ #define __NR_getcpu318 #define __NR_epoll_pwait 319 #define __NR_signalfd 320 +#define __NR_timerfd 321 #ifdef __KERNEL__ -#define NR_syscalls 321 +#define NR_syscalls 322 #define __ARCH_WANT_IPC_PARSE_VERSION #define __ARCH_WANT_OLD_READDIR - 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.21-rc5 from fc7-rc2 problems
Hello, I have just tried booting the fc7-rc2 live cd on 2 of my laptops and it failed on both. Laptop 1 is an asus vbi s96f that get a panic that says exception in interrupt routine for my rtl8139. This device works fine in 2.6.20.2 $ lspci -v 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub Flags: bus master, fast devsel, latency 0 Capabilities: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feb8 (32-bit, non-prefetchable) [size=512K] I/O ports at ec00 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at feb4 (32-bit, non-prefetchable) [size=256K] Capabilities: 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) Subsystem: ASUSTeK Computer Inc. Unknown device 1252 Flags: bus master, fast devsel, latency 0 Memory at fea8 (32-bit, non-prefetchable) [size=512K] Capabilities: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1343 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at feb38000 (64-bit, non-prefetchable) [size=16K] Capabilities: 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Memory behind bridge: fe70-fe7f Capabilities: 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: fdf0-fe6f Prefetchable memory behind bridge: bdf0-bfe0 Capabilities: 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at e400 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at e480 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at e800 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at e880 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0, IRQ 19 Memory at feb3fc00 (32-bit, non-prefetchable) [size=1K] Capabilities: 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=32 I/O behind bridge: d000-dfff Memory behind bridge: fe80-fe8f Prefetchable memory behind bridge: 8000-8000 Capabilities: 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, medium devsel, latency 0 Capabilities: 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) (prog-if 80 [Master]) Subsystem: ASUSTeK Computer Inc. Unknown device 1347 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 20 I/O ports at 01f0 [size=8] I/O ports at 03f4
[patch 10/13] signal/timer/event fds v9 - eventfd core ...
This is a very simple and light file descriptor, that can be used as
event wait/dispatch by userspace (both wait and dispatch) and by the
kernel (dispatch only). It can be used instead of pipe(2) in all cases
where those would simply be used to signal events. Their kernel overhead
is much lower than pipes, and they do not consume two fds. When used in
the kernel, it can offer an fd-bridge to enable, for example, functionalities
like KAIO or syslets/threadlets to signal to an fd the completion of certain
operations. But more in general, an eventfd can be used by the kernel to
signal readiness, in a POSIX poll/select way, of interfaces that would
otherwise be incompatible with it. The API is:
int eventfd(unsigned int count);
The eventfd API accepts an initial "count" parameter, and returns an
eventfd fd. It supports poll(2) (POLLIN, POLLOUT, POLLERR), read(2) and
write(2).
The POLLIN flag is raised when the internal counter is greater than zero.
The POLLOUT flag is raised when at least a value of "1" can be written to
the internal counter.
The POLLERR flag is raised when an overflow in the counter value is detected.
The write(2) operation can never overflow the counter, since it blocks
(unless O_NONBLOCK is set, in which case -EAGAIN is returned).
But the eventfd_signal() function can do it, since it's supposed to not
sleep during its operation.
The read(2) function reads the __u64 counter value, and reset the internal
value to zero. If the value read is equal to (__u64) -1, an overflow
happened on the internal counter (due to 2^64 eventfd_signal() posts
that has never been retired - unlickely, but possible).
The write(2) call writes an __u64 count value, and adds it
to the current counter. The eventfd fd supports O_NONBLOCK also.
On the kernel side, we have:
struct file *eventfd_fget(int fd);
int eventfd_signal(struct file *file, unsigned int n);
The eventfd_fget() should be called to get a struct file* from an eventfd
fd (this is an fget() + check of f_op being an eventfd fops pointer).
The kernel can then call eventfd_signal() every time it wants to post
an event to userspace. The eventfd_signal() function can be called from any
context.
An eventfd() simple test and bench is available here:
http://www.xmailserver.org/eventfd-bench.c
This is the eventfd-based version of pipetest-4 (pipe(2) based):
http://www.xmailserver.org/pipetest-4.c
Not that performance matters much in the eventfd case, but eventfd-bench
shows almost as double as performance than pipetest-4.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/include/linux/syscalls.h
===
--- linux-2.6.21-rc5.fds.orig/include/linux/syscalls.h 2007-03-31
12:30:36.0 -0700
+++ linux-2.6.21-rc5.fds/include/linux/syscalls.h 2007-03-31
12:36:11.0 -0700
@@ -605,6 +605,7 @@
asmlinkage long sys_signalfd(int ufd, sigset_t __user *user_mask, size_t
sizemask);
asmlinkage long sys_timerfd(int ufd, int clockid, int flags,
const struct itimerspec __user *utmr);
+asmlinkage long sys_eventfd(unsigned int count);
int kernel_execve(const char *filename, char *const argv[], char *const
envp[]);
Index: linux-2.6.21-rc5.fds/fs/eventfd.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21-rc5.fds/fs/eventfd.c 2007-03-31 12:36:11.0 -0700
@@ -0,0 +1,237 @@
+/*
+ * fs/eventfd.c
+ *
+ * Copyright (C) 2007 Davide Libenzi
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+
+struct eventfd_ctx {
+ spinlock_t lock;
+ wait_queue_head_t wqh;
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the "count"
+* value to userspace, and will reset "count" to zero. The kernel
+* size eventfd_signal() also, adds to the "count" counter and
+* issue a wakeup.
+*/
+ __u64 count;
+};
+
+
+/*
+ * Adds "n" to the eventfd counter "count". Returns "n" in case of
+ * success, or a value lower then "n" in case of coutner overflow.
+ * This function is supposed to be called by the kernel in paths
+ * that do not allow sleeping. In this function we allow the counter
+ * to reach the ULLONG_MAX value, and we signal this as overflow
+ * condition by returining a POLLERR to poll(2).
+ */
+int eventfd_signal(struct file *file, int n)
+{
+ struct eventfd_ctx *ctx = file->private_data;
+ unsigned long flags;
+
+ if (n < 0)
+ return -EINVAL;
+ spin_lock_irqsave(>lock, flags);
+ if (ULLONG_MAX - ctx->count < n)
+ n = (int) (ULLONG_MAX - ctx->count);
+ ctx->count += n;
+
[patch 9/13] signal/timer/event fds v9 - timerfd compat code ...
This patch implement the necessary compat code for the timerfd system call.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/fs/compat.c
===
--- linux-2.6.21-rc5.fds.orig/fs/compat.c 2007-03-31 12:30:34.0
-0700
+++ linux-2.6.21-rc5.fds/fs/compat.c2007-03-31 12:35:48.0 -0700
@@ -2361,3 +2361,26 @@
#endif /* CONFIG_SIGNALFD */
+#ifdef CONFIG_TIMERFD
+
+asmlinkage long compat_sys_timerfd(int ufd, int clockid, int flags,
+ const struct compat_itimerspec __user *utmr)
+{
+ long res;
+ struct itimerspec t;
+ struct itimerspec __user *ut;
+
+ res = -EFAULT;
+ if (get_compat_itimerspec(, utmr))
+ goto err_exit;
+ ut = compat_alloc_user_space(sizeof(*ut));
+ if (copy_to_user(ut, , sizeof(t)) )
+ goto err_exit;
+
+ res = sys_timerfd(ufd, clockid, flags, ut);
+err_exit:
+ return res;
+}
+
+#endif /* CONFIG_TIMERFD */
+
Index: linux-2.6.21-rc5.fds/include/linux/compat.h
===
--- linux-2.6.21-rc5.fds.orig/include/linux/compat.h2007-03-31
12:25:43.0 -0700
+++ linux-2.6.21-rc5.fds/include/linux/compat.h 2007-03-31 12:35:48.0
-0700
@@ -225,6 +225,11 @@
return lhs->tv_nsec - rhs->tv_nsec;
}
+extern int get_compat_itimerspec(struct itimerspec *dst,
+const struct compat_itimerspec __user *src);
+extern int put_compat_itimerspec(struct compat_itimerspec __user *dst,
+const struct itimerspec *src);
+
asmlinkage long compat_sys_adjtimex(struct compat_timex __user *utp);
extern int compat_printk(const char *fmt, ...);
Index: linux-2.6.21-rc5.fds/kernel/compat.c
===
--- linux-2.6.21-rc5.fds.orig/kernel/compat.c 2007-03-31 12:25:43.0
-0700
+++ linux-2.6.21-rc5.fds/kernel/compat.c2007-03-31 12:35:48.0
-0700
@@ -475,8 +475,8 @@
return min_length;
}
-static int get_compat_itimerspec(struct itimerspec *dst,
-struct compat_itimerspec __user *src)
+int get_compat_itimerspec(struct itimerspec *dst,
+ const struct compat_itimerspec __user *src)
{
if (get_compat_timespec(>it_interval, >it_interval) ||
get_compat_timespec(>it_value, >it_value))
@@ -484,8 +484,8 @@
return 0;
}
-static int put_compat_itimerspec(struct compat_itimerspec __user *dst,
-struct itimerspec *src)
+int put_compat_itimerspec(struct compat_itimerspec __user *dst,
+ const struct itimerspec *src)
{
if (put_compat_timespec(>it_interval, >it_interval) ||
put_compat_timespec(>it_value, >it_value))
-
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 13/13] signal/timer/event fds v9 - KAIO eventfd support example ...
This is an example about how to add eventfd support to the current KAIO code,
in order to enable KAIO to post readiness events to a pollable fd
(hence compatible with POSIX select/poll). The KAIO code simply signals
the eventfd fd when events are ready, and this triggers a POLLIN in the fd.
This patch uses a reserved for future use member of the struct iocb to pass
an eventfd file descriptor, that KAIO will use to post events every time
a request completes. At that point, an aio_getevents() will return the
completed result to a struct io_event.
I made a quick test program to verify the patch, and it runs fine here:
http://www.xmailserver.org/eventfd-aio-test.c
The test program uses poll(2), but it'd, of course, work with select and
epoll too.
This can allow to schedule both block I/O and other poll-able devices requests,
and wait for results using select/poll/epoll.
In a typical scenario, an application would submit KAIO request using
aio_submit(),
and will also use epoll_ctl() on the whole other class of devices (that
with the addition of signals, timers and user events, now it's pretty much
complete), and then would:
epoll_wait(...);
for_each_event {
if (curr_event_is_kaiofd) {
aio_getevents();
dispatch_aio_events();
} else {
dispatch_epoll_event();
}
}
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/fs/aio.c
===
--- linux-2.6.21-rc5.fds.orig/fs/aio.c 2007-03-31 12:45:30.0 -0700
+++ linux-2.6.21-rc5.fds/fs/aio.c 2007-03-31 12:46:31.0 -0700
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -421,6 +422,7 @@
req->private = NULL;
req->ki_iovec = NULL;
INIT_LIST_HEAD(>ki_run_list);
+ req->ki_eventfd = ERR_PTR(-EINVAL);
/* Check if the completion queue has enough free space to
* accept an event from this io.
@@ -462,6 +464,8 @@
{
assert_spin_locked(>ctx_lock);
+ if (!IS_ERR(req->ki_eventfd))
+ fput(req->ki_eventfd);
if (req->ki_dtor)
req->ki_dtor(req);
if (req->ki_iovec != >ki_inline_vec)
@@ -946,6 +950,14 @@
return 1;
}
+ /*
+* Check if the user asked us to deliver the result through an
+* eventfd. The eventfd_signal() function is safe to be called
+* from IRQ context.
+*/
+ if (!IS_ERR(iocb->ki_eventfd))
+ eventfd_signal(iocb->ki_eventfd, 1);
+
info = >ring_info;
/* add a completion event to the ring buffer.
@@ -1555,6 +1567,19 @@
fput(file);
return -EAGAIN;
}
+ if (iocb->aio_resfd != 0) {
+ /*
+* If the aio_resfd field of the iocb is not zero, get an
+* instance of the file* now. The file descriptor must be
+* an eventfd() fd, and will be signaled for each completed
+* event using the eventfd_signal() function.
+*/
+ req->ki_eventfd = eventfd_fget((int) iocb->aio_resfd);
+ if (IS_ERR(req->ki_eventfd)) {
+ ret = PTR_ERR(req->ki_eventfd);
+ goto out_put_req;
+ }
+ }
req->ki_filp = file;
ret = put_user(req->ki_key, _iocb->aio_key);
Index: linux-2.6.21-rc5.fds/include/linux/aio.h
===
--- linux-2.6.21-rc5.fds.orig/include/linux/aio.h 2007-03-31
12:45:30.0 -0700
+++ linux-2.6.21-rc5.fds/include/linux/aio.h2007-03-31 12:46:31.0
-0700
@@ -119,6 +119,12 @@
struct list_headki_list;/* the aio core uses this
* for cancellation */
+
+ /*
+* If the aio_resfd field of the userspace iocb is not zero,
+* this is the underlying file* to deliver event to.
+*/
+ struct file *ki_eventfd;
};
#define is_sync_kiocb(iocb)((iocb)->ki_key == KIOCB_SYNC_KEY)
Index: linux-2.6.21-rc5.fds/include/linux/aio_abi.h
===
--- linux-2.6.21-rc5.fds.orig/include/linux/aio_abi.h 2007-03-31
12:45:30.0 -0700
+++ linux-2.6.21-rc5.fds/include/linux/aio_abi.h2007-03-31
12:46:31.0 -0700
@@ -84,7 +84,11 @@
/* extra parameters */
__u64 aio_reserved2; /* TODO: use this for a (struct sigevent *) */
- __u64 aio_reserved3;
+ __u32 aio_reserved3;
+ /*
+* If different from 0, this is an eventfd to deliver AIO results to
+*/
+ __u32 aio_resfd;
}; /* 64 bytes */
#undef IFBIG
-
To unsubscribe from this list: send the line
[patch 11/13] signal/timer/event fds v9 - eventfd wire up i386 arch ...
This patch wire the eventfd system call to the i386 architecture. Signed-off-by: Davide Libenzi - Davide Index: linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S === --- linux-2.6.21-rc5.fds.orig/arch/i386/kernel/syscall_table.S 2007-03-31 12:35:44.0 -0700 +++ linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S 2007-03-31 12:36:48.0 -0700 @@ -321,3 +321,4 @@ .long sys_epoll_pwait .long sys_signalfd /* 320 */ .long sys_timerfd + .long sys_eventfd Index: linux-2.6.21-rc5.fds/include/asm-i386/unistd.h === --- linux-2.6.21-rc5.fds.orig/include/asm-i386/unistd.h 2007-03-31 12:35:44.0 -0700 +++ linux-2.6.21-rc5.fds/include/asm-i386/unistd.h 2007-03-31 12:36:48.0 -0700 @@ -327,10 +327,11 @@ #define __NR_epoll_pwait 319 #define __NR_signalfd 320 #define __NR_timerfd 321 +#define __NR_eventfd 322 #ifdef __KERNEL__ -#define NR_syscalls 322 +#define NR_syscalls 323 #define __ARCH_WANT_IPC_PARSE_VERSION #define __ARCH_WANT_OLD_READDIR - 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 12/13] signal/timer/event fds v9 - eventfd wire up x86_64 arch ...
This patch wire the eventfd system call to the x86_64 architecture. Signed-off-by: Davide Libenzi - Davide Index: linux-2.6.21-rc5.fds/arch/x86_64/ia32/ia32entry.S === --- linux-2.6.21-rc5.fds.orig/arch/x86_64/ia32/ia32entry.S 2007-03-31 12:35:46.0 -0700 +++ linux-2.6.21-rc5.fds/arch/x86_64/ia32/ia32entry.S 2007-03-31 12:36:51.0 -0700 @@ -721,4 +721,5 @@ .quad sys_epoll_pwait .quad sys_signalfd /* 320 */ .quad sys_timerfd + .quad sys_eventfd ia32_syscall_end: Index: linux-2.6.21-rc5.fds/include/asm-x86_64/unistd.h === --- linux-2.6.21-rc5.fds.orig/include/asm-x86_64/unistd.h 2007-03-31 12:35:46.0 -0700 +++ linux-2.6.21-rc5.fds/include/asm-x86_64/unistd.h2007-03-31 12:36:51.0 -0700 @@ -623,8 +623,10 @@ __SYSCALL(__NR_signalfd, sys_signalfd) #define __NR_timerfd 281 __SYSCALL(__NR_timerfd, sys_timerfd) +#define __NR_eventfd 282 +__SYSCALL(__NR_eventfd, sys_eventfd) -#define __NR_syscall_max __NR_timerfd +#define __NR_syscall_max __NR_eventfd #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/13] signal/timer/event fds v9 - signalfd wire up x86_64 arch ...
This patch wire the signalfd system call to the x86_64 architecture. Signed-off-by: Davide Libenzi - Davide Index: linux-2.6.21-rc5.fds/include/asm-x86_64/unistd.h === --- linux-2.6.21-rc5.fds.orig/include/asm-x86_64/unistd.h 2007-03-31 12:25:43.0 -0700 +++ linux-2.6.21-rc5.fds/include/asm-x86_64/unistd.h2007-03-31 12:30:10.0 -0700 @@ -619,8 +619,10 @@ __SYSCALL(__NR_vmsplice, sys_vmsplice) #define __NR_move_pages279 __SYSCALL(__NR_move_pages, sys_move_pages) +#define __NR_signalfd 280 +__SYSCALL(__NR_signalfd, sys_signalfd) -#define __NR_syscall_max __NR_move_pages +#define __NR_syscall_max __NR_signalfd #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR Index: linux-2.6.21-rc5.fds/arch/x86_64/ia32/ia32entry.S === --- linux-2.6.21-rc5.fds.orig/arch/x86_64/ia32/ia32entry.S 2007-03-31 12:25:43.0 -0700 +++ linux-2.6.21-rc5.fds/arch/x86_64/ia32/ia32entry.S 2007-03-31 12:30:10.0 -0700 @@ -714,9 +714,10 @@ .quad compat_sys_get_robust_list .quad sys_splice .quad sys_sync_file_range - .quad sys_tee + .quad sys_tee /* 315 */ .quad compat_sys_vmsplice .quad compat_sys_move_pages .quad sys_getcpu .quad sys_epoll_pwait + .quad sys_signalfd /* 320 */ ia32_syscall_end: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 6/13] signal/timer/event fds v9 - timerfd core ...
This patch introduces a new system call for timers events delivered
though file descriptors. This allows timer event to be used with
standard POSIX poll(2), select(2) and read(2). As a consequence of
supporting the Linux f_op->poll subsystem, they can be used with
epoll(2) too.
The system call is defined as:
int timerfd(int ufd, int clockid, int flags, const struct itimerspec *utmr);
The "ufd" parameter allows for re-use (re-programming) of an existing
timerfd w/out going through the close/open cycle (same as signalfd).
If "ufd" is -1, s new file descriptor will be created, otherwise the
existing "ufd" will be re-programmed.
The "clockid" parameter is either CLOCK_MONOTONIC or CLOCK_REALTIME.
The time specified in the "utmr->it_value" parameter is the expiry
time for the timer.
If the TFD_TIMER_ABSTIME flag is set in "flags", this is an absolute
time, otherwise it's a relative time.
If the time specified in the "utmr->it_interval" is not zero (.tv_sec == 0,
tv_nsec == 0), this is the period at which the following ticks should
be generated.
The "utmr->it_interval" should be set to zero if only one tick is requested.
Setting the "utmr->it_value" to zero will disable the timer, or will create
a timerfd without the timer enabled.
The function returns the new (or same, in case "ufd" is a valid timerfd
descriptor) file, or -1 in case of error.
As stated before, the timerfd file descriptor supports poll(2), select(2)
and epoll(2). When a timer event happened on the timerfd, a POLLIN mask
will be returned.
The read(2) call can be used, and it will return a u32 variable holding
the number of "ticks" that happened on the interface since the last call
to read(2). The read(2) call supportes the O_NONBLOCK flag too, and EAGAIN
will be returned if no ticks happened.
A quick test program, shows timerfd working correctly on my amd64 box:
http://www.xmailserver.org/timerfd-test.c
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/fs/timerfd.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21-rc5.fds/fs/timerfd.c 2007-03-31 12:46:14.0 -0700
@@ -0,0 +1,233 @@
+/*
+ * fs/timerfd.c
+ *
+ * Copyright (C) 2007 Davide Libenzi
+ *
+ *
+ * Thanks to Thomas Gleixner for code reviews and useful comments.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+
+struct timerfd_ctx {
+ struct hrtimer tmr;
+ ktime_t tintv;
+ spinlock_t lock;
+ wait_queue_head_t wqh;
+ /*
+* Every time a timer triggers, we increase "ticks". A read(2)
+* will return the current value, and will reset "ticks" to zero.
+*/
+ u32 ticks;
+};
+
+
+/*
+ * This gets called when the timer event triggers. We increment the
+ * tick count and wake the possible waiters. If the timer in a
+ * sequential one (->tintv.tv64 != 0), we re-arm it with hrtimer_forward().
+ */
+static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
+{
+ struct timerfd_ctx *ctx = container_of(htmr, struct timerfd_ctx, tmr);
+ enum hrtimer_restart rval = HRTIMER_NORESTART;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ ctx->ticks++;
+ wake_up_locked(>wqh);
+ if (ctx->tintv.tv64 != 0) {
+ hrtimer_forward(htmr, hrtimer_cb_get_time(htmr), ctx->tintv);
+ rval = HRTIMER_RESTART;
+ }
+ spin_unlock_irqrestore(>lock, flags);
+
+ return rval;
+}
+
+static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+ const struct itimerspec *ktmr)
+{
+ enum hrtimer_mode htmode;
+ ktime_t texp;
+
+ htmode = (flags & TFD_TIMER_ABSTIME) ?
+ HRTIMER_MODE_ABS: HRTIMER_MODE_REL;
+
+ texp = timespec_to_ktime(ktmr->it_value);
+ ctx->ticks = 0;
+ ctx->tintv = timespec_to_ktime(ktmr->it_interval);
+ hrtimer_init(>tmr, clockid, htmode);
+ ctx->tmr.expires = texp;
+ ctx->tmr.function = timerfd_tmrproc;
+ if (texp.tv64 != 0)
+ hrtimer_start(>tmr, texp, htmode);
+}
+
+static int timerfd_release(struct inode *inode, struct file *file)
+{
+ struct timerfd_ctx *ctx = file->private_data;
+
+ hrtimer_cancel(>tmr);
+ kfree(ctx);
+ return 0;
+}
+
+static unsigned int timerfd_poll(struct file *file, poll_table *wait)
+{
+ struct timerfd_ctx *ctx = file->private_data;
+ unsigned int events = 0;
+ unsigned long flags;
+
+ poll_wait(file, >wqh, wait);
+
+ spin_lock_irqsave(>lock, flags);
+ if (ctx->ticks)
+ events |= POLLIN;
+ spin_unlock_irqrestore(>lock, flags);
+
+ return events;
+}
+
+static ssize_t timerfd_read(struct file *file, char __user *buf, size_t count,
+
[patch 3/13] signal/timer/event fds v9 - signalfd wire up i386 arch ...
This patch wire the signalfd system call to the i386 architecture. Signed-off-by: Davide Libenzi - Davide Index: linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S === --- linux-2.6.21-rc5.fds.orig/arch/i386/kernel/syscall_table.S 2007-03-31 12:25:43.0 -0700 +++ linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S 2007-03-31 12:30:07.0 -0700 @@ -319,3 +319,4 @@ .long sys_move_pages .long sys_getcpu .long sys_epoll_pwait + .long sys_signalfd /* 320 */ Index: linux-2.6.21-rc5.fds/include/asm-i386/unistd.h === --- linux-2.6.21-rc5.fds.orig/include/asm-i386/unistd.h 2007-03-31 12:25:43.0 -0700 +++ linux-2.6.21-rc5.fds/include/asm-i386/unistd.h 2007-03-31 12:30:07.0 -0700 @@ -325,10 +325,11 @@ #define __NR_move_pages317 #define __NR_getcpu318 #define __NR_epoll_pwait 319 +#define __NR_signalfd 320 #ifdef __KERNEL__ -#define NR_syscalls 320 +#define NR_syscalls 321 #define __ARCH_WANT_IPC_PARSE_VERSION #define __ARCH_WANT_OLD_READDIR - 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/13] signal/timer/event fds v9 - anonymous inode source ...
This patch add an anonymous inode source, to be used for files that need
and inode only in order to create a file*. We do not care of having an
inode for each file, and we do not even care of having different names in
the associated dentries (dentry names will be same for classes of file*).
This allow code reuse, and will be used by epoll, signalfd and timerfd
(and whatever else there'll be).
Andrew, those two patches should be removed from you -mm and replaced with
this one:
add-an-anonymous-inode-source-tidy.patch
add-an-anonymous-inode-source.patch
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/fs/anon_inodes.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6.21-rc5.fds/fs/anon_inodes.c 2007-03-30 18:22:49.0
-0700
@@ -0,0 +1,198 @@
+/*
+ * fs/anon_inodes.c
+ *
+ * Copyright (C) 2007 Davide Libenzi
+ *
+ * Thanks to Arnd Bergmann for code review and suggestions.
+ * More changes for Thomas Gleixner suggestions.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+
+static struct vfsmount *aino_mnt __read_mostly;
+static struct inode *aino_inode;
+static const struct file_operations aino_fops;
+
+
+static int ainofs_get_sb(struct file_system_type *fs_type, int flags,
+const char *dev_name, void *data, struct vfsmount *mnt)
+{
+ return get_sb_pseudo(fs_type, "aino:", NULL, AINOFS_MAGIC, mnt);
+}
+
+static int ainofs_delete_dentry(struct dentry *dentry)
+{
+ /*
+* We faked vfs to believe the dentry was hashed when we created it.
+* Now we restore the flag so that dput() will work correctly.
+*/
+ dentry->d_flags |= DCACHE_UNHASHED;
+ return 1;
+}
+
+
+static struct file_system_type aino_fs_type = {
+ .name = "ainofs",
+ .get_sb = ainofs_get_sb,
+ .kill_sb= kill_anon_super,
+};
+static struct dentry_operations ainofs_dentry_operations = {
+ .d_delete = ainofs_delete_dentry,
+};
+
+
+/**
+ * aino_getfd - creates a new file instance by hooking it up to and anonymous
+ * inode, and a dentry that describe the "class" of the file
+ * @pfd: [out] pointer to the file descriptor
+ * @dpinode: [out] pointer to the inode
+ * @pfile: [out] pointer to the file struct
+ * @name:[in]name of the "class" of the new file
+ * @fops [in]file operations for the new file
+ * @priv [in]private data for the new file (will be file's
private_data)
+ *
+ * Creates a new file by hooking it on a single inode. This is useful for files
+ * that do not need to have a full-fledged inode in order to operate correctly.
+ * All the files created with aino_getfd() will share a single inode, by hence
+ * saving memory and avoiding code duplication for the file/inode/dentry setup.
+ */
+int aino_getfd(int *pfd, struct inode **pinode, struct file **pfile,
+ const char *name, const struct file_operations *fops, void *priv)
+{
+ struct qstr this;
+ struct dentry *dentry;
+ struct inode *inode;
+ struct file *file;
+ int error, fd;
+
+ if (IS_ERR(aino_inode))
+ return -ENODEV;
+ file = get_empty_filp();
+ if (!file)
+ return -ENFILE;
+
+ inode = igrab(aino_inode);
+ if (IS_ERR(inode)) {
+ error = PTR_ERR(inode);
+ goto err_put_filp;
+ }
+
+ error = get_unused_fd();
+ if (error < 0)
+ goto err_iput;
+ fd = error;
+
+ /*
+* Link the inode to a directory entry by creating a unique name
+* using the inode sequence number.
+*/
+ error = -ENOMEM;
+ this.name = name;
+ this.len = strlen(name);
+ this.hash = 0;
+ dentry = d_alloc(aino_mnt->mnt_sb->s_root, );
+ if (!dentry)
+ goto err_put_unused_fd;
+ dentry->d_op = _dentry_operations;
+ /* Do not publish this dentry inside the global dentry hash table */
+ dentry->d_flags &= ~DCACHE_UNHASHED;
+ d_instantiate(dentry, inode);
+
+ file->f_path.mnt = mntget(aino_mnt);
+ file->f_path.dentry = dentry;
+ file->f_mapping = inode->i_mapping;
+
+ file->f_pos = 0;
+ file->f_flags = O_RDWR;
+ file->f_op = fops;
+ file->f_mode = FMODE_READ | FMODE_WRITE;
+ file->f_version = 0;
+ file->private_data = priv;
+
+ fd_install(fd, file);
+
+ *pfd = fd;
+ *pinode = inode;
+ *pfile = file;
+ return 0;
+
+err_put_unused_fd:
+ put_unused_fd(fd);
+err_iput:
+ iput(inode);
+err_put_filp:
+ put_filp(file);
+ return error;
+}
+
+/*
+ * A single inode exist for all aino files. Contrary to pipes,
+ * aino inodes has no per-instance data associated, so we can avoid
+ *
[patch 5/13] signal/timer/event fds v9 - signalfd compat code ...
This patch implement the necessary compat code for the signalfd system call.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.fds/fs/compat.c
===
--- linux-2.6.21-rc5.fds.orig/fs/compat.c 2007-03-31 12:25:43.0
-0700
+++ linux-2.6.21-rc5.fds/fs/compat.c2007-03-31 12:30:34.0 -0700
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2335,3 +2336,28 @@
#endif /* TIF_RESTORE_SIGMASK */
#endif /* CONFIG_EPOLL */
+
+#ifdef CONFIG_SIGNALFD
+
+asmlinkage long compat_sys_signalfd(int ufd,
+ const compat_sigset_t __user *sigmask,
+ compat_size_t sigsetsize)
+{
+ compat_sigset_t ss32;
+ sigset_t tmp;
+ sigset_t __user *ksigmask;
+
+ if (sigsetsize != sizeof(compat_sigset_t))
+ return -EINVAL;
+ if (copy_from_user(, sigmask, sizeof(ss32)))
+ return -EFAULT;
+ sigset_from_compat(, );
+ ksigmask = compat_alloc_user_space(sizeof(sigset_t));
+ if (copy_to_user(ksigmask, , sizeof(sigset_t)))
+ return -EFAULT;
+
+ return sys_signalfd(ufd, ksigmask, sizeof(sigset_t));
+}
+
+#endif /* CONFIG_SIGNALFD */
+
-
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] Fix microcode-related suspend problem
Hi,
This patch appeard on LMKL six days ago and there have not been any negative
comments since then, so I think I can try to make it official.
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix the regression resulting from the recent change of suspend code ordering
that causes systems based on Intel x86 CPUs using the microcode driver to
hang during the resume.
The problem occurs since the microcode driver uses request_firmware() in its
CPU hotplug notifier, which is called after tasks has been frozen and hangs.
It can be fixed by telling the microcode driver to use the microcode stored in
memory during the resume instead of trying to load it from disk.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/i386/kernel/microcode.c | 71 ---
include/linux/cpu.h |2 +
kernel/cpu.c | 32 +--
3 files changed, 85 insertions(+), 20 deletions(-)
Index: linux-2.6.21-rc5/arch/i386/kernel/microcode.c
===
--- linux-2.6.21-rc5.orig/arch/i386/kernel/microcode.c
+++ linux-2.6.21-rc5/arch/i386/kernel/microcode.c
@@ -567,6 +567,53 @@ static int cpu_request_microcode(int cpu
return error;
}
+static int apply_microcode_on_cpu(int cpu)
+{
+ struct cpuinfo_x86 *c = cpu_data + cpu;
+ struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
+ cpumask_t old;
+ unsigned int val[2];
+ int err = 0;
+
+ if (!uci->mc)
+ return -EINVAL;
+
+ old = current->cpus_allowed;
+ set_cpus_allowed(current, cpumask_of_cpu(cpu));
+
+ /* Check if the microcode we have in memory matches the CPU */
+ if (c->x86_vendor != X86_VENDOR_INTEL || c->x86 < 6 ||
+ cpu_has(c, X86_FEATURE_IA64) || uci->sig != cpuid_eax(0x0001))
+ err = -EINVAL;
+
+ if (!err && ((c->x86_model >= 5) || (c->x86 > 6))) {
+ /* get processor flags from MSR 0x17 */
+ rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
+ if (uci->pf != (1 << ((val[1] >> 18) & 7)))
+ err = -EINVAL;
+ }
+
+ if (!err) {
+ wrmsr(MSR_IA32_UCODE_REV, 0, 0);
+ /* see notes above for revision 1.07. Apparent chip bug */
+ sync_core();
+ /* get the current revision from MSR 0x8B */
+ rdmsr(MSR_IA32_UCODE_REV, val[0], val[1]);
+ if (uci->rev != val[1])
+ err = -EINVAL;
+ }
+
+ if (!err)
+ apply_microcode(cpu);
+ else
+ printk(KERN_ERR "microcode: Could not apply microcode to CPU%d:"
+ " sig=0x%x, pf=0x%x, rev=0x%x\n",
+ cpu, uci->sig, uci->pf, uci->rev);
+
+ set_cpus_allowed(current, old);
+ return err;
+}
+
static void microcode_init_cpu(int cpu)
{
cpumask_t old;
@@ -577,7 +624,8 @@ static void microcode_init_cpu(int cpu)
set_cpus_allowed(current, cpumask_of_cpu(cpu));
mutex_lock(_mutex);
collect_cpu_info(cpu);
- if (uci->valid && system_state == SYSTEM_RUNNING)
+ if (uci->valid && system_state == SYSTEM_RUNNING &&
+ !suspend_cpu_hotplug)
cpu_request_microcode(cpu);
mutex_unlock(_mutex);
set_cpus_allowed(current, old);
@@ -663,13 +711,24 @@ static int mc_sysdev_add(struct sys_devi
return 0;
pr_debug("Microcode:CPU %d added\n", cpu);
- memset(uci, 0, sizeof(*uci));
+ /* If suspend_cpu_hotplug is set, the system is resuming and we should
+* use the data from before the suspend.
+*/
+ if (suspend_cpu_hotplug) {
+ err = apply_microcode_on_cpu(cpu);
+ if (err)
+ microcode_fini_cpu(cpu);
+ }
+ if (!uci->valid)
+ memset(uci, 0, sizeof(*uci));
err = sysfs_create_group(_dev->kobj, _attr_group);
if (err)
return err;
- microcode_init_cpu(cpu);
+ if (!uci->valid)
+ microcode_init_cpu(cpu);
+
return 0;
}
@@ -680,7 +739,11 @@ static int mc_sysdev_remove(struct sys_d
if (!cpu_online(cpu))
return 0;
pr_debug("Microcode:CPU %d removed\n", cpu);
- microcode_fini_cpu(cpu);
+ /* If suspend_cpu_hotplug is set, the system is suspending and we should
+* keep the microcode in memory for the resume.
+*/
+ if (!suspend_cpu_hotplug)
+ microcode_fini_cpu(cpu);
sysfs_remove_group(_dev->kobj, _attr_group);
return 0;
}
Index: linux-2.6.21-rc5/include/linux/cpu.h
===
--- linux-2.6.21-rc5.orig/include/linux/cpu.h
+++ linux-2.6.21-rc5/include/linux/cpu.h
@@ -127,6 +127,8 @@ static inline int cpu_is_offline(int cpu
#endif /*
Re: [SLUB 2/2] i386 arch page size slab fixes
On Sat, 31 Mar 2007, Andrew Morton wrote: > Can we disable SLUB on i386 in Kconfig until it gets sorted out? Yes just do not apply this patch. The first one disables SLUB on i386. - 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: [SLUB 2/2] i386 arch page size slab fixes
On Sat, 31 Mar 2007 11:31:07 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > Fixup i386 arch for SLUB support > > i386 arch code currently uses the page struct of slabs for various purposes. > This interferes with slub and so SLUB has been disabled for i386 by setting > ARCH_USES_SLAB_PAGE_STRUCT. > > This patch removes the use of page sized slabs for maintaining pgds and pmds. > > Patch by William Irwin with only very minor modifications by me which are > > 1. Removal of HIGHMEM64G slab caches. It seems that virtualization hosts >require a a full pgd page. > > 2. Add missing virtualization hook. Seems that we need a new way >of serializing paravirt_alloc(). It may need to do its own serialization. > > 3. Remove ARCH_USES_SLAB_PAGE_STRUCT > > Note that this makes things work without debugging on. > The arch still fails to boot properly if full SLUB debugging is on with > a cryptic message: > > CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 00 > Checking 'hlt' instruction... OK. > ACPI: Core revision 20070126 > ACPI: setting ELCR to 0200 (from 1ca0) > BUG: at kernel/sched.c:3417 sub_preempt_count() > [] _spin_unlock_irq+0x13/0x30 > [] schedule_tail+0x36/0xd0 > [] __switch_to+0x28/0x180 > [] ret_from_fork+0x6/0x1c > [] kthread+0x0/0xe0 This all has the potential to make my inbox hurt. Can we disable SLUB on i386 in Kconfig until it gets sorted out? - 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 10/13] signal/timer/event fds v8 - eventfd core ...
On Fri, 30 Mar 2007, Andrew Morton wrote: > On Fri, 30 Mar 2007 18:11:55 -0700 (PDT) Davide Libenzi > wrote: > > > > > > > + */ > > > > > > So it is the caller's responsibility to ensure that *file refers to an > > > eventfd file? > > > > In which function? I lost you ... > > > > eventfd_signal() assumes that the passed in file* refers to an eventfd > file. So if a caller passes in a file* for /etc/passwd, the kernel will go > splat. > > I guess that's caveat emptor, and any violations of that will show up > quickly in testing. My main concern would be that there might be some way > for a naughty user to force the kernel to pass a non-eventfd file* into > this function. That depends upon as-yet-unwritten code - is there a risk > of this happening, and how do we prevent it? That's the kernel side of the API. The userspace->kernel fd validation is done in eventfd_fget(), that the kernel uses to get an eventfd file* from an eventfd file descriptor. The eventfd_fget() does the file operations check and returns proper error. At that point, if the kernel feeds eventfd_signal() with crap, it gets crap back. Like calling internal kernel functions with bogus mm_struct or task_struct. > > > > + DECLARE_WAITQUEUE(wait, current); > > > > + > > > > + if (count < sizeof(ucnt)) > > > > + return -EINVAL; > > > > + if (get_user(ucnt, (const __u64 __user *) buf)) > > > > + return -EFAULT; > > > > > > Some architectures do not implement 64-bit get_user() > > > > copy_from_user it is, then ... > > > > spose so. I think architectures _should_ implement 64-bit get_user() and > put_user() nowadays. So you could leave the code as-is and inform the arch > maintainers, if you're feeling keen. > > If all this code has its own Kconfig options then the architectures won't > break until their maintainers come along to enable the new features, so > they'll implement 64-bit get_user() at that time and things will all unfold > in a nicely non-chaotic fashion. Agreed. I'll leave the get_user(u64). - 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: [patch 6/13] signal/timer/event fds v8 - timerfd core ...
On Fri, 30 Mar 2007, Andrew Morton wrote:
> On Fri, 30 Mar 2007 17:47:28 -0700 (PDT) Davide Libenzi
> wrote:
>
> > On Fri, 30 Mar 2007, Andrew Morton wrote:
> >
> > > > +struct timerfd_ctx {
> > > > + struct hrtimer tmr;
> > > > + ktime_t tintv;
> > > > + spinlock_t lock;
> > > > + wait_queue_head_t wqh;
> > > > + unsigned long ticks;
> > > > +};
> > >
> > > Did you consider using the (presently unused) lock inside wqh instead of
> > > adding a new one? That's a little bit rude, poking into waitqueue
> > > internals like that, but we do it elsewhere and tricks like that are
> > > acceptable in core-kernel, I guess.
> >
> > Please, no. Gain is not worth the plug into the structure design IMO.
> >
>
> The decision is not that obvious - your patch's main use of
> timerfd_ctx.lock is to provide locking for wqh - ie: to duplicate the
> function of the existing lock which is there for that purpose.
>
> So I think it's a legitimate optimisation to borrow it.
As I see it, the lock protects the ticks and the timer structure, and the
wait queue *happen* to have a lock inside. That's the whole purpose in
having data modeled by structures with accessor functions.
IMO, given that we'd get by plugging into the wait_queue_head_t lock is
not much (if at all), it'd be better to to peek at the wait_queue_head_t
directly.
> > > > +static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
> > > > +{
> > > > + struct timerfd_ctx *ctx = container_of(htmr, struct
> > > > timerfd_ctx, tmr);
> > > > + enum hrtimer_restart rval = HRTIMER_NORESTART;
> > > > + unsigned long flags;
> > > > +
> > > > + spin_lock_irqsave(>lock, flags);
> > > > + ctx->ticks++;
> > > > + wake_up_locked(>wqh);
> > > > + if (ctx->tintv.tv64 != 0) {
> > > > + hrtimer_forward(htmr, hrtimer_cb_get_time(htmr),
> > > > ctx->tintv);
> > > > + rval = HRTIMER_RESTART;
> > > > + }
> > > > + spin_unlock_irqrestore(>lock, flags);
> > > > +
> > > > + return rval;
> > > > +}
> > >
> > > What's this do?
> >
> > Really, do we need to comment such trivial code? There is *nothing* that
> > is worth a line of comment in there. IMO useless comment are more annoying
> > than blank lines.
> >
>
> Look at it from the point of view of someone who knows kernel code but does
> not specifically know this subsystem. That describes the great majority of
> people who will be reading your code.
Okie, I added a comment ;)
> Patch headers are not maintainable.
>
> Nobody wants to have to go off and waddle though the git repo to understand
> the design intent behind each function.
I agree. I thought we were talking about the "poor smuck" having to
document it, and the patch header is a pretty good start (and maybe
finish ;).
- 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.21-rc5-mm[12]: Oops on bootup in xor_see_2
On Sat, 31 Mar 2007 17:36:47 + Bernhard Rosenkraenzer <[EMAIL PROTECTED]> wrote: > I'm getting this Oops when booting an 2.6.21-rc5-mm1 or 2.6.21-rc5-mm2 on an > Acer Aspire 1501 LMi in 32 bit mode (2.6.21-rc4-mm1 + hotfixes works > perfectly): > > xor: automatically using best checksumming function: pIII_sse > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 0010 > printing eip: > c02cb724 > *pde= > Oops: 0002 [#1] > last sysfs file: > Modules linked in: > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010212 (2.6.12-rc5-mm2) > EIP is at xor_sse_2+0x34/0x200 > eax: 0010 ebx: fffea4df ecx: df8c3000 edx: df8c > esi: 8005003b edi: c03ebce0 ebp: df8c3000 esp: dfd01ef8 > ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > Process swapper (pid: 1, ti=dfd00 task=c146aa10 task:ti=dfd0 > Stack: > >c13f1800 fffea4df c02caa83 c03ebce0 df8c c011bd7b > Call Trace: > [] do_xor_speed+0x53/0xf0 > [] printk+0x1b/0x20 > [] calibrate_xor_block+0x2e/0x1b0 > [] kernel_init+0x92/0x1c0 > [] ret_from_fork+0x6/0x1c > [] kernel_init+0x0/0x1c0 > [] kernel_init+0x0/0x1c0 > [] kernel_thread_helper+0x7/0x10 > === > Code: 44 89 74 24 48 0f 20 c6 0f 06 0f 11 04 24 0f 11 4c 24 10 0f 11 54 24 20 > 0f > 11 5c 24 30 0f 18 82 00 01 00 00 0f 18 82 20 01 00 00 <00> 00 00 00 00 > 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > - Dan, I'm assuming your changes in there are the cause of this. AFAICT all you're doing is moving code around, so it's a bit odd. Bernhard, the config would be useful please. Neil, is calibrate_xor_block() being rational? b1 = (void *) __get_free_pages(GFP_KERNEL, 2); ... b2 = b1 + 2*PAGE_SIZE + BENCH_SIZE; Is it correct to add BENCH_SIZE to b2 here? - 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-pm] [PATCH v2] Add suspend/resume for HPET
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute [EMAIL PROTECTED] from further messages!! )
>
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> >
> > i dont think there's any particular problem here because suspend/resume
> > wont be done during bootup - but we might need a way to move a device to
> > earlier spots in the device tree, even if they got registered later on -
> > instead of forcing the time devices to be registered very early?
>
> I'm about ready to test the appended patch... a "move one device" call
> might be safest at this point in the release cycle though.
As expected, this behaved OK on an x86 laptop. I'll see if it breaks
some of the ARM boards I have handy.
To be clear, what this means is that if "clockevent" and "clocksource"
devices get registered "very early", and the various clockevent and
clock source devices get registered, then the suspend/resume methods
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered. Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.
- Dave
> - Dave
>
> SNIP!
> Change how the PM list is constructed, so that devices are added right
> after their parents (when they have one) rather than at the end of the
> list. This preserves sequencing guarantees, but enables sequencing of
> suspend/resume operations by more important characteristics than "when
> device happened to enumerate" ... e.g. clocksources and clockevents
> at a clearly defined point during suspend and resume.
>
> This patch has a potential downside for devices that have multiple
> power dependencies and which "just happened to work" before.
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> --- g26.orig/drivers/base/power/main.c2006-07-02 12:30:30.0
> -0700
> +++ g26/drivers/base/power/main.c 2007-03-31 11:02:28.0 -0700
> @@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
> int device_pm_add(struct device * dev)
> {
> int error;
> + struct device *parent = dev->parent;
>
> - pr_debug("PM: Adding info for %s:%s\n",
> - dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
> + pr_debug("PM: Adding info for %s:%s, after %s\n",
> + dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
> + parent ? parent->bus_id : "(no parent)");
> down(_list_sem);
> - list_add_tail(>power.entry, _active);
> - device_pm_set_parent(dev, dev->parent);
> + if (parent)
> + list_add(>power.entry, >power.entry);
> + else
> + list_add_tail(>power.entry, _active);
> + device_pm_set_parent(dev, parent);
> if ((error = dpm_sysfs_add(dev)))
> list_del(>power.entry);
> up(_list_sem);
>
-
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/
[SLUB tool] slabinfo: Display slab statistics
/*
* Slabinfo: Tool to get reports about slabs
*
* (C) 2007 sgi, Christoph Lameter <[EMAIL PROTECTED]>
*
* Compile by doing:
*
* gcc -o slabinfo slabinfo.c
*/
#include
#include
#include
#include
#include
#include
#include
char buffer[200];
int show_alias = 0;
int show_slab = 1;
int show_parameter = 0;
int skip_zero = 1;
int page_size;
void fatal(const char *x, ...)
{
va_list ap;
va_start(ap, x);
vfprintf(stderr, x, ap);
va_end(ap);
exit(1);
}
/*
* Get the contents of an attribute
*/
unsigned long get_obj(char *name)
{
FILE *f = fopen(name, "r");
unsigned long result = 0;
if (!f) {
getcwd(buffer, sizeof(buffer));
fatal("Cannot open file '%s/%s'\n", buffer, name);
}
if (fgets(buffer,sizeof(buffer), f))
result = atol(buffer);
fclose(f);
return result;
}
/*
* Put a size string together
*/
int store_size(char *buffer, unsigned long value)
{
unsigned long divisor = 1;
char trailer = 0;
int n;
if (value > 10UL) {
divisor = 1UL;
trailer = 'G';
} else if (value > 100UL) {
divisor = 10UL;
trailer = 'M';
} else if (value > 1000UL) {
divisor = 100;
trailer = 'K';
}
value /= divisor;
n = sprintf(buffer, "%ld",value);
if (trailer) {
buffer[n] = trailer;
n++;
buffer[n] = 0;
}
if (divisor != 1) {
memmove(buffer + n - 2, buffer + n - 3, 4);
buffer[n-2] = '.';
n++;
}
return n;
}
void alias(const char *name)
{
char *target;
if (!show_alias)
return;
/* Read link target */
printf("%20s -> %s", name, target);
}
int line = 0;
void first_line(void)
{
printf("NameObjects ObjsizeSpace "
"Slabs/Part/Cpu O/S O %%Fr %%Ef Flg\n");
}
void slab(const char *name)
{
unsigned long aliases, align, cache_dma, cpu_slabs, destroy_by_rcu;
unsigned long hwcache_align, object_size, objects, objs_per_slab;
unsigned long order, partial, poison, reclaim_account, red_zone;
unsigned long sanity_checks, slab_size, slabs, store_user, trace;
char size_str[20];
char dist_str[40];
char flags[20];
char *p = flags;
if (!show_slab)
return;
if (chdir(name))
fatal("Unable to access slab %s\n", name);
aliases = get_obj("aliases");
align = get_obj("align");
cache_dma = get_obj("cache_dma");
cpu_slabs = get_obj("cpu_slabs");
destroy_by_rcu = get_obj("destroy_by_rcu");
hwcache_align = get_obj("hwcache_align");
object_size = get_obj("object_size");
objects = get_obj("objects");
objs_per_slab = get_obj("objs_per_slab");
order = get_obj("order");
partial = get_obj("partial");
poison = get_obj("poison");
reclaim_account = get_obj("reclaim_account");
red_zone = get_obj("red_zone");
sanity_checks = get_obj("sanity_checks");
slab_size = get_obj("slab_size");
slabs = get_obj("slabs");
store_user = get_obj("store_user");
trace = get_obj("trace");
if (skip_zero && !slabs)
goto out;
store_size(size_str, slabs * page_size);
sprintf(dist_str,"%lu/%lu/%lu", slabs, partial, cpu_slabs);
if (!line++)
first_line();
if (aliases)
*p++ = '*';
if (cache_dma)
*p++ = 'd';
if (hwcache_align)
*p++ = 'A';
if (poison)
*p++ = 'P';
if (reclaim_account)
*p++ = 'a';
if (red_zone)
*p++ = 'Z';
if (sanity_checks)
*p++ = 'F';
if (store_user)
*p++ = 'U';
if (trace)
*p++ = 'T';
*p = 0;
printf("%-20s %8ld %7d %8s %14s %3ld %1ld %3d %3d %s\n",
name, objects, object_size, size_str, dist_str,
objs_per_slab, order,
slabs ? (partial * 100) / slabs : 100,
slabs ? (objects * object_size * 100) / (slabs *
(page_size << order)) : 100,
flags);
out:
chdir("..");
}
void parameter(const char *name)
{
if (!show_parameter)
return;
}
int main(int argc, char *argv[])
{
DIR *dir;
struct dirent *de;
page_size = getpagesize();
if (chdir("/sys/slab"))
fatal("This kernel does not have SLUB support.\n");
dir = opendir(".");
while ((de = readdir(dir))) {
[SLUB 2/2] i386 arch page size slab fixes
Fixup i386 arch for SLUB support
i386 arch code currently uses the page struct of slabs for various purposes.
This interferes with slub and so SLUB has been disabled for i386 by setting
ARCH_USES_SLAB_PAGE_STRUCT.
This patch removes the use of page sized slabs for maintaining pgds and pmds.
Patch by William Irwin with only very minor modifications by me which are
1. Removal of HIGHMEM64G slab caches. It seems that virtualization hosts
require a a full pgd page.
2. Add missing virtualization hook. Seems that we need a new way
of serializing paravirt_alloc(). It may need to do its own serialization.
3. Remove ARCH_USES_SLAB_PAGE_STRUCT
Note that this makes things work without debugging on.
The arch still fails to boot properly if full SLUB debugging is on with
a cryptic message:
CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 00
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ACPI: setting ELCR to 0200 (from 1ca0)
BUG: at kernel/sched.c:3417 sub_preempt_count()
[] _spin_unlock_irq+0x13/0x30
[] schedule_tail+0x36/0xd0
[] __switch_to+0x28/0x180
[] ret_from_fork+0x6/0x1c
[] kthread+0x0/0xe0
This may have a coule of reasons:
1. SLUB breakage. kmalloc caches have been initialized but maybe debugging
uses a facility that is not available that early (can find nothing).
2. SLAB does not enable full debugging for page order slabs. SLUB does.
So we were so far unable to verify that the code is clean for these
slabs. There could be some unsolved slab issues. i386 fails to boot
if any of the debug options that require additional metadata at the
end of an object or poisoning is enabled. Boot will work with sanity
checks only.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: William Lee Irwin III <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5-mm3/arch/i386/mm/init.c
===
--- linux-2.6.21-rc5-mm3.orig/arch/i386/mm/init.c 2007-03-30
18:26:11.0 -0700
+++ linux-2.6.21-rc5-mm3/arch/i386/mm/init.c2007-03-30 18:28:04.0
-0700
@@ -696,31 +696,6 @@ int remove_memory(u64 start, u64 size)
EXPORT_SYMBOL_GPL(remove_memory);
#endif
-struct kmem_cache *pgd_cache;
-struct kmem_cache *pmd_cache;
-
-void __init pgtable_cache_init(void)
-{
- if (PTRS_PER_PMD > 1) {
- pmd_cache = kmem_cache_create("pmd",
- PTRS_PER_PMD*sizeof(pmd_t),
- PTRS_PER_PMD*sizeof(pmd_t),
- 0,
- pmd_ctor,
- NULL);
- if (!pmd_cache)
- panic("pgtable_cache_init(): cannot create pmd cache");
- }
- pgd_cache = kmem_cache_create("pgd",
- PTRS_PER_PGD*sizeof(pgd_t),
- PTRS_PER_PGD*sizeof(pgd_t),
- 0,
- pgd_ctor,
- PTRS_PER_PMD == 1 ? pgd_dtor : NULL);
- if (!pgd_cache)
- panic("pgtable_cache_init(): Cannot create pgd cache");
-}
-
/*
* This function cannot be __init, since exceptions don't work in that
* section. Put this after the callers, so that it cannot be inlined.
Index: linux-2.6.21-rc5-mm3/arch/i386/mm/pageattr.c
===
--- linux-2.6.21-rc5-mm3.orig/arch/i386/mm/pageattr.c 2007-03-25
15:56:23.0 -0700
+++ linux-2.6.21-rc5-mm3/arch/i386/mm/pageattr.c2007-03-30
18:28:04.0 -0700
@@ -87,24 +87,23 @@ static void flush_kernel_map(void *arg)
static void set_pmd_pte(pte_t *kpte, unsigned long address, pte_t pte)
{
- struct page *page;
- unsigned long flags;
+ struct mm_struct *mm;
set_pte_atomic(kpte, pte); /* change init_mm */
if (PTRS_PER_PMD > 1)
return;
- spin_lock_irqsave(_lock, flags);
- for (page = pgd_list; page; page = (struct page *)page->index) {
- pgd_t *pgd;
+ spin_lock(_lock);
+ list_for_each_entry(mm, _mm.mmlist, mmlist) {
+ pgd_t *pgd = mm->pgd;
pud_t *pud;
pmd_t *pmd;
- pgd = (pgd_t *)page_address(page) + pgd_index(address);
+
pud = pud_offset(pgd, address);
pmd = pmd_offset(pud, address);
set_pte_atomic((pte_t *)pmd, pte);
}
- spin_unlock_irqrestore(_lock, flags);
+ spin_unlock(_lock);
}
/*
Index: linux-2.6.21-rc5-mm3/arch/i386/mm/pgtable.c
===
--- linux-2.6.21-rc5-mm3.orig/arch/i386/mm/pgtable.c2007-03-25
15:56:23.0 -0700
+++ linux-2.6.21-rc5-mm3/arch/i386/mm/pgtable.c 2007-03-30 18:28:04.0
-0700
@@ -181,109 +181,30 @@ void reserve_top_address(unsigned long r
[SLUB 0/2] SLUB: The unqueued slab allocator V6
[PATCH] SLUB The unqueued slab allocator v6 Note that the definition of the return type of ksize() is currently different between mm and Linus' tree. Patch is conforming to mm. This patch also needs sprint_symbol() support from mm. V5->V6: - Straighten out various coding issues u.a. to make the hot path clearer in slab_alloc and slab_free. This adds more gotos. sigh. - Detailed alloc / free tracking including pid, cpu, time of alloc / free if SLAB_STORE_USER is enabled or slub_debug=U specified on boot. - sysfs support via /sys/slab. Drop /proc/slubinfo support. Include slabinfo tool that produces an output similar to what /proc/slabinfo does. Tool needs to be made more sophisticated to allow control of various slub options at runtime. Currently reports total slab sizes, slab fragmentation and slab effectiveness (actual object use vs. slab space use). - Runtime debug option changes per slab via /sys/slab/. All slab debug options can be configured via sysfs provided that no objects have been allocated yet. - Deal with i386 use of slab page structs. Main patch disables slub for i386 (CONFIG_ARCH_USES_SLAB_PAGE_STRUCT). Then a special patch removes the page sized slabs and removes that setting. See the caveats in that patch for further details. V4->V5: - Single object slabs only for slabs > slub_max_order otherwise generate sufficient objects to avoid frequent use of the page allocator. This is necessary to compensate for fragmentation caused by frequent uses of the page allocator. We expect slabs of PAGE_SIZE from this rule since multi object slabs require uses of fields that are in use on i386 and x86_64. See the quicklist patchset for a way to fix that issue and a patch to get rid of the PAGE_SIZE special casing. - Drop pass through to page allocator due to page allocator fragmenting memory. The buffering through large order allocations is done in SLUB. Infrequent larger order allocations cause less fragmentation than frequent small order allocations. - We need to update object sizes when merging slabs otherwise kzalloc will not initialize the full object (this caused the failure on various platforms). - Padding checks before redzone checks so that we get messages about the corruption of whole slab and not about a single object. V3->V4 - Rename /proc/slabinfo to /proc/slubinfo. We have a different format after all. - More bug fixes and stabilization of diagnostic functions. This seems to be finally something that works wherever we test it. - Serialize kmem_cache_create and kmem_cache_destroy via slub_lock (Adrian's idea) - Add two new modifications (separate patches) to guarantee a mininum number of objects per slab and to pass through large allocations. V2->V3 - Debugging and diagnostic support. This is runtime enabled and not compile time enabled. Runtime debugging can be controlled via kernel boot options on an individual slab cache basis or globally. - Slab Trace support (For individual slab caches). - Resiliency support: If basic sanity checks are enabled (via F f.e.) (boot option) then SLUB will do the best to perform diagnostics and then continue (i.e. mark corrupted objects as used). - Fix up numerous issues including clash of SLUBs use of page flags with i386 arch use for pmd and pgds (which are managed as slab caches, sigh). - Dynamic per CPU array sizing. - Explain SLUB slabcache flags V1->V2 - Fix up various issues. Tested on i386 UP, X86_64 SMP, ia64 NUMA. - Provide NUMA support by splitting partial lists per node. - Better Slab cache merge support (now at around 50% of slabs) - List slab cache aliases if slab caches are merged. - Updated descriptions /proc/slabinfo output This is a new slab allocator which was motivated by the complexity of the existing code in mm/slab.c. It attempts to address a variety of concerns with the existing implementation. A. Management of object queues A particular concern was the complex management of the numerous object queues in SLAB. SLUB has no such queues. Instead we dedicate a slab for each allocating CPU and use objects from a slab directly instead of queueing them up. B. Storage overhead of object queues SLAB Object queues exist per node, per CPU. The alien cache queue even has a queue array that contain a queue for each processor on each node. For very large systems the number of queues and the number of objects that may be caught in those queues grows exponentially. On our systems with 1k nodes / processors we have several gigabytes just tied up for storing references to objects for those queues This does not include the objects that could be on those queues. One fears that the whole memory of the machine could one day be consumed by those queues. C. SLAB meta data overhead SLAB has overhead at the beginning of each slab. This means that data cannot be naturally aligned at the beginning of a slab block. SLUB keeps all
Re: usb hid: reset NumLock
On Fri, 30 Mar 2007, Pete Zaitcev wrote:
> @@ -1328,9 +1340,18 @@ static int hid_probe(struct usb_interface *intf, const
> struct usb_device_id *id)
> return -ENODEV;
> }
>
> - if ((hid->claimed & HID_CLAIMED_INPUT))
> + if ((hid->claimed & HID_CLAIMED_INPUT)) {
> hid_ff_init(hid);
>
> + /*
> + * We do this only if input has claimed the device because
> + * we can only find fields after they were configured in
> + * hidinput_connect.
> + */
> + /* if (hid->quirks & HID_QUIRK_RESET_LEDS) */
> + usbhid_set_leds(hid, LED_NUML, 0);
> + }
> +
> if (hid->quirks & HID_QUIRK_SONY_PS3_CONTROLLER)
> hid_fixup_sony_ps3_controller(interface_to_usbdev(intf),
> intf->cur_altsetting->desc.bInterfaceNumber);
Hi Pete,
I think I see an issue here. Imagine that you boot a system initially with
one keyboard connected (usb, ps/2, doesn't matter), and after some time
you connect second USB keyboard (the NumLock is 'on' on the first keyboard
when you connect the second one).
Without your patch, the NumLock led will be OK on the second keyboard
immediately. With your patch, the NumLock will be forced to 'off' and it
will be out of sync with the first keyboard. The leds will get in sync
later when any change occurs.
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index d26b08f..f592f01 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -267,6 +267,7 @@ struct hid_item {
> #define HID_QUIRK_SKIP_OUTPUT_REPORTS0x0002
> #define HID_QUIRK_IGNORE_MOUSE 0x0004
> #define HID_QUIRK_SONY_PS3_CONTROLLER0x0008
> +#define HID_QUIRK_RESET_LEDS 0x0010
I think this is not worth a quirk - when we get it working properly, why
not do it unconditionally for all keyboards?
> URL with details, discussion, rejected patch to read BIOS byte at 0x417:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228674
"You are not authorized to access bug #228674. To see this bug, you must
first log in to an account with the appropriate permissions."
:)
Thanks,
--
Jiri Kosina
-
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.21-rc5-mm3: Why was my vioc cleanup patch dropped?
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote: >... > Changes since 2.6.21-rc5-mm2: >... > -drivers-net-vioc-possible-cleanups.patch >... > Merged into mainline or a subsystem tree. >... Please give me a clue: - This patch is not merged into the netdev tree as included in -mm and - it still applies fine against 2.6.21-rc5-mm3 and - it still compiles fine with 2.6.21-rc5-mm3. TIA 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: missing kretprobes support on avr32 and sparc64
From: Christoph Hellwig <[EMAIL PROTECTED]> Date: Sat, 31 Mar 2007 15:15:22 +0200 > Currently all avr32 and sparc64 don't support kretprobes unlike all > other kprobes supporting architectures. This is not nice from the > user interface point of view and from the ugly ifdefs point of view. > Is there a reason these ports can't support kretprobes or was this > simply an oversight / lazyness? I just haven't gotten around to it yet. Don't worry I'm aware of it. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20.4 crashes
Hi, here's more... BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: *pde = Oops: [#1] Modules linked in: binfmt_misc sit nfs lockd nfs_acl sunrpc ipt_ECN iptable_mangle w83627ehf i2c_isa i2c_viapro i2c_core via_agp agpgart rtc CPU:0 EIP:0060:[<>]Not tainted VLI EFLAGS: 00010016 (2.6.20.3-cks1 #4) EIP is at 0x0 eax: e94a5e6c ebx: e94a5e6c ecx: edx: 0001 esi: edi: e94a5e84 ebp: e94a5e6c esp: e94a5e4c ds: 007b es: 007b ss: 0068 Process grep (pid: 9156, ti=e94a4000 task=f4569a90 task.ti=e94a4000) Stack: c0116429 0001 0001 ec7da800 0286 e94a5e84 c0117802 ec7da800 ec7da800 ec7da85c c015c622 e9d02b40 e94a5f60 f77b6ac0 0400 c0313e6c 1000 Call Trace: [] __wake_up_common+0x39/0x70 [] __wake_up+0x22/0x30 [] pipe_write+0x222/0x4b0 [] do_sync_write+0xc7/0x110 [] autoremove_wake_function+0x0/0x50 [] vfs_write+0xa6/0x160 [] do_sync_write+0x0/0x110 [] sys_write+0x41/0x70 [] sysenter_past_esp+0x5f/0x85 [] ipv6_flowlabel_opt+0x193/0x730 === Code: Bad EIP value. EIP: [<>] 0x0 SS:ESP 0068:e94a5e4c <3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20 in_atomic():0, irqs_disabled():1 [] down_read+0x12/0x20 [] acct_collect+0x38/0x120 [] do_exit+0xda/0x750 [] printk+0x1b/0x20 [] do_trap+0x0/0x100 [] do_page_fault+0x2da/0x630 [] do_page_fault+0x0/0x630 [] error_code+0x74/0x7c [] __wake_up_common+0x39/0x70 [] __wake_up+0x22/0x30 [] pipe_write+0x222/0x4b0 [] do_sync_write+0xc7/0x110 [] autoremove_wake_function+0x0/0x50 [] vfs_write+0xa6/0x160 [] do_sync_write+0x0/0x110 [] sys_write+0x41/0x70 [] sysenter_past_esp+0x5f/0x85 [] ipv6_flowlabel_opt+0x193/0x730 === BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: *pde = Oops: [#2] Modules linked in: binfmt_misc sit nfs lockd nfs_acl sunrpc ipt_ECN iptable_mangle w83627ehf i2c_isa i2c_viapro i2c_core via_agp agpgart rtc CPU:0 EIP:0060:[<>]Not tainted VLI EFLAGS: 00010087 (2.6.20.3-cks1 #4) EIP is at 0x0 eax: e94a5e6c ebx: e94a5e6c ecx: edx: 0001 esi: edi: e94a5e84 ebp: e94a5ccc esp: e94a5cac ds: 007b es: 007b ss: 0068 Process grep (pid: 9156, ti=e94a4000 task=f4569a90 task.ti=e94a4000) Stack: c0116429 0001 0001 ec7da800 0286 ec7da800 e94a5ce4 c0117802 0001 e9d02ad4 c015c069 e9d02b40 0008 e9d02ad4 f77b6ac0 c0157b20 Call Trace: [] __wake_up_common+0x39/0x70 [] __wake_up+0x22/0x30 [] pipe_release+0x59/0xb0 [] __fput+0xb0/0x180 [] filp_close+0x47/0x80 [] put_files_struct+0x9c/0xb0 [] do_exit+0x115/0x750 [] printk+0x1b/0x20 [] do_trap+0x0/0x100 [] do_page_fault+0x2da/0x630 [] do_page_fault+0x0/0x630 [] error_code+0x74/0x7c [] __wake_up_common+0x39/0x70 [] __wake_up+0x22/0x30 [] pipe_write+0x222/0x4b0 [] do_sync_write+0xc7/0x110 [] autoremove_wake_function+0x0/0x50 [] vfs_write+0xa6/0x160 [] do_sync_write+0x0/0x110 [] sys_write+0x41/0x70 [] sysenter_past_esp+0x5f/0x85 [] ipv6_flowlabel_opt+0x193/0x730 === Code: Bad EIP value. EIP: [<>] 0x0 SS:ESP 0068:e94a5cac <1>Fixing recursive fault but reboot is needed! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] [SCSI]stex: fix reset recovery for console device
On Fri, 2007-03-30 at 15:21 -0700, Ed Lin wrote: > After reset completed, the scsi error handler sends out START_STOP > and TEST_UNIT_READY to the device. For 'normal' devices these > commands will be handled by firmware. However, because the RAID > console only interfaces to scsi mid layer, the firmware will not process > these commands for it. This will make the console to be offlined right > after reset. Add the handling in driver to fix this problem. I don't see how this explanation can be correct. The error handler only sends a START_STOP command if sdev->allow_restart is one, which you have to set in the slave_configure routines (which stex doesn't). If you're seeing a START_STOP in the eh path, there's something else wrong. TEST_UNIT_READY, certainly ... it's part of a restart check. James - 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: mcdx -- do_request(): non-read command to cd!!
On 03/31/2007 08:47 AM, Jens Axboe wrote:
Try this.
diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c
index f574962..7086313 100644
--- a/drivers/cdrom/mcdx.c
+++ b/drivers/cdrom/mcdx.c
@@ -577,6 +577,11 @@ static void do_mcdx_request(request_queue_t * q)
if (!req)
return;
+ if (!blk_fs_request(req)) {
+ end_request(req, 0);
+ goto again;
+ }
+
stuffp = req->rq_disk->private_data;
if (!stuffp->present) {
@@ -596,7 +601,7 @@ static void do_mcdx_request(request_queue_t * q)
xtrace(REQUEST, "do_request() (%lu + %lu)\n",
req->sector, req->nr_sectors);
- if (req->cmd != READ) {
+ if (rq_data_dir(req) != READ) {
xwarn("do_request(): non-read command to cd!!\n");
xtrace(REQUEST, "end_request(0): write\n");
end_request(req, 0);
Thank you! Yes, that works in so far that it now indeed does actually
mount the CD:
[EMAIL PROTECTED]:~# mount -t iso9660 /dev/mcdx0 /mnt/cdrom
mount: block device /dev/mcdx0 is write-protected, mounting read-only
[EMAIL PROTECTED]:~# ls /mnt/cdrom/
dott dott.exe dottdemo indydemo rebel samdemo
There's quite a bit of noise in dmesg though. Repeated 5 times:
===BUG: scheduling while atomic: mount/0x0001/1166
[] __sched_text_start+0x57/0x574
[] schedule_timeout+0x70/0x8f
[] process_timeout+0x0/0x5
[] interruptible_sleep_on_timeout+0x5d/0xa5
[] default_wake_function+0x0/0xc
[] mcdx_xfer+0xae/0x2a5 [mcdx]
[] cfq_init_prio_data+0x57/0x12a
[] cfq_get_queue+0x119/0x16e
[] cfq_set_request+0x0/0x131
[] elv_set_request+0x14/0x22
[] elv_rb_del+0x23/0x31
[] cfq_remove_request+0x63/0xd9
[] elv_dispatch_sort+0x1c/0x67
[] cfq_dispatch_insert+0x38/0x4c
[] __cfq_dispatch_requests+0x72/0x1ad
[] cfq_dispatch_requests+0x50/0x77
[] sync_buffer+0x0/0x2e
[] elv_next_request+0x5d/0x105
[] sync_buffer+0x0/0x2e
[] do_mcdx_request+0x9b/0xd2 [mcdx]
[] __generic_unplug_device+0x1d/0x1f
[] generic_unplug_device+0x11/0x29
[] blk_backing_dev_unplug+0xc/0xd
[] sync_buffer+0x26/0x2e
[] __wait_on_bit+0x2c/0x51
[] out_of_line_wait_on_bit+0x6f/0x77
[] sync_buffer+0x0/0x2e
[] wake_bit_function+0x0/0x3c
[] wake_bit_function+0x0/0x3c
[] __wait_on_buffer+0x22/0x25
[] __bread_slow+0x4b/0x60
[] __bread+0x18/0x1d
[] isofs_fill_super+0xf0/0x5d7 [isofs]
[] radix_tree_delete+0x177/0x1a0
[] get_sb_bdev+0xc6/0x10f
[] mntput_no_expire+0x11/0x73
[] alloc_vfsmnt+0x97/0xbe
[] isofs_get_sb+0x20/0x25 [isofs]
[] isofs_fill_super+0x0/0x5d7 [isofs]
[] vfs_kern_mount+0x40/0x6f
[] do_kern_mount+0x2a/0x3a
[] do_new_mount+0x64/0x93
[] do_mount+0x185/0x19a
[] __wake_up_locked+0x1e/0x20
[] default_wake_function+0x0/0xc
[] sys_mount+0x79/0xb5
[] syscall_call+0x7/0xb
===
Any access results in te above. A copy from the CD segfaulted:
===
[EMAIL PROTECTED]:~# cp /mnt/cdrom/dott.exe .
malloc: unwind_prot.c:247: assertion botched
free: called with unallocated block argument
Segmentation fault
===
This sounds like a userspace problem but I sure haven't seen it before.
There's a few "blk: request botched" followed by similar backtraces in
the log after that.
It looks like mcdx_xfer() is seriously broken. If you don't particularly
care for spending time on this thing -- feel free. To top it off, if you
unload the module, it doesn't clean up after itself and the IRQ is kept
in use (and a cat /proc/interrupts faults).
I'm only using the thing for the heck of it...
Rene.
-
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-pm] [PATCH v2] Add suspend/resume for HPET
( please remove obsolute [EMAIL PROTECTED] from further messages!! )
On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
>
> i dont think there's any particular problem here because suspend/resume
> wont be done during bootup - but we might need a way to move a device to
> earlier spots in the device tree, even if they got registered later on -
> instead of forcing the time devices to be registered very early?
I'm about ready to test the appended patch... a "move one device" call
might be safest at this point in the release cycle though.
- Dave
SNIP!
Change how the PM list is constructed, so that devices are added right
after their parents (when they have one) rather than at the end of the
list. This preserves sequencing guarantees, but enables sequencing of
suspend/resume operations by more important characteristics than "when
device happened to enumerate" ... e.g. clocksources and clockevents
at a clearly defined point during suspend and resume.
This patch has a potential downside for devices that have multiple
power dependencies and which "just happened to work" before.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- g26.orig/drivers/base/power/main.c 2006-07-02 12:30:30.0 -0700
+++ g26/drivers/base/power/main.c 2007-03-31 11:02:28.0 -0700
@@ -52,12 +52,17 @@ EXPORT_SYMBOL_GPL(device_pm_set_parent);
int device_pm_add(struct device * dev)
{
int error;
+ struct device *parent = dev->parent;
- pr_debug("PM: Adding info for %s:%s\n",
-dev->bus ? dev->bus->name : "No Bus", dev->kobj.name);
+ pr_debug("PM: Adding info for %s:%s, after %s\n",
+dev->bus ? dev->bus->name : "No Bus", dev->kobj.name,
+parent ? parent->bus_id : "(no parent)");
down(_list_sem);
- list_add_tail(>power.entry, _active);
- device_pm_set_parent(dev, dev->parent);
+ if (parent)
+ list_add(>power.entry, >power.entry);
+ else
+ list_add_tail(>power.entry, _active);
+ device_pm_set_parent(dev, parent);
if ((error = dpm_sysfs_add(dev)))
list_del(>power.entry);
up(_list_sem);
-
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.21-rc5: known regressions with patches (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: hung bootup in various drivers References : http://lkml.org/lkml/2007/3/30/68 Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Kay Sievers <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/3/30/323 Status : patch available Subject: NCQ problem with ahci and Hitachi drive References : http://lkml.org/lkml/2007/3/4/178 http://lkml.org/lkml/2007/3/9/475 http://lkml.org/lkml/2007/2/22/8 Submitter : Mathieu Bérard <[EMAIL PROTECTED]> Handled-By : Tejun Heo <[EMAIL PROTECTED]> Robert Hancock <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/2/22/8 Status : possible patch available Subject: suspend to disk hangs (microcode driver) References : http://lkml.org/lkml/2007/3/16/126 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> Caused-By : Rafael J. Wysocki <[EMAIL PROTECTED]> commit e3c7db621bed4afb8e231cb005057f2feb5db557 commit ed746e3b18f4df18afa3763155972c5835f284c5 commit 259130526c267550bc365d3015917d90667732f1 Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/3/25/71 Status : patch available - 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 v2] Add suspend/resume for HPET
On Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote: > yeah. There's some practical problems that need to be sorted out: much > of the current GTOD code is irq-driven (and all GTOD locks are > irq-safe), while the sysfs code needs to run in process-context level. > > Clocksources 'arrive' and 'depart' in hardirq context (which is the > primary place where we notice their breakage, determine that they are > now verified to be usable, etc.). This came partly from legacy: the > gradual conversion of the monolithic time code, and the need to preserve > GTOD and non-GTOD architectures without too much duplication. It also > came partly because there's also a fundamental need to have accurate > time, which is better served from irq context. > Is this in reference to the irq-context clocksource polling stuff? I don't see a dire reason to keep that code, and I agree removing that is a certainly a worth while cleanup .. I added this cleanup to one of my trees when you first suggested it , and there is some infrastructure that really should be added to facilitate it. 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: [linux-pm] [PATCH v2] Add suspend/resume for HPET
On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote: > > On Sat, 31 Mar 2007, Thomas Gleixner wrote: > > > > Right, but clock - sources/events need to be extremly late suspended and > > early resumed. How can we ensure this ? > > Make them be at the top of the device tree by adding them early. That's > the whole point of the device tree after all - we have an ordering that is > enforced by its topology, and that we sort by when things were added. Right, but "when things get added" doesn't correlate well to "when they should get suspended/resumed". It's also in basic conflict with runtime PM models, where devices may be suspended at essentially any time. And sysdevs are even stranger. One way out: rather than constructing that list as devices get enumerated, it could be constructed by a (linear-time, non-recursive) walk of the device tree(s) before they get suspended. (Or equivalently: construct lists at enumeration time, but just adding them *right after their parent* rather than at the end of the list.) Would that solve the problem here? Potentially ... if the tree is structured to meet Thomas' rules: > > The required resume order is: > > > > clocksources > > timekeeping > > clockevents > > tick management > So the only thing that needs to be done is to make sure that we add the > timer devices early during bootup - something we have to do *anyway*. If a > device is added early in bootup, that automatically means that it will be > suspended late, and resumed early - because we maintain that order all the > way through.. > -- "clocksource" -- +-- HPET > | > +-- TSC > | > +-- i8259 > | > +-- lapic timer > | > .. whatever else If each of those were a device node, with "clocksource" suspend/resume methods handling Thomas' "timekeeping" item, and simlarly for "clockevent" devices ... I could see that all working neatly. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] remove artificial software max_loop limit
On Sat, 31 Mar 2007 10:07:43 -0700 Greg KH <[EMAIL PROTECTED]> wrote: > On Fri, Mar 30, 2007 at 02:15:24PM -0700, Andrew Morton wrote: > > On Fri, 30 Mar 2007 02:25:37 -0700 > > "Ken Chen" <[EMAIL PROTECTED]> wrote: > > > > > -module_param(max_loop, int, 0); > > > -MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)"); > > > > So.. this change will cause a fatal error for anyone who is presently > > using max_loop, won't it? If they're doing that within their > > initramfs/initrd/etc then things could get rather ugly for them. > > > > I don't know how much of a problem this will be in practice - do people use > > max_loop much? > > Yes, the distros do, and they recommend it to their users a lot. Thanks. In that case I think we should retain the max_loop module parameter for now. Ken, when you respin that patch could you restore max_loop, and make its use trigger a warning along the lines of "loop: the max_loop option is obsolete and will be removed in March 2008"? - 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 v2] Add suspend/resume for HPET
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > Umm.. WHy not make the device tree look like this: > > -- "clocksource" -- +-- HPET > | > +-- TSC > | > +-- i8259 > | > +-- lapic timer > | > .. whatever else > > and use the "struct device" that we *have* for this? The whole "struct > device" is literally designed to do this, and to be embedded into > whatever bigger structures you have that describes higher-level > behaviour. Ie you'd put a "struct device" inside the "struct > clocksource". yeah. There's some practical problems that need to be sorted out: much of the current GTOD code is irq-driven (and all GTOD locks are irq-safe), while the sysfs code needs to run in process-context level. Clocksources 'arrive' and 'depart' in hardirq context (which is the primary place where we notice their breakage, determine that they are now verified to be usable, etc.). This came partly from legacy: the gradual conversion of the monolithic time code, and the need to preserve GTOD and non-GTOD architectures without too much duplication. It also came partly because there's also a fundamental need to have accurate time, which is better served from irq context. i very much agree that this should and must be cleaned up, but it needs quite a bit more logistics than it might appear at first sight. Clockevents basically just followed (and had to follow) the direction of clocksources in this regard. Ingo - 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 v2] Add suspend/resume for HPET
On Sat, 31 Mar 2007, Maxim Levitsky wrote: > > So maybe I was right afrer all, > Maybe it is better to add a suspend/resume hook to each clock source and call > it from timekeeping_resume() ? Umm.. WHy not make the device tree look like this: -- "clocksource" -- +-- HPET | +-- TSC | +-- i8259 | +-- lapic timer | .. whatever else and use the "struct device" that we *have* for this? The whole "struct device" is literally designed to do this, and to be embedded into whatever bigger structures you have that describes higher-level behaviour. Ie you'd put a "struct device" inside the "struct clocksource". That thingalready *has* the suspend/resume hooks, and it will mean that people will see the clocks in the device tree rather than have a new notion. Linus - 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 v2] Add suspend/resume for HPET
On Sat, Mar 31, 2007 at 09:53:43AM -0700, Linus Torvalds wrote: > Make them be at the top of the device tree by adding them early. That's > the whole point of the device tree after all - we have an ordering that is > enforced by its topology, and that we sort by when things were added. > > Right now the way things work is (iirc - somebody like Greg should > double-check me) is that we add all devices to the power list at > device_add() time by traversing the devices fromt he root all the way out, > and doing a device_add() which does a device_pm_add(), which in turn adds > it to the power-management list - so that the list is always topologically > sorted. Yes, this is how it works (or if not, then there's a bug that needs to be fixed, as that is how it _should_ work...) thanks, greg k-h - 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/
