I can not kexec RHEL 5.1 from 2.6.25-rc3 later caused by: commit 89d694b9dbe769ca1004e01db0ca43964806a611 Author: Thomas Gleixner <tglx@linutronix.de> Date: Mon Feb 18 18:25:17 2008 +0100 genirq: do not leave interupts enabled on free_irq The default_disable() function was changed in commit: 76d2160147f43f982dfe881404cfde9fd0a9da21 genirq: do not mask interrupts by default It removed the mask function in favour of the default delayed interrupt disabling. ...

only one root bus, don't need to split that root resources. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> diff --git a/arch/x86/pci/k8-bus_64.c b/arch/x86/pci/k8-bus_64.c index 7ed7f51..c433982 100644 --- a/arch/x86/pci/k8-bus_64.c +++ b/arch/x86/pci/k8-bus_64.c @@ -69,7 +69,8 @@ void set_pci_bus_resources_arch_default(struct pci_bus *b) int j; struct pci_root_info *info; - if (!pci_root_num) + /* if only one root bus, don't need to anything */ + if (pci_root_num < 2) ...

Hi! I'm getting the following messages at the very end of dmesg after booting in a new laptop (Dell Vostro 1500, bought about four months ago) in (all?) -rc releases: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } hda: task_no_data_intr: error=0x04 { AbortedCommand } ide: failed opcode was: 0xef The laptops works perfectly, so I'm not sure if there is a problem with the hard disk / controller, with the kernel or with nothing at all. Just in case, I'm reporting ...

A long long time ago when dinosaurs roamed the earth and tech company stock valuations were high (2001), the primitive of the completion was introduced to save us from a problem with semaphores. Those interested in the details can examine http://www.ussg.iu.edu/hypermail/linux/kernel/0107.3/0674.html and related messages, but everyone else can take my word for it that, with the generic semaphores I hope will be merged in 2.6.26, semaphores no longer have the problem that caused us to switch to ...

Is it 100% reproducable? I mean sometimes I also have complete lockup right after one of eth interfaces shutdown during shutdown sequence. And it's also recent. But it triggers ~1 time in 10 subjectively.. --

After about 4 restarts and 4 reboots, 2.6.25-rc9 seems to work fine with and without the revert. I'll do some more testing. The assembly output files for kernel/printk.c don't seem that different between rc9 and rc7. I'll see what else I can test. Thanx --

Ok, I suspect it may be timing-dependent and slightly random. Sadly, that is absolutely the case where "git bisect" works the worst. The end result of bisection will basically be _totally_ random if even one of the "git bisect bad/good" choises were wrong - doing a binary search is a very efficient way to find the buggy commit, but it also means that a single wrong turn will efficiently find a commit that is somewhere totally different. So if your shutdown/reboot regression is even ...

rfkill really should have been named rfswitch. As it is, one can get confused whether RFKILL_STATE_ON means the KILL switch is on (and therefore, the radio is being *blocked* from operating), or whether it means the RADIO rf output is on. Clearly state that RFKILL_STATE_ON means the radio is *unblocked* from operating (i.e. there is no rf killing going on). Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: John W. Linville ...

Some devices (notably laptops) have read-only rfkill switches. Those devices are slider or rocker switches that are *physically* manipulated by the user, most of the time tied to hardware or firmware functions that automatically rf-kill and/or hot-unplug radio devices when in the "radios off" position. Software must not (and in fact, cannot) attempt to change the state of any such switch. These switches exist because of international regulations regarding radio emission devices on airplanes ...

I know it is easier to complain than to submit code, but at this point, shouldn't we make this dynamic? [so that the interested technology that provides an rfkill switch registers it?]. Something that given a technology name registers a dynamic key and type number that can be use throughout? -- Inaky --

Currently, radios are always enabled when their rfkill interface is registered. This is not optimal, the safest state for a radio is to be offline unless the user turns it on. Add a module parameter that causes all radios to be disabled when their rfkill interface is registered. Add override parameters for each rfkill switch type as well, just in case the user wants the defaults to be different for a given radio type. We don't change the module default, but I'd really recommed doing so in ...

I wouldn't have anything against that, but we do need to coalesce the types when possible, otherwise the "type" notion becomes useless for rfkill-input. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

I have a current version of the documentation tree at: git://git.lwn.net/linux-2.6.git docs There are a couple of code comment changes, but no changes to any code itself. It's safe to pull now (and it would be nice to get a couple of these changes in), but can also easily wait for the merge window to open. What's there: J. Bruce Fields (4): Spell out behavior of atomic_dec_and_lock() in kerneldoc Documentation: move nfsroot.txt to filesystems/ Documentation: move ...

Initialize I2C pins on boards with CPM1/CPM2 controllers. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++++++++++ arch/powerpc/boot/dts/mpc866ads.dts | 10 ++++++++++ arch/powerpc/boot/dts/mpc885ads.dts | 10 ++++++++++ arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++++ arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++++ arch/powerpc/platforms/8xx/mpc885ads_setup.c | 3 +++ 6 files changed, 41 ...

Looks good to me. Thanks. --- ~Randy --

This patch implements various helpers to support OF bindings for the i2c API. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- drivers/of/Kconfig | 6 +++ drivers/of/Makefile | 1 + drivers/of/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/of_i2c.h | 24 ++++++++++ 4 files changed, 146 insertions(+), 0 deletions(-) create mode 100644 drivers/of/i2c.c create mode 100644 include/linux/of_i2c.h diff --git a/drivers/of/Kconfig ...

No - it's not wild like it was back in the early X2 days and I think you're right about the drift being normal. Interesting thing though I am running ntpd and it's not working. I am fairly sure the ntp.conf file is exactly as it was installed by fedora. I'm now looking into that. Thanks for your help. Sorry for the false alarm. But if thee was an issue I thought you would want to know it. Marc Perkel Junk Email Filter dot ...

I have found that ntp tends to fail to work on any machine with spread spectrum clocking enabled. On those machines disabling spread specturm in the BIOS seems to fix it. I had to update the BIOS on one machine to even get the option to disable it though. -- Len Sorensen --

I was just wondering if there were any known issues with AMD quad core phenom clock drift problems? I';m running a 2.6.24 kernel and it's losing time. I remember the first dual core AMD chips had a lot of clock issues. If this is something new let me know what information to check and post to this list. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam ...

When reporting clock problems, please post dmesg. This has all the interesting timekeeping-related log messages from the kernel. Please also describe the drift quantitatively. -- Chris --

I don't know if this is related, however check http://marc.info/?l=linux-kernel&m=120784269708442&w=2 --

While compiling linux-2.6.25-rc8-git7 with CONFIG_DEBUG_SECTION_MISMATCH=y, I noticed the following "section mismatch" warnings. Please CC me as I'm not subscribed to this list. WARNING: vmlinux.o(.text+0x10d58): Section mismatch in reference from the function cpu_exit_clear() to the function .cpuinit.text:cpu_uninit() The function cpu_exit_clear() references the function __cpuinit cpu_uninit(). This is often because cpu_exit_clear lacks a __cpuinit annotation or the annotation of cpu_uninit ...

On Fri, 11 Apr 2008 20:28:27 +0300 Acked-by: Alan Cox <alan@redhat.com> --

I'm poking around with some scheduler stuff, and there's something I'm not clear on for the CFS runqueue locks. The comments before __load_balance_iterator(...) in sched_fair.c suggests things can be dequeued even though the runqueue lock is held. Can things also be added to the queue while the lock is held? (Also, either way, what's the rationale that dequeueing is a safe procedure when somebody else holds a lock?) -dan --

/* * Load-balancing iterator. Note: while the runqueue stays locked * during the whole iteration, the current task might be * dequeued so the iterator has to be dequeue-safe. Here we * achieve that by always pre-iterating before returning * the current task: */ I don't think this comment is correct, but if it were, it would only apply to rq->curr, not for any enqueue/dequeue. --

x86: Implement prctl PR_GET_TSC and PR_SET_TSC This patch adds a configure option CONFIG_DISABLE_TSC (off by default) for the x86 platform to enable the PR_GET_TSC and PR_SET_TSC commands. These control the ability to use the timestamp counter from userspace (the RDTSC instruction.) This patch uses code earlier used to disable the timestamp counter for the SECCOMP framework. It used to disable the RDTSC on 32 bit kernels, but allow it on x86_64. ...

[PATCH 13/13] With the previous patch ipc_lock() becomes lockless. So there is no need anymore for ipc_lock_down()-like routines. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- ipc/shm.c | 21 +++------------------ ipc/util.c | 52 +--------------------------------------------------- ipc/util.h | 6 ------ 3 files changed, 4 insertions(+), 75 deletions(-) Index: linux-2.6.25-rc8-mm1/ipc/util.h =================================================================== --- ...

[PATCH 11/13] From now on the ridr code can be compiled and used (the initialization routine is called during kernel init). Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- init/main.c | 2 ++ lib/Makefile | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) Index: linux-2.6.25-rc8-mm1/lib/Makefile =================================================================== --- linux-2.6.25-rc8-mm1.orig/lib/Makefile 2008-04-11 17:14:08.000000000 +0200 +++ ...

[PATCH 09/13] This patch only fixes the sub_remove() and ridr_remove() portions of ridr.c, to make them RCU based. Note: also fixes idr_remove(): looks like there is a return that is not at the right place. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- include/linux/idr.h | 1 + lib/idr.c | 9 +++++---- lib/ridr.c | 29 +++++++++++++---------------- 3 files changed, 19 insertions(+), 20 deletions(-) Index: ...

[PATCH 07/13] This patch only fixes the ridr_get_empty_slot() portion of ridr.c, to make it RCU based. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- lib/ridr.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) Index: linux-2.6.25-rc8-mm1/lib/ridr.c =================================================================== --- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:51:34.000000000 +0200 +++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 17:55:37.000000000 ...

[PATCH 05/13] This patch only fixes the free_layer() portion of ridr.c, to make it use call_rcu(). Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- lib/ridr.c | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-) Index: linux-2.6.25-rc8-mm1/lib/ridr.c =================================================================== --- linux-2.6.25-rc8-mm1.orig/lib/ridr.c 2008-04-11 17:43:44.000000000 +0200 +++ linux-2.6.25-rc8-mm1/lib/ridr.c 2008-04-11 ...

[PATCH 03/13] This patch only fixes the ridr_pre_get() portion of ridr.c, to introduce a per-cpu pool of preloaded ridr layer structures, and define the ridr_pre_get[_end]() routines. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- include/linux/ridr.h | 7 ++++++- lib/ridr.c | 50 ++++++++++++++++++++++++++++++++++++-------------- 2 files changed, 42 insertions(+), 15 deletions(-) Index: ...

[PATCH 01/13] This patch duplicates idr.c and idr.h, only changing the routines and structures names where needed. Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net> --- include/linux/ridr.h | 58 +++++++ lib/ridr.c | 386 +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 444 insertions(+) Index: linux-2.6.25-rc8-mm1/include/linux/ridr.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 ...

Here is finally the ipc ridr-based implementation I was talking about last week (see http://lkml.org/lkml/2008/4/4/208). I couldn't avoid much of the code duplication, but at least made things incremental. Does somebody now a test suite that exists for the idr API, that I could run on this new api? Mike, can you try to run it on your victim: I had such a hard time building this patch, that I couldn't re-run the test on my 8-core with this new version. So the last results I have are for ...

I'm doing a couple of cleanups to Documentation/i386/IO-APIC.txt and I have a problem with this line, which is supposed to compute a sample pirq= kernel parameter: echo -n pirq=; echo `scanpci | grep T_L | cut -c56-` | sed 's/ /,/g' The 'scanpci' command used to be part of xutils and/or XFree86. Xorg implements "Xorg -scanpci" but the output is different and it won't run while X is running. Firstly I propose using the $( ) construct rather than backticks, since it is easier to read: ...

Hi, This message is not actually about a new project. It is also not about the Linux Kernel specifically. Rather, I have a question about how your community operates. If you feel this is off-topic, please feel free to ignore it entirely. If you feel that this is off-topic but interesting (my hope) then feel free to email me directly at fred.trotter@gmail.com rather than gum up the mailing list with a 'community' discussion. While this is marginally off-topic, note that it is a ...

ANUNCIE SEU SITE OU SERVI

mpc8272-i2c -Scott --

Based on earlier work by Jon Smirl and Jean Delvare. Remove the old driver_name/type scheme for i2c driver matching. Only the standard aliasing model will be used from now on. Signed-off-by: Jochen Friedrich <jochen@scram.de> Cc: Jean Delvare <khali@linux-fr.org> Cc: Jon Smirl <jonsmirl@gmail.com> --- drivers/i2c/i2c-core.c | 35 +++++++++++++---------------------- include/linux/i2c.h | 9 ++------- 2 files changed, 15 insertions(+), 29 deletions(-) diff --git ...

I've resenf the patch without the dependency on PPC_OF. Thanks for the comment. Jochen --

This patch implements various helpers to support OF bindings for the i2c API. Signed-off-by: Jochen Friedrich <jochen@scram.de> --- drivers/of/Kconfig | 6 +++ drivers/of/Makefile | 1 + drivers/of/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/of_i2c.h | 24 ++++++++++ 4 files changed, 146 insertions(+), 0 deletions(-) create mode 100644 drivers/of/i2c.c create mode 100644 include/linux/of_i2c.h diff --git a/drivers/of/Kconfig ...

Based on earlier work by Jon Smirl and Jean Delvare. This patch allows new-style i2c chip drivers to have alias names using the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this point, the old i2c driver binding scheme (driver_name/type) is still supported. Signed-off-by: Jochen Friedrich <jochen@scram.de> Cc: Jean Delvare <khali@linux-fr.org> Cc: Jon Smirl <jonsmirl@gmail.com> --- drivers/hwmon/f75375s.c | 21 ++++++++---- drivers/i2c/chips/ds1682.c ...

someone mucked around with the cgroup api; this should fix it: Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- diff --git a/kernel/sched.c b/kernel/sched.c index 7119895..8b4e0b6 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -8291,8 +8291,8 @@ static struct cftype cpu_files[] = { }, { .name = "rt_period_us", - .read_uint = cpu_rt_period_read_uint, - .write_uint = cpu_rt_period_write_uint, + .read_u64 = cpu_rt_period_read_uint, + .write_u64 = ...

Yeah, no worries, I recognised it the moment I looked at it. This is just a merge artefact from changes in different trees. --

CC kernel/sched.o kernel/sched.c:8294: error: unknown field 'read_uint' specified in initializer kernel/sched.c:8294: warning: initialization makes integer from pointer without a cast kernel/sched.c:8295: error: unknown field 'write_uint' specified in initializer kernel/sched.c:8295: warning: initialization from incompatible pointer type # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc8-mm2 # Fri Apr 11 09:36:32 2008 # # CONFIG_64BIT is not ...

Sorry - this change was in my original API patch (plus renaming the read/write functions to have u64 suffices) but I think it collided with the git-sched instability around the end of February. Paul --

D'oh! Many thanks, I could repeat this again and again and I wouldn't have noticed :S cu Anthony --

First of all, I'd like to introduce myself, my name is Anthony and I've been using linux during the last 8 years. I have googled around and I haven't found anything so let's go to the question: It seems that when initializing either KBUILD_OUTPUT or O variables (make KBUILD_OUTPUT="../build/" ) there is a problem, the output is effectivly working, but the problem is that some files (.config) that has been generated at the begining of the make process, are later used and as a consecuence, the ...

I think I know what locking around shared resources is for, which is why I'm surprised the kernel doesn't do it. Is it normal for a kernel resource not to be thread-safe (i.e. you don't get advertised/sensible results if two threads access it at the same I could accept (though I haven't thought about it) that there aren't any real-world applications that do simultaneous reads and writes through the same file pointer. I might even accept that there can be no useful application that ...

If two threads are changing one filehandle at the same time, then the program is broken. I can't see how the kernel making updates to 64bit filehandles "atomic" helps. You could still seek in one thread, then seek in another and then start the write in the first and get a wrong result. Changes to a shared filehandle of any kind requires locking to work reliably, so additional slow downs and locking in the kernel won't Unless the application has it's own locking to ensure multiple ...

This patch fixes section mismatch warnings in unlock_ExtINT_logic(). WARNING: arch/x86/kernel/built-in.o(.text+0x14a92): Section mismatch in reference from the function unlock_ExtINT_logic() to the function .init.text:find_isa_irq_pin() The function unlock_ExtINT_logic() references the function __init find_isa_irq_pin(). This is often because unlock_ExtINT_logic lacks a __init annotation or the annotation of find_isa_irq_pin is wrong. Signed-off-by: Jacek Luczak ...

This patch fixes mismatch warnings in smp_checks() (in arch/x86/kernel/smpboot.c): WARNING: arch/x86/kernel/built-in.o(.text+0x11922): Section mismatch in reference from the function smp_checks() to the variable .cpuinit.data:smp_b_stepping The function smp_checks() references the variable __cpuinitdata smp_b_stepping. This is often because smp_checks lacks a __cpuinitdata annotation or the annotation of smp_b_stepping is wrong. Signed-off-by: Jacek Luczak <luczak.jacek@gmail.com> --- ...

Hi, those patches fixes some section mismatch warnings, which appear on x86_64 with linux-next-200804[09,10,11]. It's continuation of work on section mismatches which result in two patches send previously: - http://lkml.org/lkml/2008/4/10/88 - http://lkml.org/lkml/2008/4/10/290 Patches are against x86/latest. -Jacek --

↓?▼↖◆▼×♀ ﹦校園網路二手書店-歡迎你來尋寶↓ http://book.sam.com.tw/ 這是一個完全免費開放的二手書買賣平台 現在註冊還送1,000點註冊金(相當於台幣$1,000喔) 有書要出清的歡迎PO上來賣吧^.^ 當然想買書的人也歡迎上來尋寶阿^^ ∴?←■⊙▼∴⊕

Hi, I need to have many processes all reading from userspace the counter register of the (same) HPET hardware. Just reading counter values, not handling timers, enabling/disabling interrupts etc. `/dev/hpet' doesn't allow for this, as the number of times it can be opened is limited by the number of timers available. What would be the right way to implement such a support? For now, I simply register a new misc device, '/dev/hpetctr', along with '/dev/hpet', for the same ACPI device and on ...

Reading HPET registers should not be dangerous in any way, but it might be possible to read other devices' registers that happen to lie inside Yes, definitely. I've wanted to do this patch for some time but haven't There are at least as many available timers as before the change -- a program that tries to use a timer will still get a timer, and now this will succeed even if there are other programs that use only the counter. Even now, for most programs using /dev/hpet, it actually is just ...

That's a pretty unusual policy. Not one that's generally So include <linux/kernel.h> first. There *is* a policy of avoiding extra #includes ... extras slow down builds. - Dave --

Hello again, I just noticed that you need include/asm/types.h also for the CONFIG_HAVE_GPIO_LIB=y case. So the #include can better go to the top of include/asm-generic/gpio.h. I won't send a new version untill you say if it's OK for you to add #includes to that header. Best regards Uwe -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 --

As Andrew Hastings pointed out earlier this all needs to be h->order < MAX_ORDER [got pretty much all the checks wrong off by one]. It won't affect anything on x86-64 but might cause problems on archs which have exactly MAX_ORDER -Andi --

RAID: remove trailing space from printk line drivers/md/*.[ch] contains only one more printk line with a trailing space. Remove it. Signed-off-by: Nick Andrew <nick@nick-andrew.net> --- drivers/md/md.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 61ccbd2..5ebfb4d 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -4152,7 +4152,7 @@ static int hot_remove_disk(mddev_t * mddev, dev_t dev) return 0; ...

You can combine several commits into one in a few ways. Of course the combined commit is an entirely new one (with its own SHA1 etc.). One possible way: # you are at <commit0> $ git cherry-pick --no-commit <commit1> # apply but don't commit yet $ git cherry-pick --edit <commit2> # apply, edit the changelog, commit There will now be a <commit3> whose parent is <commit0>. <commit3> incorporates changes of <commit1> and <commit2>. Another way: # you are at <commit0> $ patch < ...

This patch implements new notifier function to panic_notifier_list. We can change the list of order by debugfs. Thanks, --- Signed-off-by: Takenori Nagano <t-nagano@ah.jp.nec.com> --- diff -uprN linux-2.6.25-rc8-mm1.orig/arch/alpha/kernel/setup.c linux-2.6.25-rc8-mm1/arch/alpha/kernel/setup.c --- linux-2.6.25-rc8-mm1.orig/arch/alpha/kernel/setup.c 2008-04-02 04:44:26.000000000 +0900 +++ linux-2.6.25-rc8-mm1/arch/alpha/kernel/setup.c 2008-04-10 21:30:16.143555075 +0900 @@ -44,14 +44,18 ...

You are adding sysfs files, not debugfs files, please change your announcement text. Also, as you are adding new sysfs files, we need some documentation to be added to Documentation/ABI/ describing what these files are, what are in them, and how to use them. thanks, greg k-h --

BTW. I think I'm seeing some problems perhaps related to change page attr stuff for DEBUG_PAGEALLOC on x86-64. And I don't know if it is the same thing, but some general instability around either the page allocator or slab allocator. The debug pagealloc problems seem to be that a thread suddenly get stuck in the kernel spinning in cpa (usually on one of the locks) and never seems to recover. Once it seemed to be spinning in clear_page_... too, but perhaps could it be messing up the page ...

So I'm thinking it's probably related to this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=523b94... As kmalloc_node() in setup_cpu_cache() returns NULL, it seems likely to be due to the use of GFP_THISNODE in cache_alloc_refill() when calling cache_grow() and that the semantics changed. No idea why page allocator would think your UMA "local node" has no memory though. Pekka --

but ... as i said it in my report, this is a regression since v2.6.24 - v2.6.24 (and a whole bunch of commits since then, i listed the IDs) booted up fine. The commit ID you mention is: v2.6.23-4345-g523b945, way earlier than the good commit IDs. so this is a recent regression. Ingo --

And I'd lose as you're 32-bit. Oh well, that's the price to pay for pretending to know x86 arch internals. --

I'd be willing to put some money on this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ad14... --

Allowing systems without node 0 is a major change for x86. --

In mainline, x86-32-subarch es7000 builds cleanly. .config attached. (CONFIG_ACPI=n) In linux-next, the same .config (with minimal -next changes) fails: arch/x86/mach-es7000/built-in.o: In function `es7000_rename_gsi': next-20080411/arch/x86/mach-es7000/es7000plat.c:64: undefined reference to `es7000_plat' arch/x86/mach-es7000/built-in.o: In function `setup_unisys': next-20080411/arch/x86/mach-es7000/es7000plat.c:89: undefined reference to ...

Greetings list, The moral of this story is probably "don't do that", but... While doing some scheduler testing recently, I ran volanomark, and accidentally left latencytop running. The results were decidedly un-good, and the reason appears to be that MUCH time is spent crawling over a list of (106 loaded) modules. -Mike

last week found: after latest kernel kexec RHEL 5.1 or other stack kernel, the nvidia forcedeth doesn't work anymore. I stared at forcedeth.c two days. and revert every patches about that doesn't help. and figure out 2.6.25-rc2 works. with git-bisect found commit 89d694b9dbe769ca1004e01db0ca43964806a611 Author: Thomas Gleixner <tglx@linutronix.de> Date: Mon Feb 18 18:25:17 2008 +0100 genirq: do not leave interupts enabled on free_irq The default_disable() function was ...

On Fri, Apr 11, 2008 at 12:30 AM, Eric W. Biederman mcp55 is using msi for forcedeth MSI.. will look at the driver in RHEL 5.1 it seems that another server with ck804 works because it is using ioapic. YH --

I've just got a report from a forcedeth user that it doesn't work after a resume from RAM for him any more. Can it be related? Rafael --

When turning on MSI for forcedeth, we do the INTx disable thing (and it's actually necessary for at least some forcedeth-driven hardware); if we're not disabling MSI (and making INTx undisabled), the old kernel may not undisable INTx but expect to have legacy interrupts delivered. -Daniel *This .sig left intentionally blank* --

Sounds like you are not getting any interrupts when you receive a packet. (i.e. The interrupt line is staying disabled). Is MSI an option here? I'm wondering if we disable the MSI and something is not enabling it. Eric --

On Fri, Apr 11, 2008 at 12:30 AM, Eric W. Biederman after setpci -s 0x00:08.0 0x60.b=0xfe the eth0 can get ip address with ifup eth0. YH

Commit 54a015104136974262afa4b8ddd943ea70dec8a2 adds some new magic asmlinkage_protect gizmo, but that can only be used from C code, not assembly. Protect relevant bits of <linux/linkage.h> with !__ASSEMBLY__ so this can't leak into assembly source. Fixes a couple build errors on my boxes, AS arch/parisc/kernel/pacache.o In file included from arch/parisc/kernel/pacache.S:40: include/linux/linkage.h:34: error: syntax error in macro parameter list make[1]: *** ...

From: Kay Sievers <kay.sievers@vrfy.org> Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable MMC host platform drivers, to re-enable auto loading. Also, add missing owner declarations in driver init. [ dbrownell@users.sourceforge.net: registration fixes ] Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> --- drivers/mmc/host/at91_mci.c | ...

[Harvey Harrison - Thu, Apr 10, 2008 at 08:38:57PM -0700] [...] | + | +static inline void __put_unaligned_be16(u16 val, u8 *p) | +{ | + *p++ = val >> 8; | + *p++ = val; | +} | + [...] | +static inline void __put_unaligned_le16(u16 val, u8 *p) | +{ | + *p++ = val; | + *p++ = val >> 8; | +} [...] Hi Harvey, do we really need second increments? I mean, wouldn't be better to use *p = val >> 8 and *p << 8? - Cyrill - --

From: David Howells <dhowells@redhat.com> No, I think it has something to do with what cases GCC is allowed to optimize the call inline and what cases it cannot wrt. alignment of datums. --

OK, just let me know what you decide. I'm stil open to bringing back I suppose an out-of-line version could be easily added to accomplish this. It would be identical to the byteshifting implementation-wise. Let me know if you'd like me to spin such a patch. Harvey --

That's memmove, not memmov. Any why memmove, not memcpy? Is __tmp likely to overlap with *ptr? Also, for FRV, I think calling memmove/memcpy for MMU kernels may be the wrong thing to do... I'm sort of leaning towards doing the same thing as NOMMU kernels and just using your inline ones. The advantage of the inline ones is that they are quicker and probably involve fewer instructions executed; whereas using memcpy/memmove may end up with smaller, but slower code. Hmmm... Maybe key on ...

Well, now's the time to decide on something as I'm changing every arch. What is the general pattern used for this kind of thing? Or am I just asking what color to paint this bikeshed? Harvey --

Unaligned access is ok for the following arches: cris, m68k, mn10300, powerpc, s390, x86 Arches that use the no-builtin-memcpy implementation: h8300, m32r, xtensa generic_le: alpha, blackfin, ia64, generic_be: parisc, sparc, sparc64 generic_le or be, choice based on compiler flags: mips, sh m86knommu is generic_be for Coldfire, otherwise unaligned access is ok. frv uses the no_builtin_memcpy implementation when there is an MMU configured, otherwise uses the generic be ...

nomerge doesn't help as well as turning on combinations of SLUB debug options. --

Hi Alexey, That's odd. I don't immediately see anything there that can cause a this... Can you see the hang with the 'for-mm' branch of my tree: git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git If so, can you do a git bisect? Does sysrq-t tell us anything? Pekka --

I bisected boot hang after "ACPI: using IOAPIC for interrupt routing" down to git-pekka. normal dmesg from 2.6.25-rc8-something and .config snippets for -mm # CONFIG_SLUB_DEBUG is not set (hey, I thought this was on!) CONFIG_SLUB=y # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_DEBUG_FS is not ...

I bisected boot hang after "ACPI: using IOAPIC for interrupt routing" down to git-pekka. normal dmesg from 2.6.25-rc8-something and .config snippets for -mm # CONFIG_SLUB_DEBUG is not set (hey, I thought this was on!) CONFIG_SLUB=y # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_DEBUG_FS is not ...

On Fri, 11 Apr 2008 20:17:24 +0900 Sorry, I tested *master* branch ;), under *testing* branch it reproduced. bisected. (see below) I'm sorry I can't use my box for next 2 days. I can test possible fix on Monday (in Japan). ==bisect result== 831d78b552aade2c383cf8d75b180dd35f81a4e3 is first bad commit commit 831d78b552aade2c383cf8d75b180dd35f81a4e3 Author: Christoph Lameter <clameter@sgi.com> Date: Tue Apr 8 22:26:30 2008 +0300 SLUB: Add KICKABLE to avoid repeated kick() ...

On Fri, 11 Apr 2008 13:34:18 +0300 will try. Thanks, -Kame --

Alexey, can you try passing the 'slub_nomerge' option to the kernel to see if the hang goes away with that? Pekka --

My bad, sorry. Fixed and pushed out. From: Pekka Enberg <penberg@cs.helsinki.fi> Date: Fri, 11 Apr 2008 17:17:43 +0300 Subject: [PATCH] slub: add missing slab_unlock() to __kmem_cache_shrink() If page is not kickable, remember to slab_unlock() before continuing the loop. Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi> --- mm/slub.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index 4b694a7..f09f1fb 100644 --- a/mm/slub.c +++ ...

It can already happen that one device writes the sector and other not if the power is interrupted. And all RAID implementations already deal with it by resynchronizing the modified areas in case of crash. So they could resynchronize modify-while-write cases as well, with the same code. ... or I don't know if MM maintainers want to add locking to the pages There would be no problem with fsync. Fsync writes the synced data to both devices. So after a crash you can select any of the ...

Guilt v0.30 is available for download (once it mirrors out on kernel.org). Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like functionality and interface to git. Tarballs: http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/ Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git As promissed, this version includes some interesting changes. The major one being the status file now has a new format. The motivation for this was ...

Yeah, it should be easy to disable the 2MB default and just make it look exactly the same but with 1G pages. Thanks a lot for your suggestion, I'll pull the snapshot over the weekend and try to make it pass on x86 and work with Jon to ensure it Yes I don't like the proc interface, nor the way it has been extended (although that's not Andi's fault it is just a limitation of the old API). I think actually we should have individual directories for each hstate size, and we can put all other ...

Not if (some) kernel assembly files are preprocessed with -traditional-cpp or -traditional, which supports neither GNU style arg... nor ISO C99 ... + __VA_ARGS__ vararg macros. Jakub --

You can simply ditch the line. 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 --

Yeah, I figured it out eventually. I do think the architectures should try to avoid it, if only because x86 doesn't use -traditional (so they'll hit things like this unnecessarily otherwise), but I'll apply Heiko's minimal patch in the meantime. Linus --

Cool with me; I'll try to puzzle out why removing -traditional breaks on those two specific files. Ugh, big cleanups likely. cheers, Kyle --

I don't think you should remove those. At some point the offset needs to be reset when the frequency scale changes for obvious reasons, and that needs to be fixed, not the code removed. Right now you'll get scheduling inconsistencies during frequency changes on !constant_tsc CPUs. (actually it is still the wrong time -- really needs a grace period during which the TSC is not used ftp://firstfloor.org/pub/ak/quilt/patches/sched-clock implemented some of these ideas against an older ...

recent CPUs have constant-freq TSCs so it's mostly a legacy issue, but the affected installed base is still significant to warrant a fix. we dont really have to worry about complications like grace periods - higher layers in the scheduler protect against temporary sched_clock() outliers. So i think this can all be done much simpler. Just get rid of the global cpu_khz notion, sched_clock() should simply follow the ->freq value - and that's it. Ingo --

Same issue. Think about it. Perhaps I should have written the complicated proof :) You really have to compute the offset before the scaling, otherwise it is useless. TSC is a counter that adds up time units. Now when the frequency changes the time units change, but counter doesn't reset. Now the full absolue value of the counter is useless for exact time because there is no way to reconstruct what the lengths of the different time units meshed together in the single counter value ...

hm, that's very close to the system i tried: Athlon64 X2 with Radeon X300SE (PCIe), 1GB RAM. (Asus A8N-E mobo) Ingo --

i got some hint. Will send you one patch to workaround the overlapping. YH --

can you put boot in your command line? Thanks YH --

please keep the three patches and applied the two attached debug patches. i wonder if there is some io allocation overlapping with your system. YH

http://marc.info/?l=linux-fsdevel&m=117581629326194&w=2 --

Yeah, that patch looks totally wrong. It's not generally a good idea to do a loop where the exit condition depends on something you don't control. And error values from filesystem methods are typically like that. For example with fuse, the error code could come from an unprivileged userspace process. I didn't realize this aspect of the bug previously, because I concentrated on the lockd inconsistency. Btw, why hasn't this work been posted on -fsdevel prior to merging EAGAIN for a ...

Hi Jacek The correct fix would be to drop the preprocessor directves and use __CPUINITDATA If your testing confirms this then please apply similar fix to the _32.S version of the file too. Nore that this looses the @progbits annotation but it should be OK to do so. I may later add it to init.h. Sam --

This race appears to have been fixed between 2.6.25rc5-mm1 and 2.6.25rc8-mm1. I've been running the later over night and have over 7 million iterations with out a crash. Ross --

The problem is that at such level you cannot easily retrieve info about where your serial port is connected to and which PPS source you should manage... Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti --

uart_ is only used by some drivers. We have a whole army of drivers using the tty layer directly and another army of drivers using the USB layer. You also need a sensible way to talk to the devices, identify support and avoid clashing uses of carrier pins. Alan --

At the moment you can't. That needs fixing. Most of the infrastructure is I do not want PPS code adding to every single serial driver. That way lies madness. We do it once, and in the right layer. I'll take a further look at it after the tty->ops patch is merged. At that point we'll be in a good position to add the needed ops/callbacks. Alan --

On Thu, 2008-04-10 at 17:46 +0200, Markus Armbruster wrote: How about adding a new console flag so that e.g. you could do: if (!strcmp(c->name, "tty") && c->index == 0 && !(c->flags & CON_SET_ON_CMDLINE)) --

I was looking at making sparse check that certain variable references are under rcu, but it's not as easy. Also, the lock context is just an arbitrary name, there's no way to actually link it to a certain variable or so to differentiate between them. I think that's not really solvable in sparse, look at the things lockdep has to do. johannes

I looked around a bit and talked to some people. It seems that a local variable declaration within a for{} block is OK. I still don't like it, but I won't object any longer. So, AFAICT you've only got that arch dependency problem left to solve. Thanks, Hans --

Hello Hans, See below. BTW, I found it, it's in linux/stringify.h. And there are several possible users: ukleinek@zentaur:~/gsrc/linux-2.6$ git ls-files -z | xargs -0 perl -n -e 'print "$ARGV\n" if ...

I've seen this kind of thing hacked up by a few people already, mainly as a replacement for /dev/mem. Many people are being scared off using /dev/mem (and rightly so) because - They've seen discussions regarding future plans whereby /dev/mem wouldn't be allowed access to physical memory - They don't have anything like X forcing them to have /dev/mem and therefore want to disable it completely for (perceived?) security reasons. I like it, it'll sure be used. --Ben. --

Already in the -mm tree... thanks, greg k-h --

Hi Greg, PATCH 4/4 still has a problem. It uses some clock framework functions not available on every architecture. E.g. on x86_64 you can select this driver in menuconfig, but it won't compile. The first three patches are OK in my opinion. Uwe provided a second version of PATCH 1/4, PATCH 2/4 and PATCH 3/4 were alright in their original version. I added my Signed-off-by to 1-3, but not to 4. Thanks, Hans --

Care to send the latest version of this, I'm a bit lost as to what people want me to apply... thanks, greg k-h --

Thanks, but it doesn't compile, neither with -rc8 nor with Linus' git. One problem can easily be fixed, the macro is called __stringify, not stringify. But what about this: ERROR: "clk_get" [drivers/uio/uio_pdrv.ko] undefined! ERROR: "clk_enable" [drivers/uio/uio_pdrv.ko] undefined! ERROR: "clk_disable" [drivers/uio/uio_pdrv.ko] undefined! ERROR: "clk_put" [drivers/uio/uio_pdrv.ko] undefined! Do you have any extra patches applied? Against which kernel do you test? Thanks, --

Hey, I just wanted to improve my Signed-off-by statistics :-) Damn it, one less... No, seriously, it looked somehow familiar but I didn't remember. Sorry. Thanks, Hans --

Hello, I just notice that, too. My mail address that and your's just crossed Yes I have, but nothing special. This is part of a generic API defined in include/linux/clk.h. One of it's use it to abstract away some platform dependencies. There are several architectures that define it[1]. I used it to allow enabling the device only when the device is opened. Typical things in the enable routine are enabling a clock or reserve and configure gpios etc. A minimal dummy implementation that ...

You like it so much you already acked this same change from someone else, which is in my tree at: thanks, greg k-h --

Further to this--I found that if I blacklist the 'video' driver then I can = boot up normally. --=20 Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078

The way this works is If I select memory resource controller, CONFIG_MM_OWNER is set to y, else it do_each_thread(), while_each_thread() walks all processes and threads of those processes in the system. It is a common pattern used in the kernel (see -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

maybe I don't undestand correctlly... On Thu, 10 Apr 2008 14:46:02 +0530 no default is ok here ? what value will this have if not selected ? Again, do_each_thread() is suitable here ? for_each_process() ? Thanks, -Kame --

Thanks for the review and help with testing. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL --

is there really no way to solve this more cleanly than a forced cast? It is a totally uninteresting warning that we pass in a narrower type to printk(). It cannot ever cause any bugs or problems. Why does gcc warn about it? Ingo --

I noticed in another thread, that you are using gcc 4.1.1. I think both 4.1.0 and 4.1.1 has some issues with weak symbols. Can you please try gcc 4.1.2 and see if that fixes your issue. When I go back to 4.1.0, I am bitten by smilar oops. But not with 4.1.2. thanks, suresh --

Please report this at bugzilla.redhat.com, or to Red Hat support. This kernel is very out of scope for this mailing list, unless you can reproduce the problem on newer kernels. -- Chris --

On Thu, 10 Apr 2008 15:20:19 +0100 How about this? This is generic VSA2 detection. It's used by OLPC to determine whether or not the BIOS contains VSA2, but since other BIOSes are coming out that don't use the VSA (ie, tinybios), it might end up being useful for others. Signed-off-by: Andres Salomon <dilinger@debian.org> --- include/asm-x86/geode.h | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/geode.h ...

thanks, applied. Ingo --

In theory although not in practice, since everyone vmallocs modules. Let's not rely on that tho. How about we sweep the immediate table on init discard and remove/mark all the init and exit references? Cheers, Rusty. --

Supports placing immediate values in init code We need to put the immediate values in RW data section so we can edit them before init section unload. This code puts NULL pointers in lieu of original pointer referencing init code before the init sections are freed, both in the core kernel and in modules. (experimental patch submitted for comments and testing) Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Rusty Russell <rusty@rustcorp.com.au> CC: "Frank Ch. Eigler" ...

It should not be locked (being on the inactive list does not imply that in any way). Being on the inactive list just means its first in line to Why would you want to do that for? Would you not rather have a copy of some page in memory than having to go back to disk to fetch it? Free memory is a waste, better have something in it that might potentially be See above, free memory is a waste. Really, you don't want 24GB of free If it really would have hit swap then it just means you have a ...

i've reverted the guilty patch and will push out a new x86.git soon. Ingo --

Thanks for the info, I can try that and see if I receive any kind of messages. regards; -- Justin P. Mattock --

From: Evgeniy Polyakov <johnpol@2ka.mipt.ru> ROFL --

The nice thing about binary search is that it's by definition an O(log2(N)) operation, which isn't bad at all as far as algorithms go. The truly blunt instrument here would be a linear search of every commit...

Thanks for the advice. I'll keep it in mind next time I have to decide whether to report a bug I'm stumbling over. T.

From: Mark Lord <lkml@rtr.ca> And if I invest my spare time on your bug how does this statement apply to me? Or does it only apply to you? Every single argument you make that supports why you should not be investing the necessary time into the bug applies equally to the very developers you are so quickly to quip at and want help from. --

From: Mark Lord <lkml@rtr.ca> Will do, thanks for testing. --

.. Duh.. more like, "If I take 5-8 hours to attempt a bisect (which may not even work), then that's 5-8 hours I do not get paid for." Gotta eat, dude. Anyways, here's five hours of free consulting for you: git-bisect start # bad: [7180c4c9e09888db0a188f729c96c6d7bd61fa83] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6 git-bisect bad 7180c4c9e09888db0a188f729c96c6d7bd61fa83 # good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux ...

You got it wrong. If bug is subtle and developers can not reproduce it, there are only two ways out of the problem: to help developers or not to help. In the latter case bug report is useless (except that to show that it exists, since practically no one can fix it until some new details added). In the former case there is a discussion between developers and reporters, so things have progress. In this particular case there were no healthy discussion, that is why all this is ...

From: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Every time I see someone play the "I care about Linux" card, they are typically being a hypocrit. It's a knee jerk, defensive gesture, and Thanks for your support Evgeniy, it is truly appreciated. We had Mark's bug fixed in 15 minutes once the bisect result was known, even after Ilpo and myself had scanned through the changesets. This proves the utility of bisect and in fact that trying to intuit the cause by continuing to study changesets and ...

.. My system here is now set up for quick/easy retest, if you have any suggestions or patches to try out. Thanks guys. --

.. That's not demanding, that's quite relaxed. I had a good workaround, and didn't really care any more at that point. Just though it was rather odd that none of the developers seemed interested in tracking it down. I offered tons of help, gave it, and said I didn't have time for a full bisect at that juncture. For that, I get repeatedly slammed by the netdev folks. Even after I put aside *paid* work to submit to your demands. Next time around, I won't bother reporting bugs to you ...

Too late, but still Acked-by: Pavel Emelyanov <xemul@openvz.org> Sorry, guys, but my timezone does not allow me to react in time to found bugs :( So, when I wake up in the morning I usually just find out that someone has caught a BUG made by me and someone --

Actually that will be the best decision from evolutional point of view. Bugs, which 'are thrown back to your face' like what you did with this one, are useless. Developers already know, that bugs exist. If you do not care about bug, why do you ever bothered filling it? You expected that anyone will start running to fix it for you. You were wrong. Developers only fix bugs, which do not require mind-reading and magnetic quantification of your brain. If you do not want to help fixing it, ...

No problemo :) -- Evgeniy Polyakov --

Looks like you're saying I was right after all. Useless bug reports shouldn't be submitted. So please answer this simple question: If I know beforehand that I won't have the time to do a bisect (or other similarly time-consuming task the maintainers might ask from me), should I report the bug, or should I keep my knowledge to myself? This question is not theoretical. It's a situation I find myself in quite regularly, because I allow myself the luxury of building most rc kernels and even ...

well, your 2.6.26 plans, if i understand them correctly, is to move currently working PCI IDs from e1000 to e1000e, like you attempted to d it in v2.6.24, which Linus reverted - correct? I.e. e1000 simply wont support eth0 on my T60 from 2.6.26 on? That is still an incredibly stupid plan, and no amount of announcement on lkml will make it any less stupid. ... which pretty much pulls the rug from under your argument, no? Ingo --

Maybe you could rename both configuration switches, so that you bring it to the attention of everybody who does make oldconfig? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);} --

Ok, I'm not even interested in discussing this. Have you followed the discussion at all? Did you even notice _why_ we're discussing it? Here's a damn big hint: teh thing you say "Presumably they'd think" is exactly what we're talking about, AND HELL NO THEY DIDN'T! That goes for both me and Ingo. So stop blathering. The _fact_ is that two kernel developers were really upset about the fact that their machines stopped working with old configurations. Stop the inane ".. but that ...

You mean never ever remove PCI-E support from e1000? Won't that will inflict long term headaches on the people that matter most -- users and maintainers -- to avoid short term headaches for kernel power users? To review the overall situation, * e1000 supports so many chips, that making a change for new hardware in e1000 involves breaking stability of older chips * //You know this// from past kernel history, when late-breaking e1000 changes for new hardware wound up breaking ...

As a start we could do two driver keyed off a single Kconfig variable. And then find a way to get users informed that they might need to enabled the other one --

I don't think this will happen like that. People will simply think as usual "ah, they have added support for new hardware, but since everything in my machine was supported, I don't need it". I think that the correct solution to help people is not at build time, but at run time. The e1000 driver should just *check* if there are PCI-IDs that it used to manage and that it does not anymore, for unclaimed devices, and report a warning message clearly indicating that these devices are not handled ...

that's an insane argument ... because we messed up in the past and have hurt users (and probably lost users) you feel like it gives you a free card to mess up again??? The IDE -> SATA migration, while i like the new SATA code and find it excellent and well-maintained (many kudos for that to Tejun, Jeff, Alan & co), caused a lot of trouble for users in one specific area, for no good reasons other than stupid personality conflicts: /dev/hda worked just as well as /dev/sda, the _name_ of ...

Okay, so with my change E1000 will incidentally give you ich9 support. But it doesn't fail to "support PCI and a few PCI-E", it just does some more that it has to give you for coverage of the traditional things. -Daniel *This .sig left intentionally blank* --

I think that's a great solution. Here's a suggested patch. Not much tested, but it's fairly obvious. It basically makes one top-level config option (E1000) to pick the driver at all, and two sub-options (E1000_PCI and E1000_PCIE) that you can choose between. If you pick E1000 support, you're given the choice between "PCI only", "PCI-E only" or "support both", and that will then pick the right combination of support for E1000_PCI and E1000_PCIE. This also does imply that you ...

Yes, that sounds fine too. Although you need to add a depends on PCI to the E1000 thing (because the "select" would not honor the dependencies that E1000E and E1000_PCI have). I agree we could, but as I tried to explain, I fundamentally don't think we _should_. Why should people _ever_ be asked about whether they want "E1000 PCI support" vs "E1000 PCI-E" support, when it's almost impossible to tell which kind of card you have? In other words, I suspect that anybody who ...

firstly, a good deal of our alpha testers use =y drivers. Secondly, your kind of constructive email is exactly what i wanted to see in the first place... i dont really care _how_ this gets solved - i'm not maintaining this code. What forced me to deal with it was this outright denial of my problem, the ridiculing and NACK-ing of it and general stonewalling. I'd have preferred to have sent only my first report. The networking driver guys on the other hand: 1) forced me to send a ...

Wouldn't it make more sense to turn E1000 into a option that does nothing except select both E1000E and E1000_PCI, and have those two be the options that build drivers? Then, after a while, we drop the E1000 option entirely, and people are fine as long as they used any of the kernels in between (since the system will have forgotten that E1000E was only set by an option that has disappeared). Right now, E1000 means "support both PCI and PCI-E E1000" and E1000E means "support PCI-E ...

In my experience with FUSION=y and AIC78xx=y most of the relatively modern (2000+) pre SAS SCSI systems are covered, at least near all those without special RAID controllers. That is why I kept both of those enabled in the defconfigs originally. Might actually make sense to update this for SAS, but I don't have a good feeling what chipsets are really popular here. -Andi --

The difference is that : 1) either could be used for a long time 2) the old worked so bad that the word has spread among people in forums to try the new driver instead. I think that splitting drivers should be something accepted in the kernel's lifetime, but users must not be left confused. It's clearly easier to insert ourselves in their common process to wave hands indicating that their setup will soon not work anymore (eg: by having e1000 indicate what driver must be loaded for ...

We only support people keeping their old configs after they run 'make oldconfig', right? At which point they'd be prompted for E1000_SUPPORT. Presumably they'd think "That's odd. I'm sure I had that selected before", then select it. Then oldconfig skips over CONFIG_E1000 because it already knows the answer to that one and they're prompted with a question about PCIe support. Now something is clearly strange. Perhaps they look at the help text at this point and it says to go with 'Y' or 'M' ...

We could start by annotating those as well, for example: __rcu spinlock_t tree_lock; Then we would know that when tree lock is held the data structure is stable and we can ommit the rcu_*() functions. --

Good point! Though IIRC there are are cases where we are updating one RCU-protected data structure while in an RCU read-side critical section with respect to another RCU-protected data structure. But it would probably best to start as you say rather than trying to classify different RCU uses. :-) Thanx, Paul --

thanks Pavel, i picked this up into sched-devel.git - it makes sense independently of whether it solves the warning. Ingo --

Please unapply them, as discussed in the earlier thread they are not the correct fix. The original bug is still not found unfortunately, but it's most likely somewhere in the KVM suspend/resume code. -Andi --

thanks Jiri, i've applied both patches of yours. (let me know if there are any updated patches) do they solve the problem? Ingo --

Well, we can discuss it personally. Yes, it is probably bug that interrupts are enabled there. No, the bug can't potentially bite the user because there should be just one CPU "plugged in"... so it is kind of false-positive, too.. Does the warning go away with this? Pavel diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c index 6c90fb9..8195c37 100644 --- a/lib/smp_processor_id.c +++ b/lib/smp_processor_id.c @@ -35,6 +35,13 @@ unsigned int ...

Thanks! (I just want to fix the underlying problem in suspend, too. I guess I'll just do something like diff --git a/drivers/base/sys.c b/drivers/base/sys.c index 8e13fd9..adb7850 100644 --- a/drivers/base/sys.c +++ b/drivers/base/sys.c @@ -367,6 +367,7 @@ int sysdev_suspend(pm_message_t state) /* Call auxillary drivers first */ list_for_each_entry(drv, &cls->drivers, entry) { if (drv->suspend) { + BUG_ON(!in_interrupt()); ret = drv->suspend(sysdev, state); ...

small note: please always use WARN_ON_ONCE() in such cases. That way people's boxes dont blow up and the problem will be debuggable if the box survives despite the error condition. (and thus it can be relayed to kerneloops.org - all major distros have the package included already and Fedora enables the client by default) Ingo --

Ok. I've just pushed out a testing version of checkpatch which is identicle the 0.18 delta I just pushed to Andrew with the printk width restriction lifted. Perhaps those interested might test it to see if it whines appropriatly: http://www.kernel.org/pub/linux/kernel/people/apw/checkpatch/checkpatch.pl-testing I am going to be off next week, but will likely be dipping into email now and again. -apw --

http://bugzilla.kernel.org/show_bug.cgi?id=10319 Soeren --

Do you think the problem may be with the xserver? Did you upgrade to 7.3? Over here I did the upgrade to 7.3, but with testing with vesa there seems to be no module with the xserver for vesa or at least I haven't located it yet. On a positive note suspend does work with the ati driver installer, the negative side is it doesn't work without it. So from my perspective over here, Does xserver(7.3) have vesa support? regards; -- Justin P. Mattock --

Hmm, you could bisect the resume regression, revert that, and then go on to find the suspend regression. ...ok, not easy, I see. Do you have kernel.org bugzilla # I could look at? Perhaps this can be debugged using printks or something... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

I've got more information again. This is dmesg, and /proc/interrupts from a livecd (systemrescuecd), its a .23.14, and only 1 nic works (the one that doesent work on .25 noapic/msi), the other gets detected as fiber.. strangely enough, the link detection works on the working nic, on .23.14. attached are /proc/interrupts and dmesg.. oh, and this is a 64bit livecd kernel, but it appears to act the same on the 32bit kernel on the livecd.. This, and the previous information i have given, does ...

Sorry for slow response. If write access is denied because of a rule "No modifications to /etc/passwd", a rule "Allow modifications to /tmp/passwd" can no longer be enforced after "mount --bind /etc/ /tmp/" or "mount --bind /etc/passwd /tmp/passwd" or "mv /etc/passwd /tmp/passwd" or "ln /etc/passwd /tmp/passwd" is done. "No modifications" (i.e. "forbid modifications") and "Allow modifications" (i.e. "don't forbid modifications") are incompatible rules as long as the rules are described ...

That's a fundamental limitation of pathname-based security though. If the same file exists in two places, you have to resolve the question of which rule overrides the other. In my role as a sysadmin, I would consider it a flaw if someone could edit a file I'd marked uneditable -- simply by creating a hard-link to it. If we look at existing systems, such as the immutable bit, those apply to inodes, not to paths, so they can't be evaded. If a system such as TOMOYA allows evasion this easily, ...

Please also test the kernel with the patch from http://bugzilla.kernel.org/attachment.cgi?id=15736&action=view applied. Thanks, Rafael --

> This crashes my powerpc mac g5. I had only tested with Linus's tree plus the small handful of post-2.6.25 cleanup patches I've posted in the last few weeks. To be precise it was 9597362d354f8655ece324b01d0c640a0e99c077 plus several of my cleanup patches (that are probably all in -mm, but I'm not sure off hand). I'd rebased my tree today to 783e391b7b5b273cd20856d8f6f4878da8ec31b3 anyway. I just tried the new kernel with the sigmask cleanups and only a few other patches, and have no ...

Okay, freezer probably does what you want, but be warned that Linus is not exactly in love with freezer. You probably can get away with using it for user processes, but maybe you should drop him the line saying you want to expand freezer usage and see what happens. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

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

hm. It'd be nice to know how git-x86 managed to make this happen. I haven't looked, apart from noting that it doesn't seem to touch any of the relevant files. --

Indeed. Will change the definition. Long-term I'd like to generalize the btree a bit and allow three key variants: long, u64 and u8[]. Some people want to stuff a (u64, u64, u8) tupel into a btree. For those it seems ideal to just treat the key as an array and do memcmp() for comparison. Jörn -- You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the ...

From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi> Linus has pulled those changes in. --

You're not likely to see demand for it from users. I believe glibc will emulate it as best it can (which is not very well), and things will appear to work.... most of the time. -- dwmw2 --

This thread fizzled out without a patch... here goes: [ note: I'm replying via gmail, so if it has whitespace mangled the patch please see the attachment ] -----snip----> sysfs: add /sys/dev/{char,block} to lookup sysfs path by major:minor From: Dan Williams <dan.j.williams@intel.com> Why?: There are occasions where userspace would like to access sysfs attributes for a device but it may not know how sysfs has named the device or the path. For example what is the sysfs path ...

Hi, Linus just made 2.6.25-rclast (I hope), I understand 2.6.25 will have broken drivers/net/wan/hdlc_ppp, any chance to apply the temporary Kconfig ("depends on BROKEN") patch? Would you like me to resend it? TIA. -- Krzysztof Halasa --

Any progress? -- tejun --

Aiee.... Can you please try 2.6.25-rc8 with both configurations? And w/o systemrescuecd? Just seeing whether things mount properly or not is good enough. There isn't much risk of losing data. -- tejun --

Hello. I'm still not seeing the code to deals with the PCI device ID 4 which may be HPT36x, or HPT370, or HPT372[N] depending on revision -- you're always Wrong -- HPT374 should have hpt37x_dma_ops... MBR, Sergei --

I'm curious: what scenarios require sub-millisecond timeouts? -- Michael Kerrisk Maintainer of the Linux man-pages project http://www.kernel.org/doc/man-pages/ Want to report a man-pages bug? Look here: http://www.kernel.org/doc/man-pages/reporting_bugs.html --

The us scale seemed the best fit in that it allows sub-ms granularity while still allowing for quite long periods too. I'd preferred ns scale as that is what we use throughout the scheduler where possible - but that seemed too restrictive at the high end. No real hard arguments either way. --

Just to make sure me and the man page are clear: by tick-based, you Okay. And following on from my other conversation in this thread... What should/will be the specified behavior w.r.t. resetting or not resetting the timer on a sched_yield()? Cheers, Michael -- Michael Kerrisk Maintainer of the Linux man-pages project http://www.kernel.org/doc/man-pages/ Want to report a man-pages bug? Look here: http://www.kernel.org/doc/man-pages/reporting_bugs.html --

It appears you are right. I must have been staring at something else than code when I said that :-(, yield() will indeed _not_ reset the counter. Now, I think it makes some sense to reset it, because we do try to play nice by calling yield. OTOH we don't actually block and become unrunnable - we'll still be contending for CPU time. --

Okay -- thanks. I will make that clear in the man page. Cheers, Michael -- Michael Kerrisk Maintainer of the Linux man-pages project http://www.kernel.org/doc/man-pages/ Want to report a man-pages bug? Look here: http://www.kernel.org/doc/man-pages/reporting_bugs.html --

On Thu, Apr 3, 2008 at 5:44 AM, James Courtier-Dutton Yea. I see Thomas' patch was applied then reverted as it caused problems with the TSC reseting over suspend and resume (since the timekeeping core doesn't have a hook into the tsc clocksource to inform it that the comparision is invalid, so the resume-time read will always return the cycle_last value and not the actual smaller TSC value). This suggested bounding of how much a negative value is considered valid would resolve this issue, ...