Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)
On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote: > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote: > > As a crude data point of idle system running a full kde desktop > > environment on > > powersave with minimal backlight and just chatting on IRC I find it's > > just > > under 10% battery life difference. > > Have you tried the same test but without artsd, or with it configured to > release the sound device after some reasonable time, like 1-2s? I have it on release after 1 second already. Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 support for gcc < 3.2
On Sun, Jul 31, 2005 at 11:01:45PM -0400, Kurt Wall wrote: > On Mon, Aug 01, 2005 at 12:26:07AM +0200, Adrian Bunk took 109 lines to write: > > This patch removes support for gcc < 3.2 . > > > > The advantages are: > > - reducing the number of supported gcc versions from 8 to 4 [1] > > allows the removal of several #ifdef's and workarounds > > - my impression is that the older compilers are only rarely > > used, so miscompilations of a driver with an old gcc might > > not be detected for a longer amount of time > > > > My personal opinion about the time and space a compilation requires is > > that this is no longer that much of a problem for modern hardware, and > > in the worst case you can compile the kernels for older machines on more > > recent machines. > > Environments that require kernel compilation, often multiple times, > testing, benefit from shorter compile times. It can be the difference > between, say, completing a test suite overnight instead of having to > wait until tomorrow afternoon. Keeping 2.95, at least, has some value > in such environments. I *do* still use 2.95 a lot, and I'm not alone, judging from people around me. 2.95 has been the reference for a very long time, that's why it's still so much present. 3.0 and 3.1 (even 3.2) have been there for a very short time frame, but 2.95 and 3.3 really seem to be references compilers. So please keep support for 2.95. Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] i386 dynamic ticks 2.6.13-rc4 (code reordered)
On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote: > As a crude data point of idle system running a full kde desktop > environment on > powersave with minimal backlight and just chatting on IRC I find it's > just > under 10% battery life difference. Have you tried the same test but without artsd, or with it configured to release the sound device after some reasonable time, like 1-2s? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] i386 dynamic ticks 2.6.13-rc4 (code reordered)
On Tue, 2 Aug 2005 02:43 pm, Con Kolivas wrote: > This has slightly more build fixes than the last one I posted and boots and > runs fine on my laptop. So far at absolute idle it appears this pentiumM > 1.7 is claiming to have _25%_ more battery life. I'll need to investigate > further to see the real power savings. As a crude data point of idle system running a full kde desktop environment on powersave with minimal backlight and just chatting on IRC I find it's just under 10% battery life difference. I have confirmed in the past the accuracy of the remaining capacity exported by the battery and the time to complete discharge. This saving is similar in magnitude to the 1000->100Hz savings of 7% mentioned on other threads. While nothing like the 25% initially suggested it is still significant. Anyone with a more accurate means of testing this interested? Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: busy usenet server: only stable kernel is 2.6.12-mm1, rest (including 2.6.13-rc4*) barfs within a few days
On Sun, Jul 31, 2005 at 09:47:18AM +, Danny ter Haar wrote: > A tyan AMD64 opteron machine functioning as a usenet gateway really > pumps some traffic a day (http://newsgate.newsserver.nl) > Incoming traffic comes through a optical gig-E card (acenic) > and local traffic is fed to our spool boxes through cupper gig-E > (tigon3). Machine uses adaptec onboard scsi disks. > At first i thought i had a hardware problem since no kernel would > survive longer than 30 hours. Ofcourse i ran memtest for a couple > of days. Than i compiled 2.6.12-mm1 and this kernel surviced 18 days > without a problem. But of course you now and then want to try > bigger(tm) kernels ;-) I've filed a bug at kernel bugzilla, so your report won't be lost. See http://bugzilla.kernel.org/show_bug.cgi?id=4982 Please, register at http://bugme.osdl.org/createaccount.cgi and add yourself to CC list. P. S.: Andrew Morton already asked for Oops output. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)
Con Kolivas wrote: > My desktop pentium4 did not like the patch erroring with "bad gzip magic > number" on boot for reasons that aren't obvious to me. This could be related > to trying gcc 4.0.1 on that box whereas the laptop is on gcc 3.4.4 and is > working fine. > Just writing to report that on my laptop with a pentium 4 m that it boots just fine. No idea what the change in power use is at the moment. Compiled using gcc 3.3.5. -- Michael Marineau [EMAIL PROTECTED] Oregon State University signature.asc Description: OpenPGP digital signature
Re: [PATCH] String conversions for memory policy
Christoph wrote:
> New version without the magic numbers ...
Good.
===
How about replacing:
static const char *policy_types[] = { "default", "prefer", "bind",
"interleave" };
with:
static const char *policy_types[] = {
[MPOL_DEFAULT]= "default",
[MPOL_PREFERRED] = "prefer",
[MPOL_BIND] = "bind",
[MPOL_INTERLEAVE] = "interleave"
};
so that the mapping of the MPOL_* define constants to strings is
explicit, not implicit.
===
Maybe I need more caffeine, but the following tests seem backwards:
+ if (buffer + maxlen > p + l + 1)
+ return -ENOSPC;
and
+ if (buffer + maxlen > p + 2)
+ return -ENOSPC;
===
Can the following:
+ int l;
+ ...
+
+ l = strlen(policy_types[mode]);
+ if (buffer + maxlen > p + l + 1)
+ return -ENOSPC;
+ strcpy(p, policy_types[mode]);
+ p += l;
+
+ if (!nodes_empty(nodes)) {
+
+ if (buffer + maxlen > p + 2)
+ return -ENOSPC;
+
+ *p++ = '=';
+ p += nodelist_scnprintf(p, buffer + maxlen - p, nodes);
+ }
be rewritten to:
char *bufend = buffer + maxlen;
...
p += scnprintf(p, bufend - p, "%s", policy_types[mode]);
if (!nodes_empty(nodes)) {
p += scnprintf(p, bufend - p, "=");
p += nodelist_scnprintf(p, bufend - p, nodes);
}
if (p >= bufend - 1)
return -ENOSPC;
Less code, more consistent code for each buffer addition, fails with
ENOSPC in the case that the nodelist only partially fits rather than
truncating it without notice, and fixes any possible problem with the
above tests being backwards - by removing the tests ;).
This suggested replacement code does have one weakness, in that it
cannot distinguish the case that the buffer was exactly the right
size from the case it was too small, and errors with -ENOSPC in
either case. I don't think that this case is worth adding extra
logic to distinguish, in this situation.
===
+ for(mode = 0; mode <= MPOL_MAX; mode++) {
Space after 'for'
===
There should probably be comments that these routines must
execute in the context of the task whose mempolicies are
being displayed or modified.
==
There should probably be a doc style comment introducing
the mpol_to_str() and str_to_mpol() routines, as described
in Documentation/kernel-doc-nano-HOWTO.txt.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [ACPI] S3 and sigwait (was Re: 2.6.13-rc3: swsusp works (TP 600X))
On Mon, 2005-08-01 at 09:09 +0200, Pavel Machek wrote:
> Hi!
>
> > > If you think it is a linux bug, can you produce small test case doing
> > > just the sigwait, and post it on l-k with big title "sigwait() breaks
> > > when straced, and on suspend"?
> > >
> > > That way it is going to get some attetion, and you'll get either
> > > documentation or kernel fixed.
> > Looks like a linux bug to me. The refrigerator fake signal waked the
> > task up and without restart for the sigwait case. How about below
> > patch:
>
> Is there chance to fix strace case, too? sigwait() is broken in more
> than one way it seems...
This patch should fix two cases. Can anybody familiar with signal
handling look at it?
The posix standard said for sigtimedwait:
"If no signal in set is pending at the time of the call, the calling
thread shall be suspended until one or more signals in set become
pending or until it is interrupted by an unblocked, caught signal."
Systemcall might be restarted if it's not interrupted by a caught
signal.
Thanks,
Shaohua
---
linux-2.6.13-rc4-root/kernel/signal.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -puN kernel/signal.c~sigwait-suspend-resume kernel/signal.c
--- linux-2.6.13-rc4/kernel/signal.c~sigwait-suspend-resume 2005-08-02
10:33:16.798179984 +0800
+++ linux-2.6.13-rc4-root/kernel/signal.c 2005-08-02 12:49:06.688208376
+0800
@@ -2231,7 +2231,8 @@ sys_rt_sigtimedwait(const sigset_t __use
current->state = TASK_INTERRUPTIBLE;
timeout = schedule_timeout(timeout);
- try_to_freeze();
+ if (freezing(current))
+ return -ERESTARTNOINTR;
spin_lock_irq(>sighand->siglock);
sig = dequeue_signal(current, , );
current->blocked = current->real_blocked;
@@ -2250,7 +2251,7 @@ sys_rt_sigtimedwait(const sigset_t __use
} else {
ret = -EAGAIN;
if (timeout)
- ret = -EINTR;
+ ret = -ERESTARTNOHAND;
}
return ret;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.13-rc5
Ok, one more in the series towards final 2.6.13. This one is small enough that both shortlog and diffstat fit comfortably: no big architecture updates or anything like that. Some input, x86-64 and ppc updates, and various fairly small fixes in random places. Some reverts back to 2.6.12 behaviour - you've seen the discussions, and I'm sure we'll end up discussing things further for a long while still, but the plan is to release 2.6.13 with known behaviour characteristics. Give it a good testing, I'm hoping this can really turn into 2.6.13. Linus --- Adam Kropelin: Input: HID - only report events coming from interrupts to hiddev Adrian Bunk: include/linux/dcookies.h: dummy functions must be "static inline" SCSI_SATA has to be a tristate USB: drivers/usb/net/: remove two unused multicast_filter_limit variables DEBUG_FS must depend on SYSFS Alan Stern: USB: Usbcore: Don't try to delete unregistered interfaces USB: usbfs: Don't leak uninitialized data Alasdair G Kergon: device-mapper: fix md->lock deadlocks in core device-mapper: fix deadlocks in core device-mapper: fix deadlocks in core (prep) Alexander Nyberg: x86_64: cpu hotplug changes kills nmi watchdog Alexey Kuznetsov: [NET]: fix oops after tunnel module unload Andi Kleen: x86_64: Remove unused variable in k8-bus.c x86_64: Fix SRAT handling on non dual core systems x86_64: Switch to the interrupt stack when running a softirq in local_bh_enable() x86_64: Small assembly improvements x86_64: Remove unnecessary include in fault.c x86_64: When running cpuid4 need to run on the correct CPU x86_64: Turn BUG data into valid instruction x86_64: Support more than 8 cores on AMD systems x86_64: Remove the broadcast options that were added for cpuhotplug x86_64: Remove IA32_* build tools in Makefile x86_64: Create per CPU machine check sysfs directories x86_64: Print a boot message for hotplug memory zones x86_64: Fix incorrectly defined MSR_K8_SYSCFG x86_64: Fix some typos in system.h comments x86_64: Remove obsolete eat_key prototype x86_64: Fix some comments in tlbflush.h x86_64: Some updates for boot-options.txt x86_64: Improve CONFIG_GART_IOMMU description and make it default y x86_64: Remove unused variable in delay.c x86_64: Some cleanup in setup64.c x86_64: Clarify Booting processor ... message x86_64: Minor clean up to CPU setup - use smp_processor_id instead of custom hack x86_64: Move cpu_present/possible_map parsing earlier x86_64: i386/x86_64: remove prototypes for not existing functions in smp.h x86_64: Use for_each_cpu_mask for clustered IPI flush x86_64: Update defconfig x86_64: Always ack IPIs even on errors Andreas Gruenbacher: x86_64: Icecream has no way of detecting assembler-level includes Andrew Morton: shm: CONFIG_SHMEM=n build fix transmeta: CONFIG_PROC_FS=n build fix skge build fix i2c-mpc.c: revert duplicate patch revert bogus softirq changes Input: cannot refer to __exit from within __init. Anton Blanchard: ppc64: topology API fix Antonino A. Daplas: tridentfb: Fix scrolling artifacts during disk IO tridentfb: Fix scrolling artifacts if acceleration is enabled vesafb: Document mtrr boot option usage fbdev: Replace memcpy with for-loop when preparing bitmap vesafb: Fix mtrr bugs Baruch Even: [NET]: Spelling mistakes threshoulds -> thresholds Ben Dooks: USB: add S3C24XX USB Host driver support Benjamin Herrenschmidt: ppc64: Fix CONFIG_ALTIVEC not set Bjorn Helgaas: serial: add MMIO support to 8250_pnp Bodo Stroesser: uml: Fix typo uml: Fix skas0 stub return Christophe Lucas: uml: Clean up prink calls Conger, Chris A: USB: fix Bug in usb-skeleton.c Cornelia Huck: s390: device recognition Dan Streetman: USB: fix in usb_calc_bus_time Daniel Walker: stable_api_nonsense.txt fixes Daniele Gaffuri: PCI: Hidden SMBus bridge on Toshiba Tecra M2 Dave Hansen: re-disable TSC on NUMAQ Dave Jones: arch/i386/kernel/cpu/cpufreq/powernow-k8.c: In function `powernow_k8_cpu_init_acpi': Fix up powernow-k8 compile. (Missing definitions). powernow-k8.c: In function `query_current_values_with_pending_wait': Here are two possible cleanups in cpufreq.c: Opteron revision F will support higher frequencies than powernow-k8 requires that a data structure for Dave Peterson: x86_64: fix bug in csum_partial_copy_generic() David Moore: Input: ALPS - fix resume (for DualPoints) David S. Miller: [NET]: Fix busy waiting in dev_close(). David Shaohua Li: [ACPI] suspend/resume ACPI PCI Interrupt Links [ACPI] address boot-freeze with updated DMI blacklist for c-states Denis Lunev: [NET] Fix too aggressive backoff in dst garbage collection Denis Vlasenko: silence cs89x0 Dmitry Torokhov: Input: i8042 - don't use negation to mark AUX data Input: i8042 - add Alienware Sentia to NOMUX blacklist. Input: serio_raw - link serio_raw misc device to corresponding Merge
Re: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Tue, 2005-08-02 at 02:13 +0200, Thorsten Knabe wrote:
> Using OSS emulation with one of the
> VoIP phones
Are you referring to the in-kernel OSS emulation, or the alsa-lib
emulation ("aoss ./app")?
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Fw: ati-remote strangeness from 2.6.12 onwards
I discovered a minor change in 2.6.10-mm1, changing this value back
corrects the "ok" button issue.
diff -urN linux/drivers/usb/input/ati_remote.c
linux-2.6.11/drivers/usb/input/ati_remote.c
--- linux/drivers/usb/input/ati_remote.c2005-08-02
17:56:26.0 +1200
+++ linux-2.6.11/drivers/usb/input/ati_remote.c 2005-08-02
17:54:34.0 +1200
@@ -263,7 +263,7 @@
{KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */
{KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */
{KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */
- {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */
+ {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */
{KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */
{KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */
{KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */
On 7/31/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>
> Begin forwarded message:
>
> Date: Sun, 31 Jul 2005 12:18:23 +1200
> From: mdew <[EMAIL PROTECTED]>
> To: linux-kernel
> Subject: ati-remote strangeness from 2.6.12 onwards
>
>
> using 2.6.11 everything works fine, Upgrading too 2.6.13-rc3 I noticed 2
> errors,
>
> (1) When setting the HZ rating too 250 or 100 will cause the driver to
> excessfully repeat keys/accelerate when pressing a button, making it
> unusable :(
>
> (2) the "Ok" button no longer works in anything after and including
> 2.6.12-rc1 (I've tested upto 2.6.13-rc3), 2.6.11 works fine. xbindkeys
> doesnt register any "ok" key presses on 2.6.12-rc1 onwards.
>
> 2.6.11 xbindkeys responses (nothing shows up in -rc1)
>
> mediabawx2:~# xbindkeys -mk
> Press combination of keys or/and click under the window.
> You can use one of the two lines after "NoCommand"
> in $HOME/.xbindkeysrc to bind a key.
>
> --- Press "q" to stop. ---
> "NoCommand"
> m:0x0 + c:36
> Return
> "NoCommand"
> m:0x0 + c:36
> Return
>
>
> 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/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Power consumption HZ100, HZ250, HZ1000: new numbers
Theodore Ts'o wrote: > On Mon, Aug 01, 2005 at 12:18:18PM -0400, James Bruce wrote: >>The tradeoff is a realistic 4.4% power savings vs a 300% increase in >>the minimum sleep period. A user will see zero power savings if they >>have a USB mouse (probably 99% of desktops). On top of that, we can > Most laptops (including mine, a Thinkpad T40) use a PS/2 mouse. So in > the places where power consumption savins matters most, it's usually > quite possible to function without needing any USB devices. The 90% > figure isn't at all right; in fact, it may be that over 90% of the > laptops still use PS/2 mice and keyboards. Yes, laptops are mostly PS/2, which is why I only claimed a statistic for desktops. Desktops pretty much all use USB mice now. If 250Hz were only being sold as an option for laptops, we could leave it at that, yet its being pushed as a default that's "good for everyone". For desktops this is not currently true at all. By the time USB is fixed to do power saving, we'll probably have a working tick-skipping patch which makes the whole HZ argument moot. - Jim Bruce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] i386 dynamic ticks 2.6.13-rc4 (code reordered)
This is a code reordered version of the dynamic ticks patch from Tony Lindgen
and Tuukka Tikkanen - sorry about spamming your mail boxes with this, but
thanks for the code. There is significant renewed interest by the lkml
audience for such a feature which is why I'm butchering your code (sorry
again if you don't like me doing this). The only real difference between your
code and this patch is moving the #ifdef'd code out of code paths and putting
it into dyn-tick specific files.
This has slightly more build fixes than the last one I posted and boots and
runs fine on my laptop. So far at absolute idle it appears this pentiumM 1.7
is claiming to have _25%_ more battery life. I'll need to investigate further
to see the real power savings.
My desktop pentium4 did not like the patch erroring with "bad gzip magic
number" on boot for reasons that aren't obvious to me. This could be related
to trying gcc 4.0.1 on that box whereas the laptop is on gcc 3.4.4 and is
working fine.
Cheers,
Con
Index: linux-2.6.13-rc4-ck1/arch/i386/Kconfig
===
--- linux-2.6.13-rc4-ck1.orig/arch/i386/Kconfig 2005-08-02 13:40:01.0 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/Kconfig 2005-08-02 13:40:51.0 +1000
@@ -457,6 +457,38 @@ config HPET_EMULATE_RTC
bool "Provide RTC interrupt"
depends on HPET_TIMER && RTC=y
+config NO_IDLE_HZ
+ bool "Dynamic Tick Timer - Skip timer ticks during idle"
+ help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
+ Note that you need to enable dynamic tick timer either by
+ passing dyntick=enable command line option, or via sysfs:
+
+ # echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
+
+config DYN_TICK_USE_APIC
+ bool "Use APIC timer instead of PIT timer"
+ depends on NO_IDLE_HZ
+ help
+ This option enables using APIC timer interrupt if your hardware
+ supports it. APIC timer allows longer sleep periods compared
+ to PIT timer.
+
+ Note that on most recent hardware disabling PIT timer also
+ disables APIC timer interrupts, and system won't run properly.
+ Symptoms include slow system boot, and time running slow.
+
+ If unsure, don't enable this option.
+
+ Note that to you still need to pass dyntick=enable,forceapic
+ command line option to use APIC timer.
+
config SMP
bool "Symmetric multi-processing support"
---help---
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/Makefile
===
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/Makefile 2005-08-02 13:38:53.0 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/Makefile 2005-08-02 13:40:51.0 +1000
@@ -32,6 +32,7 @@ obj-$(CONFIG_MODULES) += module.o
obj-y+= sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT) += srat.o
obj-$(CONFIG_HPET_TIMER) += time_hpet.o
+obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/apic.c
===
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/apic.c 2005-08-02 13:38:53.0 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/apic.c 2005-08-02 13:40:51.0 +1000
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -931,6 +932,8 @@ void (*wait_timer_tick)(void) __devinitd
#define APIC_DIVISOR 16
+u32 apic_timer_val;
+
static void __setup_APIC_LVTT(unsigned int clocks)
{
unsigned int lvtt_value, tmp_value, ver;
@@ -949,7 +952,12 @@ static void __setup_APIC_LVTT(unsigned i
& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
| APIC_TDR_DIV_16);
- apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+ apic_timer_val = clocks/APIC_DIVISOR;
+
+ if (apic_timer_val)
+ set_dyn_tick_max_skip(apic_timer_val);
+
+ apic_write_around(APIC_TMICT, apic_timer_val);
}
static void __devinit setup_APIC_timer(unsigned int clocks)
@@ -1062,6 +1070,8 @@ void __init setup_boot_APIC_clock(void)
*/
setup_APIC_timer(calibration_result);
+ setup_dyn_tick_use_apic(calibration_result);
+
local_irq_enable();
}
@@ -1200,6 +1210,13 @@ fastcall void smp_apic_timer_interrupt(s
* interrupt lock, which is the WrongThing (tm) to do.
*/
irq_enter();
+
+ /*
+ * Check if we need to wake up PIT interrupt handler.
+ * Otherwise just wake up local APIC timer.
+ */
+ wakeup_pit_or_apic(cpu, regs);
+
smp_local_timer_interrupt(regs);
irq_exit();
}
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/dyn-tick.c
===
---
Re: [patch 2.6.13-rc4] fix get_user_pages bug
On Tue, 2 Aug 2005, Nick Piggin wrote: > > Any chance you can change the __follow_page test to account for > writeable clean ptes? Something like > > if (write && !pte_dirty(pte) && !pte_write(pte)) > goto out; > > And then you would re-add the set_page_dirty logic further on. Hmm.. That should be possible. I wanted to do the simplest possible code sequence, but yeah, I guess there's nothing wrong with allowing the code to dirty the page. Somebody want to send me a proper patch? Also, I haven't actually heard from whoever actually noticed the problem in the first place (Robin?) whether the fix does fix it. It "obviously does", but testing is always good ;) 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 2.6.13-rc4] fix get_user_pages bug
On Mon, 2005-08-01 at 20:45 -0700, Linus Torvalds wrote: > > On Tue, 2 Aug 2005, Nick Piggin wrote: > > > > Surely this introduces integrity problems when `force` is not set? > > "force" changes how we test the vma->vm_flags, that was always the > meaning from a security standpoint (and that hasn't changed). > Of course, this test catches the problem I had in mind. > The old code had this "lookup_write = write && !force;" thing because > there it used "force" to _clear_ the write bit test, and that was what > caused the race in the first place - next time around we would accept a > non-writable page, even if it hadn't actually gotten COW'ed. > > So no, the patch doesn't introduce integrity problems by ignoring "force". > Quite the reverse - it _removes_ the integrity problems by ignoring it > there. That's kind of the whole point. > OK, I'm convinced. One last thing - your fix might have a non trivial overhead in terms of spin locks and simply entering the high level page fault handler when dealing with clean, writeable ptes for write. Any chance you can change the __follow_page test to account for writeable clean ptes? Something like if (write && !pte_dirty(pte) && !pte_write(pte)) goto out; And then you would re-add the set_page_dirty logic further on. Not that I know what Robin's customer is doing exactly, but it seems like something you can optimise easily enough. Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 23:55 -0400, Steven Rostedt wrote: > On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote: > > It means that IRQ 14 is running for a long time as an RT task > > Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's > the IDE drive interrupt and it gets pretty busy. Actually the check > doesn't really see if it is running for a long time, since it gets > scheduled out. But I'm running this on a slow 368MHz machine and it > takes some time. There's cases where every second the interrupt just > happened to be running, since that is what it checks. It doesn't check > to see if the thread actual sleeps. > > I may add something to your patch to see if a thread actually goes to > sleep. If it doesn't then to flag it as possible stuck. I was offering to do that earlier , but I assumed your other patch was sufficient .. Feel free to add it if you think it's needed.. 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: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote: > It means that IRQ 14 is running for a long time as an RT task Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's the IDE drive interrupt and it gets pretty busy. Actually the check doesn't really see if it is running for a long time, since it gets scheduled out. But I'm running this on a slow 368MHz machine and it takes some time. There's cases where every second the interrupt just happened to be running, since that is what it checks. It doesn't check to see if the thread actual sleeps. I may add something to your patch to see if a thread actually goes to sleep. If it doesn't then to flag it as possible stuck. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc4] fix get_user_pages bug
On Tue, 2 Aug 2005, Nick Piggin wrote: > > Surely this introduces integrity problems when `force` is not set? "force" changes how we test the vma->vm_flags, that was always the meaning from a security standpoint (and that hasn't changed). The old code had this "lookup_write = write && !force;" thing because there it used "force" to _clear_ the write bit test, and that was what caused the race in the first place - next time around we would accept a non-writable page, even if it hadn't actually gotten COW'ed. So no, the patch doesn't introduce integrity problems by ignoring "force". Quite the reverse - it _removes_ the integrity problems by ignoring it there. That's kind of the whole point. 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: 2.6.13-rc4 use after free in class_device_attr_show
On Tue, 02 Aug 2005 13:05:50 +1000, Keith Owens <[EMAIL PROTECTED]> wrote: >The vcsnn value varies. I traced the dentry parent chain for the >latest event. From bottom to top the d_name entries are > > dev, vcs16, vc, class, /. > >That makes no sense, why is dev a child of vcs16? Raw data at the end. Ignore that bit, I was confusing /dev and dev as a subdir of a sysfs entry. The parent chain is right. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Report: 2.6.13-rc4-mm1: only 8 errors for 752 randconfig builds
Grant Coady <[EMAIL PROTECTED]> wrote: > > Greetings, > > Automating random config kernel build testing, for 2.6.13-rc4-mm1: > > Done processing 752 random builds, from which: > ### 8 .configs produced errors > ### 11 .configs produced undefs > ### 52 .configs produced warnings > > Abbreviated errors (first 2 lines/error): whee. I fixed a couple locally: > arch/i386/kernel/cpu/transmeta.c: In function `init_transmeta': > arch/i386/kernel/cpu/transmeta.c:82: error: invalid lvalue in assignment > ... > ipc/shm.c:174: error: `shmem_set_policy' undeclared here (not in a function) > ipc/shm.c:174: error: initializer element is not constant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc4 use after free in class_device_attr_show
On Mon, 1 Aug 2005 12:03:21 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: >Keith Owens <[EMAIL PROTECTED]> wrote: >> >> On Sat, 30 Jul 2005 02:29:55 -0700, >> Andrew Morton <[EMAIL PROTECTED]> wrote: >> >Keith Owens <[EMAIL PROTECTED]> wrote: >> >> >> >> 2.6.13-rc4 + kdb, with lots of CONFIG_DEBUG options. There is an >> >> intermittent use after free in class_device_attr_show. Reboot with no >> >> changes and the problem does not always recur. >> >> ... >> >> ip is at class_device_attr_show+0x50/0xa0 >> >> ... >> > >> >It might help to know which file is being read from here. >> > >> >The below patch will record the name of the most-recently-opened sysfs >> >file. You can print last_sysfs_file[] in the debugger or add the >> >appropriate printk to the ia64 code? >> >> No need for a patch. It is /dev/vcsa2. > >You mean /sys/class/vc/vcsa2? The vcsnn value varies. I traced the dentry parent chain for the latest event. From bottom to top the d_name entries are dev, vcs16, vc, class, /. That makes no sense, why is dev a child of vcs16? Raw data at the end. >That appears to be using generic code... > >Can you please summarise what you curently know about this bug? What is >being accessed after free in class_device_attr_show()? class_dev_attr? >cd? IA64, compiled for both SMP and uni-processor. Lots of debug configs, including slab poisoning. The problem was first noticed at 2.6.13-rc3, it has also been seen in -rc4. It is very intermittent, so -rc3 may not be the starting point. Failures have been seen in two sysfs routines, sysfs_read_file()->class_device_attr_show() and sysfs_release()->module_put(owner). The common denominator in the failures is that sd->s_element points to poisoned data. Raw data, from the failure in sysfs_release: kdb> filp 0xe0301eeae8d0 name.name 0xe0301d171384 name.len 3 File Pointer at 0xe0301eeae8d0 f_list.nxt = 0xe0301eeaea08 f_list.prv = 0xe03003e5aeb8 f_dentry = 0xe0301d1712a0 f_op = 0xa00100a615c8 f_count = 0 f_flags = 0x8000 f_mode = 0xd f_pos = 5 dentry parent chain. /class/vc/vcs16/dev WTF? kdb> dentry 0xe0301d1712a0 Dentry at 0xe0301d1712a0 d_name.len = 3 d_name.name = 0xe0301d171384 d_count = 1 d_flags = 0x18 d_inode = 0xe0b476b32df0 d_parent = 0xe0301d171a80 d_hash.nxt = 0x d_hash.prv = 0x00200200 d_lru.nxt = 0xe0301d1712f8 d_lru.prv = 0xe0301d1712f8 d_child.nxt = 0xe0301d171af8 d_child.prv = 0xe0301d171af8 d_subdirs.nxt = 0xe0301d171318 d_subdirs.prv = 0xe0301d171318 d_alias.nxt = 0xe0b476b32e20 d_alias.prv = 0xe0b476b32e20 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58 kdb> dentry 0xe0301d171a80 Dentry at 0xe0301d171a80 d_name.len = 5 d_name.name = 0xe0301d171b64 d_count = 2 d_flags = 0x10 d_inode = 0xe0301986cac0 d_parent = 0xe0347b87c880 d_hash.nxt = 0x d_hash.prv = 0x00200200 d_lru.nxt = 0xe0301d171ad8 d_lru.prv = 0xe0301d171ad8 d_child.nxt = 0xe03011ba9ae8 d_child.prv = 0xe03019f974c8 d_subdirs.nxt = 0xe0301d171308 d_subdirs.prv = 0xe0301d171308 d_alias.nxt = 0xe0301986caf0 d_alias.prv = 0xe0301986caf0 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58 kdb> dentry 0xe0347b87c880 Dentry at 0xe0347b87c880 d_name.len = 2 d_name.name = 0xe0347b87c964 d_count = 8 d_flags = 0x0 d_inode = 0xe0b47a5dad70 d_parent = 0xe0b47a404760 d_hash.nxt = 0x d_hash.prv = 0xa0020079d000 d_lru.nxt = 0xe0347b87c8d8 d_lru.prv = 0xe0347b87c8d8 d_child.nxt = 0xe0b47a445668 d_child.prv = 0xe0347b921548 d_subdirs.nxt = 0xe0301a1fd788 d_subdirs.prv = 0xe0347b87c7c8 d_alias.nxt = 0xe0b47a5dada0 d_alias.prv = 0xe0b47a5dada0 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58 kdb> dentry 0xe0b47a404760 Dentry at 0xe0b47a404760 d_name.len = 5 d_name.name = 0xe0b47a404844 d_count = 20 d_flags = 0x0 d_inode = 0xe0347bc95c18 d_parent = 0xe0b47a405180 d_hash.nxt = 0x d_hash.prv = 0xa002002d4bc8 d_lru.nxt = 0xe0b47a4047b8 d_lru.prv = 0xe0b47a4047b8 d_child.nxt = 0xe0b47a4048e8 d_child.prv = 0xe0b47a4046a8 d_subdirs.nxt = 0xe03013818d68 d_subdirs.prv = 0xe0b47a405d28 d_alias.nxt = 0xe0347bc95c48 d_alias.prv = 0xe0347bc95c48 d_op = 0xa00100a61870 d_sb = 0xe03003e5ad58 kdb> dentry 0xe0b47a405180 Dentry at 0xe0b47a405180 d_name.len = 1 d_name.name = 0xe0b47a405264 d_count = 11 d_flags = 0x10 d_inode = 0xe0347bc97460 d_parent = 0xe0b47a405180 d_hash.nxt = 0x d_hash.prv = 0x d_lru.nxt = 0xe0b47a4051d8 d_lru.prv = 0xe0b47a4051d8 d_child.nxt = 0xe0b47a4051e8 d_child.prv = 0xe0b47a4051e8 d_subdirs.nxt = 0xe0b47a446ce8 d_subdirs.prv = 0xe0b47a404a08 d_alias.nxt = 0xe0347bc97490 d_alias.prv = 0xe0347bc97490 d_op
Report: 2.6.13-rc4-mm1: only 8 errors for 752 randconfig builds
Greetings, Automating random config kernel build testing, for 2.6.13-rc4-mm1: Done processing 752 random builds, from which: ### 8 .configs produced errors ### 11 .configs produced undefs ### 52 .configs produced warnings Abbreviated errors (first 2 lines/error): [EMAIL PROTECTED]:/opt/linux$ zcat result-report-error-abbrev.gz|cut -d: -f2- arch/i386/kernel/cpu/transmeta.c: In function `init_transmeta': arch/i386/kernel/cpu/transmeta.c:82: error: invalid lvalue in assignment arch/i386/mach-es7000/es7000.h:82: error: field `id' has incomplete type arch/i386/mach-es7000/es7000.h:88: error: field `Header' has incomplete type arch/i386/mach-es7000/es7000plat.c: In function `parse_unisys_oem': arch/i386/mach-es7000/es7000plat.c:154: error: `es7000_rename_gsi' undeclared (first use in this function) drivers/char/ipmi/ipmi_msghandler.c:1397: warning: `ipmb_file_read_proc' defined but not used drivers/char/ipmi/ipmi_msghandler.c:1406: warning: `version_file_read_proc' defined but not used drivers/char/speakup/speakup.c: In function `speakup_bits': drivers/char/speakup/speakup.c:1983: error: `pb_edit' undeclared (first use in this function) drivers/mtd/maps/nettel.c: In function `nettel_init': drivers/mtd/maps/nettel.c:419: error: `ROOT_DEV' undeclared (first use in this function) include/asm-i386/mach-default/mach_apic.h:25: error: syntax error before "bitmap" include/asm-i386/mach-default/mach_apic.h:26: warning: function declaration isn't a prototype include/asm-i386/mach-visws/do_timer.h: In function `do_timer_overflow': include/asm-i386/mach-visws/do_timer.h:32: error: `i8259A_lock' undeclared (first use in this function) ipc/shm.c:174: error: `shmem_set_policy' undeclared here (not in a function) ipc/shm.c:174: error: initializer element is not constant sound/core/memalloc.c: In function `snd_mem_exit': sound/core/memalloc.c:658: error: `snd_mem_proc' undeclared (first use in this function) Further info, full error results, configs producing errors, etc from http://scatter.mine.nu/test/kernel/2.6.13-rc4-mm1/ Warnings recorded are those not deprecated, not #warning. bzip2 tarballs of configs producing errors, undefs 22kB, warnings 86kB A significant data reduction from the 28MB raw build results :) Note: the report generator lists all faults for a particular source file, explains why summary above for errors shows warnings in first 2 lines. Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: IO scheduling & filesystem v a few processes writing a lot
On Mon, 1 Aug 2005, Sander wrote: Dr. David Alan Gilbert wrote (ao): * Sander ([EMAIL PROTECTED]) wrote: Dr. David Alan Gilbert wrote (ao): I was using rsync, but the problem with rsync is that I have a back up server then filled with lots and lots of small files - I want larger files for spooling to tape. (Other suggestions welcome) Can't you just tar the small files from the backupserver to tape? (or, what is the problem with that?). Lots of small files->slow; it is an LTO-2 tape drive that is spec'd at 35MByte/s - it won't get that if I'm feeding it from something seeking all over. ic. Sorry if the question is stupid, but is it bad not to reach 35MB/sec? with modern tape drives, when you fall out of streaming mode you are lucky to get 1/10 of the rated drive performance (not to mention the extra wear and tear on the tape and the drive) the common thing is to do disk->disk->tape backups. use rsync to pull your data from the remote machines to your server, then use tar on the server to make the one image you want to put on the tape (frequently onto a different drive), then record that image to tape. note that tar is not nessasarily the best format to use for this in the face of tape errors (see backup software companies for details, several years ago I read an interesting document from the bru backup folks that went into details) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ECC Support in Linux
On 2005.08.01 13:03:34 +, Roger Heflin wrote: > > On the newer Intels I have not found any useable ECC support > is there any in the kernels? For ia32, not in kernel now, see http://bluesmoke.sf.net For ia64, kernel already have support. > > I can test a variety of hardware if someone needs it, and can > probably even come up with some test memory that will generate ecc > errors. > Good! bluesmoke now has many advanced server support, you can help to test those drivers. Pls subscribe bluesmoke's ML. thanks -zhen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc4] fix get_user_pages bug
Linus Torvalds wrote: Instead, I'd suggest changing the logic for "lookup_write". Make it require that the page table entry is _dirty_ (not writable), and then remove the line that says: lookup_write = write && !force; and you're now done. A successful mm fault for write _should_ always have marked the PTE dirty (and yes, part of testing this would be to verify that this is true - but since architectures that don't have HW dirty bits depend on this anyway, I'm pretty sure it _is_ true). Ie something like the below (which is totally untested, obviously, but I think conceptually is a lot more correct, and obviously a lot simpler). Surely this introduces integrity problems when `force` is not set? Security holes? Perhaps not, but I wouldn't guarantee it. However: I like your idea. And getting rid of the lookup_write logic is a good thing. I don't much like that it changes the semantics of follow_page for write on a readonly pte, and that is where your problem is introduced. I think to go down this route you'd at least need a follow_page check that is distinct from 'write'. 'writeable', maybe. Then, having a 'writeable' flag lets you neatly "comment" your idea of what might constitute a writeable pte, as opposed to the current code which basically looks like black magic to a reader, and gives no indication of how it satisfies the get_user_pages requirements. A minor issue: I don't much like the proliferation of __follow_page flags either. Why not make __follow_page take a bitmask, and be used directly by get_user_pages, which would also allow removal of the 'write' argument from follow_page. I would cook you some patches, but I'm not in front of the source tree. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dynamic ticks for 2.6.13-rc4 & bad gzip
Hi Tony, LKML
Since there appears to be renewed interest of late in dynamic ticks...
You didn't respond with my last patch for dynamic ticks so I assume that's
because you threw up when you saw what a mess it is. Anyway I'm sorry for
sending you that naive mess the first time around.
Here is a full patch for 2.6.13-rc4 pushing code out of common paths and into
dyn-tick.h where possible that builds on any config I can throw on it so far.
I'm having trouble with "bad gzip magic" on boot with this one so I'm not
really sure what's going on. Perhaps someone on the mailing list can shed
some light on it.
Cheers,
Con
Index: linux-2.6.13-rc4-ck1/arch/i386/Kconfig
===
--- linux-2.6.13-rc4-ck1.orig/arch/i386/Kconfig 2005-07-30 00:38:24.0 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/Kconfig 2005-08-02 09:04:08.0 +1000
@@ -457,6 +457,38 @@ config HPET_EMULATE_RTC
bool "Provide RTC interrupt"
depends on HPET_TIMER && RTC=y
+config NO_IDLE_HZ
+ bool "Dynamic Tick Timer - Skip timer ticks during idle"
+ help
+ This option enables support for skipping timer ticks when the
+ processor is idle. During system load, timer is continuous.
+ This option saves power, as it allows the system to stay in
+ idle mode longer. Currently supported timers are ACPI PM
+ timer, local APIC timer, and TSC timer. HPET timer is currently
+ not supported.
+
+ Note that you need to enable dynamic tick timer either by
+ passing dyntick=enable command line option, or via sysfs:
+
+ # echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
+
+config DYN_TICK_USE_APIC
+ bool "Use APIC timer instead of PIT timer"
+ depends on NO_IDLE_HZ
+ help
+ This option enables using APIC timer interrupt if your hardware
+ supports it. APIC timer allows longer sleep periods compared
+ to PIT timer.
+
+ Note that on most recent hardware disabling PIT timer also
+ disables APIC timer interrupts, and system won't run properly.
+ Symptoms include slow system boot, and time running slow.
+
+ If unsure, don't enable this option.
+
+ Note that to you still need to pass dyntick=enable,forceapic
+ command line option to use APIC timer.
+
config SMP
bool "Symmetric multi-processing support"
---help---
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/apic.c
===
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/apic.c 2005-07-30 00:06:26.0 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/apic.c 2005-08-02 09:34:00.0 +1000
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -931,6 +932,8 @@ void (*wait_timer_tick)(void) __devinitd
#define APIC_DIVISOR 16
+u32 apic_timer_val;
+
static void __setup_APIC_LVTT(unsigned int clocks)
{
unsigned int lvtt_value, tmp_value, ver;
@@ -949,7 +952,12 @@ static void __setup_APIC_LVTT(unsigned i
& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
| APIC_TDR_DIV_16);
- apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+ apic_timer_val = clocks/APIC_DIVISOR;
+
+ if (apic_timer_val)
+ set_dyn_tick_max_skip(apic_timer_val);
+
+ apic_write_around(APIC_TMICT, apic_timer_val);
}
static void __devinit setup_APIC_timer(unsigned int clocks)
@@ -1062,6 +1070,8 @@ void __init setup_boot_APIC_clock(void)
*/
setup_APIC_timer(calibration_result);
+ setup_dyn_tick_use_apic(calibration_result);
+
local_irq_enable();
}
@@ -1200,6 +1210,13 @@ fastcall void smp_apic_timer_interrupt(s
* interrupt lock, which is the WrongThing (tm) to do.
*/
irq_enter();
+
+ /*
+ * Check if we need to wake up PIT interrupt handler.
+ * Otherwise just wake up local APIC timer.
+ */
+ wakeup_pit_or_apic(cpu, regs);
+
smp_local_timer_interrupt(regs);
irq_exit();
}
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/dyn-tick.c
===
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/dyn-tick.c 2005-01-12 16:19:45.0 +1100
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/dyn-tick.c 2005-08-02 10:49:57.0 +1000
@@ -0,0 +1,164 @@
+/*
+ * linux/arch/i386/kernel/dyn-tick.c
+ *
+ * Copyright (C) 2004 Nokia Corporation
+ * Written by Tony Lindgen <[EMAIL PROTECTED]> and
+ * Tuukka Tikkanen <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_X86_LOCAL_APIC
+void reprogram_apic_timer(unsigned int count)
+{
+ unsigned long flags;
+
+ count *= apic_timer_val;
+ local_irq_save(flags);
+ apic_write_around(APIC_TMICT, count);
+ local_irq_restore(flags);
+}
+#else
+void reprogram_apic_timer(unsigned int count)
+{
+}
+
+#endif
+
+void arch_reprogram_timer(void)
+{
+ if (cpu_has_local_apic()) {
+
Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote: > On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote: > > Ingo, > > > > What's with the "BUG: possible soft lockup detected on CPU..."? I'm > > getting a bunch of them from the IDE interrupt. It's not locking up, > > but it does things that probably do take some time. Is this really > > necessary? Here's an example dump: > > > > -- Steve > > > > Note: I added the curr=%s:%d,current->comm,current->pid just to see who > > was at fault. > > It means that IRQ 14 is running for a long time as an RT task .. btw, > the curr=%s:%d information duplicates some in the "show all held locks" > section . yeah I know that was redundant (after putting it in), but I wanted to make sure what current was. The locks held wasn't as straight forward as to what was current (I wasn't looking at what produced that, I just noticed the output). > > I could base it off current_sched_time() to only trigger if the task has > actually been running for 10 seconds, instead of just assuming that it > has.. I thought about changing that too. But I'm assuming that you are looking for bugs (like the kjournald as RT) where a task may be in a loop, but higher priority tasks can still preempt it. Putting the check elsewhere will still be screwed up by preempting higher prio tasks. In my custom kernel, I have a wchan field of the task that records where the task calls something that might schedule. This way I can see where things locked up if I don't have a back trace of the task. This field is always zero when it switches to usermode. Something like this can also be used to check how long the process is in kernel mode. If a task is in the kernel for more than 10 seconds without sleeping, that would definitely be a good indication of something wrong. I probably could write something to check for this if people are interested. I wont waste my time if nobody would want it. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: atomic counter underflow at ip_conntrack_event_cache_init+0x91/0xb0 (with patch)
Patrick McHardy wrote:
> Mattia Dongili wrote:
>
>>On Mon, Aug 01, 2005 at 04:27:53PM +0200, Patrick McHardy wrote:
>>
>>
--- include/linux/netfilter_ipv4/ip_conntrack.h.clean 2005-08-01
15:09:49.0 +0200
+++ include/linux/netfilter_ipv4/ip_conntrack.h 2005-08-01
15:08:52.0 +0200
@@ -298,6 +298,7 @@ static inline struct ip_conntrack *
ip_conntrack_get(const struct sk_buff *skb, enum ip_conntrack_info *ctinfo)
{
*ctinfo = skb->nfctinfo;
+ nf_conntrack_get(skb->nfct);
return (struct ip_conntrack *)skb->nfct;
}
>>>
>>>This creates lots of refcnt leaks, which is probably why it makes the
>>>underflow go away :) Please try this patch instead.
>>
>>
>>this doesn't fix it actually, see dmesg below:
>
>
> It looks like ip_ct_iterate_cleanup and ip_conntrack_event_cache_init
> race against each other with assigning pointers and grabbing/putting the
> refcounts if called from different contexts.
This should be a fist step towards fixing it. It's probably incomplete
(I'm too tired to check it now), but it should fix the problem you're
seeing. Could you give it a spin?
BTW, ip_ct_iterate_cleanup can only be called from ipt_MASQUERADE when
a device goes down. It seems a bit odd that this is happending on boot,
is there anything special about your setup?
Regards
Patrick
diff --git a/include/linux/netfilter_ipv4/ip_conntrack.h
b/include/linux/netfilter_ipv4/ip_conntrack.h
--- a/include/linux/netfilter_ipv4/ip_conntrack.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -411,6 +411,7 @@ struct ip_conntrack_stat
#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
#include
+#include
struct ip_conntrack_ecache {
struct ip_conntrack *ct;
@@ -445,26 +446,25 @@ ip_conntrack_expect_unregister_notifier(
return notifier_chain_unregister(_conntrack_expect_chain, nb);
}
+extern void ip_conntrack_event_cache_init(struct ip_conntrack *ct);
+extern void
+ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct);
+
static inline void
ip_conntrack_event_cache(enum ip_conntrack_events event,
const struct sk_buff *skb)
{
- struct ip_conntrack_ecache *ecache =
- &__get_cpu_var(ip_conntrack_ecache);
-
- if (unlikely((struct ip_conntrack *) skb->nfct != ecache->ct)) {
- if (net_ratelimit()) {
- printk(KERN_ERR "ctevent: skb->ct != ecache->ct !!!\n");
- dump_stack();
- }
- }
+ struct ip_conntrack *ct = (struct ip_conntrack *)skb->nfct;
+ struct ip_conntrack_ecache *ecache;
+
+ local_bh_disable();
+ ecache = &__get_cpu_var(ip_conntrack_ecache);
+ if (unlikely(ct != ecache->ct))
+ ip_conntrack_event_cache_init(ct);
ecache->events |= event;
+ local_bh_enable();
}
-extern void
-ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct);
-extern void ip_conntrack_event_cache_init(const struct sk_buff *skb);
-
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct)
{
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c
b/net/ipv4/netfilter/ip_conntrack_core.c
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -100,56 +100,45 @@ void __ip_ct_deliver_cached_events(struc
/* Deliver all cached events for a particular conntrack. This is called
* by code prior to async packet handling or freeing the skb */
-void
-ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct)
+void ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct)
{
- struct ip_conntrack_ecache *ecache =
- &__get_cpu_var(ip_conntrack_ecache);
-
- if (!ct)
- return;
-
+ struct ip_conntrack_ecache *ecache;
+
+ local_bh_disable();
+ ecache = &__get_cpu_var(ip_conntrack_ecache);
if (ecache->ct == ct) {
DEBUGP("ecache: delivering event for %p\n", ct);
__deliver_cached_events(ecache);
} else {
- if (net_ratelimit())
- printk(KERN_WARNING "ecache: want to deliver for %p, "
- "but cache has %p\n", ct, ecache->ct);
+ DEBUGP("ecache: already delivered for %p, cache %p",
+ ct, ecache->ct);
}
-
/* signalize that events have already been delivered */
ecache->ct = NULL;
+ local_bh_enable();
}
/* Deliver cached events for old pending events, if current conntrack != old */
-void ip_conntrack_event_cache_init(const struct sk_buff *skb)
+void ip_conntrack_event_cache_init(struct ip_conntrack *ct)
{
- struct ip_conntrack *ct = (struct ip_conntrack *) skb->nfct;
- struct ip_conntrack_ecache *ecache =
-
Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 14:09 -0700, Daniel Walker wrote: > > You guys want me to always CC in the future? Yes, please CC the LKML. I try to for all updates since I might have done a mistake in my code that my shallow tests don't catch, and others might. Also to let others know what I'm suggesting to Ingo so they may comment as well. I've had some pretty good comments from people, as well as just deeper thoughts in what's being changed. I also try to see what's being proposed to Ingo's patch to make sure that I understand what my code will be depending on. Your wakeup race patch is a perfect example of something that should definitely be CC'd to LKML. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci cacheline size / latency oddness.
On Mon, 2005-08-01 at 19:35 -0400, Dave Jones wrote: > This means we will do the wrong thing on AMD machines which have > 64 byte cachelines. pcibios_init (in i386/pci/common.c, which is linked in by X86_64 PCI code) seems to do this if (c->x86 >= 6 && c->x86_vendor == X86_VENDOR_AMD) pci_cache_line_size = 64 >> 2; /* K7 & K8 */ Is it correct to expect all AMD k7/8 machines to have 16 as cache line size - I thought 64 was more appropriate? On my Athlon64 laptop, all PCI devices end up having 0 latency. > x86-64 doesn't have an arch override for pci_cache_line_size I am trying to fix it up - What's the right way to override it in x86_64 code? Just initialize it to 64 may be? 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/
Re: [PATCH] sonypi, kernel 2.6.12.3
On Mon, Aug 01, 2005 at 10:45:03AM +0200, Stelian Pop wrote:
> Le lundi 01 août 2005 à 02:59 +0200, Erik Waling a écrit :
> > Newer Sony VAIO models (VGN-S480, VGN-S460, VGN-S3XP etc) use a new method
> > to
> > initialize the SPIC device. The new way to initialize (and disable) the
> > device
> > comes directly from the AML code in the _CRS, _SRS and _DIS methods from the
> > DSDT table. This patch against 2.6.12.3 adds support for the new models.
> >
> > -- Erik Waling <[EMAIL PROTECTED]>
> >
> >
> >
> > --- linux-2.6.12.3/drivers/char/sonypi.c2005-07-15 16:18:57.0
> > -0500
> > +++ linux/drivers/char/sonypi.c 2005-07-31 16:55:41.0 -0500
>
> [...]
>
> > + - some models with the nvidia card (geforce go 6200 tc) uses a
> > + different way to adjust the backlighting of the screen. There
> > + is a userspace utility to adjust the brightness on those models.
>
> Don't be shy, put the URL pointing to your SmartDimmer here :)
>
> Otherwise you have my:
> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
>
> Thanks Erik.
>
> Stelian.
> --
> Stelian Pop <[EMAIL PROTECTED]>
Added URL to the smartdimmer tool (to adjust backlight levels on newer
models) in the docs. Also forgot to sign my last post with the patch... So:
Signed-off-by: Erik Waling <[EMAIL PROTECTED]>
--- linux-2.6.12.3/drivers/char/sonypi.c2005-07-15 16:18:57.0
-0500
+++ linux/drivers/char/sonypi.c 2005-07-31 16:55:41.0 -0500
@@ -98,12 +98,13 @@
#define SONYPI_DEVICE_MODEL_TYPE1 1
#define SONYPI_DEVICE_MODEL_TYPE2 2
+#define SONYPI_DEVICE_MODEL_TYPE3 3
/* type1 models use those */
#define SONYPI_IRQ_PORT0x8034
#define SONYPI_IRQ_SHIFT 22
-#define SONYPI_BASE0x50
-#define SONYPI_G10A(SONYPI_BASE+0x14)
+#define SONYPI_TYPE1_BASE 0x50
+#define SONYPI_G10A(SONYPI_TYPE1_BASE+0x14)
#define SONYPI_TYPE1_REGION_SIZE 0x08
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
@@ -114,6 +115,13 @@
#define SONYPI_TYPE2_REGION_SIZE 0x20
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
+/* type3 series specifics */
+#define SONYPI_TYPE3_BASE 0x40
+#define SONYPI_TYPE3_GID2 (SONYPI_TYPE3_BASE+0x48) /* 16 bits */
+#define SONYPI_TYPE3_MISC (SONYPI_TYPE3_BASE+0x6d) /* 8 bits */
+#define SONYPI_TYPE3_REGION_SIZE 0x20
+#define SONYPI_TYPE3_EVTYPE_OFFSET 0x12
+
/* battery / brightness addresses */
#define SONYPI_BAT_FLAGS 0x81
#define SONYPI_LCD_LIGHT 0x96
@@ -159,6 +167,10 @@
{ 0x0, 0x0 }
};
+/* same as in type 2 models */
+static struct sonypi_ioport_list *sonypi_type3_ioport_list =
+ sonypi_type2_ioport_list;
+
/* The set of possible interrupts */
struct sonypi_irq_list {
u16 irq;
@@ -180,6 +192,9 @@
{ 0, 0x00 }/* no IRQ, 0x00 in SIRQ in AML */
};
+/* same as in type2 models */
+static struct sonypi_irq_list *sonypi_type3_irq_list = sonypi_type2_irq_list;
+
#define SONYPI_CAMERA_BRIGHTNESS 0
#define SONYPI_CAMERA_CONTRAST 1
#define SONYPI_CAMERA_HUE 2
@@ -223,6 +238,7 @@
#define SONYPI_MEYE_MASK 0x0400
#define SONYPI_MEMORYSTICK_MASK0x0800
#define SONYPI_BATTERY_MASK0x1000
+#define SONYPI_WIRELESS_MASK 0x2000
struct sonypi_event {
u8 data;
@@ -305,6 +321,13 @@
{ 0, 0 }
};
+/* The set of possible wireless events */
+static struct sonypi_event sonypi_wlessev[] = {
+ { 0x59, SONYPI_EVENT_WIRELESS_ON },
+ { 0x5a, SONYPI_EVENT_WIRELESS_OFF },
+ { 0, 0 }
+};
+
/* The set of possible back button events */
static struct sonypi_event sonypi_backev[] = {
{ 0x20, SONYPI_EVENT_BACK_PRESSED },
@@ -391,6 +414,12 @@
{ SONYPI_DEVICE_MODEL_TYPE2, 0x41, SONYPI_BATTERY_MASK,
sonypi_batteryev },
{ SONYPI_DEVICE_MODEL_TYPE2, 0x31, SONYPI_PKEY_MASK, sonypi_pkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0, 0x, sonypi_releaseev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x21, SONYPI_FNKEY_MASK, sonypi_fnkeyev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x31, SONYPI_WIRELESS_MASK, sonypi_wlessev
},
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x31, SONYPI_MEMORYSTICK_MASK,
sonypi_memorystickev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x41, SONYPI_BATTERY_MASK,
sonypi_batteryev },
+ { SONYPI_DEVICE_MODEL_TYPE3, 0x31, SONYPI_PKEY_MASK, sonypi_pkeyev },
{ 0 }
};
@@ -558,6 +587,23 @@
udelay(10);
}
+static void sonypi_type3_srs(void)
+{
+ u16 v16;
+ u8 v8;
+
+ /* This model type uses the same initialiazation of
+* the embedded controller as the type2 models. */
+ sonypi_type2_srs();
+
+ /* Initialization of PCI config space of the LPC interface bridge. */
+ v16 =
Re: [patch 2.6.13-rc4] fix get_user_pages bug
Linus Torvalds wrote: On Mon, 1 Aug 2005, Nick Piggin wrote: Not sure if this should be fixed for 2.6.13. It can result in pagecache corruption: so I guess that answers my own question. Hell no. This patch is clearly untested and must _not_ be applied: Yes, I meant that the problem should be fixed, not that the patch should be applied straight away. I wanted to get discussion going ASAP. Looks like it worked :) I'll catch up on it now. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] String conversions for memory policy
New version without the magic numbers ...
---
String conversions for memory policy
This patch adds two new functions to mm/mempolicy.c that allow the conversion
of a memory policy to a textual representation and vice versa.
Syntax of textual representation:
default
preferred=
bind=
interleave=
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc4-mm1/mm/mempolicy.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/mempolicy.c2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/mempolicy.c 2005-08-01 17:14:08.0 -0700
@@ -1170,3 +1170,95 @@
{
sys_set_mempolicy(MPOL_DEFAULT, NULL, 0);
}
+
+static const char *policy_types[] = { "default", "prefer", "bind",
"interleave" };
+
+/*
+ * Convert a mempolicy into a string.
+ * Returns the number of characters in buffer (if positive)
+ * or an error (negative)
+ */
+int mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
+{
+ char *p = buffer;
+ int l;
+ nodemask_t nodes;
+ mode = pol ? pol->policy : MPOL_DEFAULT;
+
+ switch (mode) {
+ case MPOL_DEFAULT:
+ nodes_clear(nodes);
+ break;
+
+ case MPOL_PREFERRED:
+ nodes_clear(nodes);
+ node_set(pol->v.preferred_node, nodes);
+ break;
+
+ case MPOL_BIND:
+ get_zonemask(pol, nodes.bits);
+ break;
+
+ case MPOL_INTERLEAVE:
+ nodes = * (nodemask_t *)pol->v.nodes;
+ break;
+
+ default:
+ BUG();
+ return -EFAULT;
+ }
+
+ l = strlen(policy_types[mode]);
+ if (buffer + maxlen > p + l + 1)
+ return -ENOSPC;
+ strcpy(p, policy_types[mode]);
+ p += l;
+
+ if (!nodes_empty(nodes)) {
+
+ if (buffer + maxlen > p + 2)
+ return -ENOSPC;
+
+ *p++ = '=';
+ p += nodelist_scnprintf(p, buffer + maxlen - p, nodes);
+ }
+ return p - buffer;
+}
+
+/*
+ * Convert a representation of a memory policy from text
+ * form to binary.
+ *
+ * Returns either a memory policy or NULL for error.
+ */
+struct mempolicy *str_to_mpol(char *buffer)
+{
+ nodemask_t nodes;
+ int mode;
+ int l;
+
+ for(mode = 0; mode <= MPOL_MAX; mode++) {
+ l = strlen(policy_types[mode]);
+ if (strnicmp(policy_types[mode], buffer, l)
+ && (mode == MPOL_DEFAULT || buffer[l] == '='))
+ break;
+ }
+
+ if (mode > MPOL_MAX)
+ return NULL;
+
+ if (mode == MPOL_DEFAULT)
+ return _policy;
+
+ if (nodelist_parse(buffer + l + 1, nodes) || nodes_empty(nodes))
+ return NULL;
+
+ /* Update current mems_allowed */
+ cpuset_update_current_mems_allowed();
+ /* Ignore nodes not set in current->mems_allowed */
+ cpuset_restrict_to_mems_allowed(nodes.bits);
+
+ if (!mpol_check_policy(mode, nodes.bits))
+ return NULL;
+ return mpol_new(mode, nodes.bits);
+}
Index: linux-2.6.13-rc4-mm1/include/linux/mempolicy.h
===
--- linux-2.6.13-rc4-mm1.orig/include/linux/mempolicy.h 2005-08-01
12:59:45.0 -0700
+++ linux-2.6.13-rc4-mm1/include/linux/mempolicy.h 2005-08-01
13:00:01.0 -0700
@@ -157,6 +157,10 @@
extern void numa_policy_init(void);
extern struct mempolicy default_policy;
+/* Conversion functions */
+int mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol);
+struct mempolicy *str_to_mpol(char *buffer);
+
#else
struct mempolicy {};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Mon, 1 Aug 2005, Andrew Haninger wrote: Thorsten: Please remember to include the list(s) when emailing those links/numbers. I'd like to be able to watch it, too, and add any information that I can, rather than entering a duplicate bug. Hello. I have taken a closer look at the ALSA AD1816 sound driver during the last weekend. Here are my findings: On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when loading the snd-ad1816a module. No messages have been logged to the syslog and the system is otherwise stable. Of course the sound card is unusable. On Linux 2.6.8 (as shipped with current Debian Sarge), vanilla Linux 2.6.10 and Linux 2.6.11.12 the module loads fine. I have done some tests with xmms(Debian), kphone(VoIP-Phone/Debian) and iaxcomm(VoIP-Phone/self-made). Audio playback with xmms is always fine using either ALSA or OSS emulation. Using OSS emulation with one of the VoIP phones, playback and recording stop a few seconds after the call is started. Using the ALSA interface with kphone works, but there is a continuous clicking approximately 3 times per second. Also audio latency is poor compared to the OSS driver. iaxcomm does not support the ALSA audio interface, thus no problems here. :-) The native OSS driver is fine on all kernels with all tested applications. Also the ALSA driver does not have an equivalent for the "ad1816_clockfreq" option of the OSS driver. The AD1816 chip requires a 33MHz reference clock, however some cards use a different (mostly 32.125MHz) clock, thus the audio sample rate has to be corrected before it is written to the hardware registers for proper playback and recording speed. I have not filed any bug reports to the ALSA bug tracking system so far, but will do so tomorrow and add the corresponding bug numbers to this thread. Thorsten -- ___ || / E-Mail: [EMAIL PROTECTED] |horsten |/\nabeWWW: http://linux.thorsten-knabe.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] net/sunrpc: fix time conversion error
On 02.08.2005 [02:03:59 +0200], Patrick McHardy wrote: > Nishanth Aravamudan wrote: > > On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote: > > > >>Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong: > >> > >>skb->stamp.tv_usec = xtime.tv_nsec * 1000; > >> > >>To convert nsec to usec, one should divide instead of multiplying: > >> > >>skb->stamp.tv_usec = xtime.tv_nsec / 1000; > >> > >>The same bug could be present in the latest kernels, although I haven't > >>checked. This bug makes svc_udp_recvfrom() timestamps incorrect. > > > > > > Agreed, the conversion is wrong. I think the code is buggy period, as it > > accesses xtime without grabbing the xtime_lock first. Following patch > > should fix both issues. > > > > Description: This function incorrectly multiplies a nanosecond value by > > 1000, instead of dividing by 1000, to obtain a corresponding microsecond > > value. Fix the math. Also, the function incorrectly accesses xtime > > without using the xtime_lock. Fixed as well. Patch is compile-tested. > > Depending on in which release you want this patch included, you might > want to redo it against Dave's net-2.6.14 tree. It includes a patch that > changes skb->stamp to an offset against a base timestamp. Ok, I'll try and get around to rediff'ing tonight or tomorrow. Thanks for the feedback! > PS: I'll submit the patch to break compilation for unconverted users > ASAP. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: pci cacheline size / latency oddness.
Dave Jones wrote: During boot of todays -git, I noticed this.. PCI: Setting latency timer of device :00:1d.7 to 64 after boot, lspci shows.. 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Dell: Unknown device 0169 Flags: bus master, medium devsel, latency 0, IRQ 201 ^^ Probably the hardware doesn't want you to set it, similar to what I describe in the following: It also complains about.. PCI: cache line size of 128 is not supported by device :00:1d.7 This message means that it couldn't set the cacheline size at all. Most likely it is either zero, or hardcoded in the silicon. Has very little to do with the platform, and more to do with the device. x86-64 doesn't have an arch override for pci_cache_line_size, so it ends up at L1_CACHE_BYTES >> 2, which is 128 if you build x86-64 kernels with CONFIG_GENERIC_CPU or CONFIG_MPSC This means we will do the wrong thing on AMD machines which have 64 byte cachelines. I saw this problem however on an em64t box. Would it make sense to shift >> once more if it fails, and retry with a smaller size perhaps ? Too big is far better than too small. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/sunrpc: fix time conversion error
Nishanth Aravamudan wrote: > On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote: > >>Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong: >> >>skb->stamp.tv_usec = xtime.tv_nsec * 1000; >> >>To convert nsec to usec, one should divide instead of multiplying: >> >>skb->stamp.tv_usec = xtime.tv_nsec / 1000; >> >>The same bug could be present in the latest kernels, although I haven't >>checked. This bug makes svc_udp_recvfrom() timestamps incorrect. > > > Agreed, the conversion is wrong. I think the code is buggy period, as it > accesses xtime without grabbing the xtime_lock first. Following patch > should fix both issues. > > Description: This function incorrectly multiplies a nanosecond value by > 1000, instead of dividing by 1000, to obtain a corresponding microsecond > value. Fix the math. Also, the function incorrectly accesses xtime > without using the xtime_lock. Fixed as well. Patch is compile-tested. Depending on in which release you want this patch included, you might want to redo it against Dave's net-2.6.14 tree. It includes a patch that changes skb->stamp to an offset against a base timestamp. Regards Patrick PS: I'll submit the patch to break compilation for unconverted users ASAP. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] String conversions for memory policy
On Mon, 1 Aug 2005, Paul Jackson wrote: > Christoph wrote: > > you need to create multiple > > levels of directories in /proc//xx > > You do? > > Where's the new multiple directory levels in the two files: > > /proc//numa_policy # contains one word > /proc//numa_nodelist # contains one nodelist > > There are some obvious negatives to this idea, but having to > "create multiple levels of directories" doesn't seem to be > one of them. One would need /proc///policy and /proc///nodelist to control the allocation in the vmas. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] String conversions for memory policy
Christoph wrote: > you need to create multiple > levels of directories in /proc//xx You do? Where's the new multiple directory levels in the two files: /proc//numa_policy # contains one word /proc//numa_nodelist # contains one nodelist There are some obvious negatives to this idea, but having to "create multiple levels of directories" doesn't seem to be one of them. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: dpm_runtime_suspend and _resume()
On Sat, 30 Jul 2005, Dominik Brodowski wrote: > dpm_runtime_suspend and _resume() would be quite useful for some PCMCIA > tasks. However, they are only exported in drivers/base/power/power.h. Any > objection to moving it to include/linux/pm.h ? Any plans to break the > functionality these functions provide? Break them anymore than they currently are? I wouldn't recommend using those functions. We're in the process of redeveloping the Runtime PM infrastructure and would hate to break users of existing poorly-designed infrastructure in the process. I'm curious what your usage model would be. After a certain amount of time of inactivity, I suspect that you want to power down a PCMCIA slot, right? Do you already have patches that do that? Is there any problem with calling the necessary functions directly? Thanks, Pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pci cacheline size / latency oddness.
During boot of todays -git, I noticed this.. PCI: Setting latency timer of device :00:1d.7 to 64 after boot, lspci shows.. 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: Dell: Unknown device 0169 Flags: bus master, medium devsel, latency 0, IRQ 201 ^^ It also complains about.. PCI: cache line size of 128 is not supported by device :00:1d.7 x86-64 doesn't have an arch override for pci_cache_line_size, so it ends up at L1_CACHE_BYTES >> 2, which is 128 if you build x86-64 kernels with CONFIG_GENERIC_CPU or CONFIG_MPSC This means we will do the wrong thing on AMD machines which have 64 byte cachelines. I saw this problem however on an em64t box. Would it make sense to shift >> once more if it fails, and retry with a smaller size perhaps ? 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: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
> Hmmm. this should have returned the behavior to normal. Ah. Need to use
> new_entry instead of entry. Try this (is there any way that I could get
> access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
>
> +#ifdef CONFIG_ATOMIC_TABLE_OPS
> /*
>* If the cmpxchg fails then another processor may have done
>* the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
> } else {
> inc_page_state(cmpxchg_fail_flag_update);
> }
> +#else
> + ptep_set_access_flags(vma, address, pte, new_entry, write_access);
> + update_mmu_cache(vma, address, new_entry);
> + lazy_mmu_prot_update(new_entry);
> +#endif
With this applied, the system boots then X locks up in memcpy as before.
The cmpxchg_fail_flag_update remains at zero but given the above patch,
that's to be expected...
Sadly, remote access to the system isn't really much use as there is no
compiler on the device and flashing a new kernel is a manual procedure
involving pressing buttons.
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Clock resolution / RT preemption
greg wrote: Hi folks, I'm looking for a timer resolution lower than 1 ms (and monotonic clock rate) destined to be used with some network code running on x86 platforms. Would you please provide me with informations about how to get/implement this. AFAIK, there's a "high resultion timer" patch hanging around, but there's not much informations with regard to portability (specific hardware requirements ?), scalability, integration with RT patches. I understand the POSIX 1003.1b Clocks and Timers system calls are not fully available within the linux kernel (and libc ?), am I right on that ? On the HRT web site (see signature) there is a CVS repository. In there is a special version for the RT kernel. As to porting it to other archs, have a look at the include/linux/hrtimer.h file. It has (or should have) all you need to know. Please pass back any port you do. One more question : I believe Ingo's preemption patch run timers/interrupt handlers within kernel threads, how should I assign specific priority to address my goals without compromising system stability ? Carefully :) -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] String conversions for memory policy
On Mon, 1 Aug 2005, Paul Jackson wrote: > In your related patch, you show how to merge this display of mempolicy > into the new /proc//smap (rss size of each memory area) file. > But this smap file (or, as you renamed it, emap file) is read-only, > so far as I can tell. It enables display of information, but not > changing it. How do you propose to support changing a memory policy? That is not clear yet. We need to discuss that. First I thought of just having a patch that creates /proc//numa_policy which allows to read and write the process policy (write via notifier not directly). > that other half should not also be used to display memory policies, > instead of adapting smap aka emap. e/smap is a generic way to get information about storage use of a vma. Therefore displaying numa node information etc there makes a lot of sense. > Would it be better to have two files, the first of which has one of > the strings: Yes. I initially had something like that in mind and have a partial implementation but such an approach gets extremely complicated and difficult to handle since you need to create multiple levels of directories in /proc//xx. It is easier to obtain the complete memory information from a single file. We already have that in /proc//maps. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc3-mm3
On Tue, 2 Aug 2005, Richard Purdie wrote:
> > + update_mmu_cache(vma, address, entry);
> > + lazy_mmu_prot_update(entry);
> > +#endif
>
> This locks the system up after the "INIT: version 2.86 booting" message.
> SysRq still responds but that's about it.
Hmmm. this should have returned the behavior to normal. Ah. Need to use
new_entry instead of entry. Try this (is there any way that I could get
access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 16:11:45.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 16:15:35.0 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, new_entry, write_access);
+ update_mmu_cache(vma, address, new_entry);
+ lazy_mmu_prot_update(new_entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-rc4-mm1] Fix smsc_ircc_init return value
Hi Andrew,
I noticed a strange return value in smsc_ircc_init in
drivers/net/irda/smsc_ircc2.c in rc4-mm1.
When reaching the line "if (ircc_fir > 0 && ircc_sir > 0)", ret is 0.
So I don't see the point of setting it to 0 in the "else" case.
>From what I see in 2.6.12 it should probably be set to -ENODEV at
the begining of the "else" case. The attached patch does this.
Note that I didn't actually see any breakage caused by this.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
Regards,
Brice
--- linux-mm/drivers/net/irda/smsc-ircc2.c.old 2005-08-01 14:39:21.0 +0200
+++ linux-mm/drivers/net/irda/smsc-ircc2.c 2005-08-01 14:51:08.0 +0200
@@ -360,6 +360,7 @@ static int __init smsc_ircc_init(void)
if (smsc_ircc_open(ircc_fir, ircc_sir, ircc_dma, ircc_irq))
ret = -ENODEV;
} else {
+ ret = -ENODEV;
/* try user provided configuration register base address */
if (ircc_cfg > 0) {
Re: [PATCH] String conversions for memory policy
Ok - its definitely getting shorter and sweeter. Good.
There are quite a few small magic numbers - is there someway to code
these out? See also my comment below, mentioning kernel/power/main.c.
Changing one of the strings should not break the code until the
corresponding magic string length numbers are changed to match.
+ p += 7;
+ if (e < p + 8 /* fixed string size */ + 4 /* max len of node
number */)
+ if (e < p + 8)
+ if (e < p + 14)
+ if (strnicmp(buffer, "default", 7) == 0)
+ if (strnicmp(buffer, "prefer=", 7) == 0) {
+ node = simple_strtoul(buffer + 7, NULL, 10);
+ } else if (strnicmp(buffer, "interleave=", 11) == 0) {
+ if (nodelist_parse(buffer + 11, nodes) ||
+ } else if (strnicmp(buffer, "bind=", 5) == 0) {
+ if (nodelist_parse(buffer+5, nodes))
And the code should not break, silently overwriting kernel stack, if
and when someone tries this on a 10,000 node system (the '4' max len of
node number). There are snprintf style routines to avoid such risks.
I'd be tempted to code for just lower case matches, not case
insensitive, which seems like gratuitous flexibility to me.
The existing numa code has a routine get_nodes(), in mm/mempolicy.c,
that obtains the nodelist from the arguments to the mbind or
set_mempolicy system call, and does a fair bit of checking on the
nodelist, in the context of the current task (the task whose mempolicy
is to be changed). Only after this checking can the resulting policy
and nodelist be applied. In the other parts of your intended changes,
where you expect to use the results of this code to convert a string
to a numa policy, where to you expect to duplicate the portion
of get_nodes() that checks the nodelist and policy, in the target
tasks context? This might involve refactoring get_nodes() into two
routines - one to obtain a nodemask_t representation of the nodelist
passed in via the set_mempolicy/mbind system calls, and the other to
perform the checking.
In your related patch, you show how to merge this display of mempolicy
into the new /proc//smap (rss size of each memory area) file.
But this smap file (or, as you renamed it, emap file) is read-only,
so far as I can tell. It enables display of information, but not
changing it. How do you propose to support changing a memory policy?
How will the other half of this patch, that converts strings to
memory policies, be used? If I knew that (you've probably said,
and I've probably forgotten - sorry) then I might then ask whether
that other half should not also be used to display memory policies,
instead of adapting smap aka emap.
There is an alternative representation of this information which
I have in mind, but cannot yet evaluate the usefulness of, due to
the above aspects that I don't understand yet. Instead of one file
(or one line in a file) having one of the following formats:
default
preferred=
bind=
interleave=
Would it be better to have two files, the first of which has one of
the strings:
default
preferred
bind
interleave
and the second of which has a nodelist, the significance of which
depends on the policy specified in the first. These files might be
called "numa_policy" and "numa_nodelist", or some such. Perhaps they
would be both read and write (display and parse), which would remove
the need for a separate read-only display in the smap/emap file.
Since I am still missing some "big picture" stuff here, I don't know
if this option is worth considering or not. But it would honor the
ideal of a single token, number or list of numbers per file.
Consider as an example the display and parsing of pm_states by the
state_show() and state_store() routines of kernel/power/main.c, for
ways to code this that separate the data (list of strings parsed
and the mapping between constants and strings) from the code logic,
and that use strlen() to avoid magic length numbers.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-rc3-mm3
On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > That number rapidly increases and so it looks like something is failing
> > and looping...
>
> Maybe we better restore the pte flags changes the way they were if
> CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
> then we need two different handle_pte_fault functions to get rid of the
> macro mess:
>
> +#ifdef CONFIG_ATOMIC_TABLE_OPS
> /*
>* If the cmpxchg fails then another processor may have done
>* the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
> } else {
> inc_page_state(cmpxchg_fail_flag_update);
> }
> +#else
> + ptep_set_access_flags(vma, address, pte, entry, write_access);
> + update_mmu_cache(vma, address, entry);
> + lazy_mmu_prot_update(entry);
> +#endif
This locks the system up after the "INIT: version 2.86 booting" message.
SysRq still responds but that's about it.
The system also feels/looks extremely sluggish after this change (more
looping?).
With your previously suggested change:
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
the system proceeds past INIT and boots normally but X still locks up...
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] NMI watch dog notify patch
Keith Owens wrote:
On Fri, 29 Jul 2005 13:55:23 -0700,
George Anzinger wrote:
This patch adds a notify to the die_nmi notify that the system
is about to be taken down. If the notify is handled with a
NOTIFY_STOP return, the system is given a new lease on life.
void die_nmi (struct pt_regs *regs, const char *msg)
{
+ if (notify_die(DIE_NMIWATCHDOG, "nmi_watchdog", regs,
+ 0, 0, SIGINT) == NOTIFY_STOP)
+ return;
+
spin_lock(_print_lock);
/*
* We are in trouble anyway, lets at least try
Minor nitpick. die_nmi() already gets a message passed in to
distinguish between different types of nmi. Pass that message to
notify_die(), on the off chance that the notified routines can use that
difference.
Excellent idea!
Also your patch adds a trailing whitespace on the call to notify_die().
Fixed.
This should do it.
-
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger
Type: Enhancement
Description:
This patch adds a notify to the die_nmi notify that the system
is about to be taken down. If the notify is handled with a
NOTIFY_STOP return, the system is given a new lease on life.
We also change the nmi watchdog to carry on if die_nmi returns.
This give debug code a chance to a) catch watchdog timeouts and
b) possibly allow the system to continue, realizing that
the time out may be due to debugger activities such as single
stepping which is usually done with "other" cpus held.
Signed-off-by: George Anzinger
nmi.c |5 -
traps.c |4
2 files changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6.13-rc/arch/i386/kernel/nmi.c
===
--- linux-2.6.13-rc.orig/arch/i386/kernel/nmi.c
+++ linux-2.6.13-rc/arch/i386/kernel/nmi.c
@@ -495,8 +495,11 @@ void nmi_watchdog_tick (struct pt_regs *
*/
alert_counter[cpu]++;
if (alert_counter[cpu] == 5*nmi_hz)
+ /*
+* die_nmi will return ONLY if NOTIFY_STOP happens..
+*/
die_nmi(regs, "NMI Watchdog detected LOCKUP");
- } else {
+
last_irq_sums[cpu] = sum;
alert_counter[cpu] = 0;
}
Index: linux-2.6.13-rc/arch/i386/kernel/traps.c
===
--- linux-2.6.13-rc.orig/arch/i386/kernel/traps.c
+++ linux-2.6.13-rc/arch/i386/kernel/traps.c
@@ -555,6 +555,10 @@ static DEFINE_SPINLOCK(nmi_print_lock);
void die_nmi (struct pt_regs *regs, const char *msg)
{
+ if (notify_die(DIE_NMIWATCHDOG, msg, regs, 0, 0, SIGINT) ==
+ NOTIFY_STOP)
+ return;
+
spin_lock(_print_lock);
/*
* We are in trouble anyway, lets at least try
2.6.13-rc4-git4: bluetooth oops on pcmcia shutdown
The attached bluetooth oops can be reliably reproduced on my x86_64
laptop. It happens when hciattach is still running while a sequence of
"cardctl eject" and then "killproc /sbin/cardmgr" is executed.
Though this seems to point to preempt I could manage to cause similar
oopses on non-preemptible kernels a while ago.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Unable to handle kernel NULL pointer dereference at 0014 RIP:
{uart_flush_buffer+43}
PGD 0
Oops: 0002 [1] PREEMPT
CPU 0
Modules linked in: hci_usb serial_cs pcmcia yenta_socket rsrc_nonstatic
pcmcia_core ehci_hcd uhci_hcd parport_pc parport snd_via82xx_modem snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss hfc_usb ipaq usbhid pl2303
usbserial usb_storage snd_via82xx gameport sd_mod snd_ac97_codec snd_pcm
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device hisax isdn
nls_iso8859_15 nls_cp850 ip_conntrack_ftp ipt_state ip_conntrack ipt_ULOG
iptable_filter ipt_REJECT ip_tables nfsd exportfs lockd sunrpc autofs4 cifs sbp2
Pid: 2995, comm: hciattach Not tainted 2.6.13-rc4-git4-gringo
RIP: 0010:[] {uart_flush_buffer+43}
RSP: 0018:81001c0b9b68 EFLAGS: 00010013
RAX: RBX: 810002208c80 RCX: 81001e6d3018
RDX: RSI: 81001c0b9b58 RDI: 0001
RBP: 81001e6d3000 R08: 81003f01ce98 R09: 0001
R10: R11: 0246 R12: 81003d76ba80
R13: 8052e6c0 R14: R15:
FS: 2af3edb0() GS:8061c800() knlGS:556d16b0
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0014 CR3: 1b1a2000 CR4: 06e0
Process hciattach (pid: 2995, threadinfo 81001c0b8000, task
81001f94f4a0)
Stack: 0292 81003db82200 81001e6d3000 803567ac
81003db82200 81002614ac00 803567e4
8052e6c0 80356931
Call Trace:{hci_uart_flush+92}
{hci_uart_close+20}
{hci_uart_tty_close+49}
{release_dev+1805}
{free_hot_cold_page+239}
{free_pgd_range+1078}
{_atomic_dec_and_lock+38} {dput+35}
{tty_release+17} {__fput+178}
{filp_close+110}
{put_files_struct+115}
{do_exit+522} {__dequeue_signal+501}
{do_group_exit+269}
{get_signal_to_deliver+1515}
{do_signal+159} {thread_return+0}
{thread_return+220}
{lock_timer_base+49}
{del_timer+104}
{schedule_timeout+156}
{process_timeout+0}
{sysret_signal+28}
{ptregscall_common+103}
Code: c7 40 14 00 00 00 00 c7 40 10 00 00 00 00 ff 34 24 9d bf 01
RIP {uart_flush_buffer+43} RSP
CR2: 0014
<1>Fixing recursive fault but reboot is needed!
scheduling while atomic: hciattach/0x0001/2995
Call Trace:{schedule+122} {do_exit+246}
{do_unblank_screen+21}
{do_page_fault+1807}
{error_exit+0} {uart_flush_buffer+43}
{uart_flush_buffer+39}
{hci_uart_flush+92}
{hci_uart_close+20}
{hci_uart_tty_close+49}
{release_dev+1805}
{free_hot_cold_page+239}
{free_pgd_range+1078}
{_atomic_dec_and_lock+38}
{dput+35} {tty_release+17}
{__fput+178} {filp_close+110}
{put_files_struct+115} {do_exit+522}
{__dequeue_signal+501}
{do_group_exit+269}
{get_signal_to_deliver+1515}
{do_signal+159}
{thread_return+0} {thread_return+220}
{lock_timer_base+49} {del_timer+104}
{schedule_timeout+156}
{process_timeout+0}
{sysret_signal+28}
{ptregscall_common+103}
[PATCH] net/sunrpc: fix time conversion error
On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote:
> Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong:
>
> skb->stamp.tv_usec = xtime.tv_nsec * 1000;
>
> To convert nsec to usec, one should divide instead of multiplying:
>
> skb->stamp.tv_usec = xtime.tv_nsec / 1000;
>
> The same bug could be present in the latest kernels, although I haven't
> checked. This bug makes svc_udp_recvfrom() timestamps incorrect.
Agreed, the conversion is wrong. I think the code is buggy period, as it
accesses xtime without grabbing the xtime_lock first. Following patch
should fix both issues.
Description: This function incorrectly multiplies a nanosecond value by
1000, instead of dividing by 1000, to obtain a corresponding microsecond
value. Fix the math. Also, the function incorrectly accesses xtime
without using the xtime_lock. Fixed as well. Patch is compile-tested.
Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
---
svcsock.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
--- 2.6.13-rc4/net/sunrpc/svcsock.c 2005-07-29 14:11:50.0 -0700
+++ 2.6.13-rc4-dev/net/sunrpc/svcsock.c 2005-08-01 15:51:11.0 -0700
@@ -559,6 +559,7 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
struct svc_serv *serv = svsk->sk_server;
struct sk_buff *skb;
int err, len;
+unsigned long seq;
if (test_and_clear_bit(SK_CHNGBUF, >sk_flags))
/* udp sockets need large rcvbuf as all pending
@@ -585,8 +586,11 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
dprintk("svc: recvfrom returned error %d\n", -err);
}
if (skb->stamp.tv_sec == 0) {
- skb->stamp.tv_sec = xtime.tv_sec;
- skb->stamp.tv_usec = xtime.tv_nsec * 1000;
+ do {
+ seq = read_seqbegin(_lock);
+ skb->stamp.tv_sec = xtime.tv_sec;
+ skb->stamp.tv_usec = xtime.tv_nsec / 1000;
+ } while (read_seqretry(_lock, seq));
/* Don't enable netstamp, sunrpc doesn't
need that much accuracy */
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: i2c-mpc build fix.
Let's be careful and not remove them twice. I know Andrew's already
sent a patch to linus to remove the duplication.
- kumar
On Aug 1, 2005, at 3:13 PM, Dave Jones wrote:
Somehow, these functions got included twice.
drivers/i2c/busses/i2c-mpc.c:386: error: redefinition of
'fsl_i2c_probe'
drivers/i2c/busses/i2c-mpc.c:292: error: previous definition of
'fsl_i2c_probe' was here
drivers/i2c/busses/i2c-mpc.c:444: error: redefinition of
'fsl_i2c_remove'
drivers/i2c/busses/i2c-mpc.c:350: error: previous definition of
'fsl_i2c_remove' was here
drivers/i2c/busses/i2c-mpc.c:459: error: redefinition of
'fsl_i2c_driver'
drivers/i2c/busses/i2c-mpc.c:365: error: previous definition of
'fsl_i2c_driver' was here
drivers/i2c/busses/i2c-mpc.c:467: error: redefinition of
'fsl_i2c_init'
drivers/i2c/busses/i2c-mpc.c:373: error: previous definition of
'fsl_i2c_init' was here
drivers/i2c/busses/i2c-mpc.c:472: error: redefinition of
'fsl_i2c_exit'
drivers/i2c/busses/i2c-mpc.c:378: error: previous definition of
'fsl_i2c_exit' was here
drivers/i2c/busses/i2c-mpc.c:476: error: redefinition of '__inittest'
drivers/i2c/busses/i2c-mpc.c:382: error: previous definition of
'__inittest' was here
drivers/i2c/busses/i2c-mpc.c:476: error: redefinition of 'init_module'
drivers/i2c/busses/i2c-mpc.c:382: error: previous definition of
'init_module' was here
drivers/i2c/busses/i2c-mpc.c:477: error: redefinition of '__exittest'
drivers/i2c/busses/i2c-mpc.c:383: error: previous definition of
'__exittest' was here
drivers/i2c/busses/i2c-mpc.c:477: error: redefinition of
'cleanup_module'
drivers/i2c/busses/i2c-mpc.c:383: error: previous definition of
'cleanup_module' was here
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6.12/drivers/i2c/busses/i2c-mpc.c~2005-08-01
16:07:47.0 -0400
+++ linux-2.6.12/drivers/i2c/busses/i2c-mpc.c2005-08-01
16:10:31.0 -0400
@@ -382,100 +382,6 @@ static void __exit fsl_i2c_exit(void)
module_init(fsl_i2c_init);
module_exit(fsl_i2c_exit);
-static int fsl_i2c_probe(struct device *device)
-{
-int result = 0;
-struct mpc_i2c *i2c;
-struct platform_device *pdev = to_platform_device(device);
-struct fsl_i2c_platform_data *pdata;
-struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM,
0);
-
-pdata = (struct fsl_i2c_platform_data *)
pdev->dev.platform_data;
-
-if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))) {
-return -ENOMEM;
-}
-memset(i2c, 0, sizeof(*i2c));
-
-i2c->irq = platform_get_irq(pdev, 0);
-i2c->flags = pdata->device_flags;
-init_waitqueue_head(>queue);
-
-i2c->base = ioremap((phys_addr_t)r->start, MPC_I2C_REGION);
-
-if (!i2c->base) {
-printk(KERN_ERR "i2c-mpc - failed to map controller\n");
-result = -ENOMEM;
-goto fail_map;
-}
-
-if (i2c->irq != 0)
-if ((result = request_irq(i2c->irq, mpc_i2c_isr,
- SA_SHIRQ, "i2c-mpc", i2c)) <
0) {
-printk(KERN_ERR
- "i2c-mpc - failed to attach
interrupt\n");
-goto fail_irq;
-}
-
-mpc_i2c_setclock(i2c);
-dev_set_drvdata(device, i2c);
-
-i2c->adap = mpc_ops;
-i2c_set_adapdata(>adap, i2c);
-i2c->adap.dev.parent = >dev;
-if ((result = i2c_add_adapter(>adap)) < 0) {
-printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
-goto fail_add;
-}
-
-return result;
-
- fail_add:
-if (i2c->irq != 0)
-free_irq(i2c->irq, NULL);
- fail_irq:
-iounmap(i2c->base);
- fail_map:
-kfree(i2c);
-return result;
-};
-
-static int fsl_i2c_remove(struct device *device)
-{
-struct mpc_i2c *i2c = dev_get_drvdata(device);
-
-i2c_del_adapter(>adap);
-dev_set_drvdata(device, NULL);
-
-if (i2c->irq != 0)
-free_irq(i2c->irq, i2c);
-
-iounmap(i2c->base);
-kfree(i2c);
-return 0;
-};
-
-/* Structure for a device driver */
-static struct device_driver fsl_i2c_driver = {
-.name = "fsl-i2c",
-.bus = _bus_type,
-.probe = fsl_i2c_probe,
-.remove = fsl_i2c_remove,
-};
-
-static int __init fsl_i2c_init(void)
-{
-return driver_register(_i2c_driver);
-}
-
-static void __exit fsl_i2c_exit(void)
-{
-driver_unregister(_i2c_driver);
-}
-
-module_init(fsl_i2c_init);
-module_exit(fsl_i2c_exit);
-
MODULE_AUTHOR("Adrian Cox <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION
("I2C-Bus adapter for MPC107 bridge and MPC824x/85xx/52xx
processors");
-
To unsubscribe from this list: send the line "unsubscribe linux-
kernel"
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] remove sys_set_zone_reclaim()
On Mon, 1 Aug 2005, Andrew Morton wrote: > (I'm still not sure what happened to the idea of adding a call to "clear > out this node+zone's pagecache now" rather than "set this noed+zone's > policy") Yes, We need the clear this zones page cache functionality. I am not sure what the Martin's reclaiming code brings us. Since these patches do not allow the clearing of the page cache, we will still have off node allocations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 6/8] x86_64:Dont use Lowest Priority when using physical mode.
Delivery mode should be APIC_DM_FIXED when using physical mode.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/genapic_flat.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_flat.c
===
--- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/genapic_flat.c
+++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_flat.c
@@ -175,9 +175,9 @@ static unsigned int physflat_cpu_mask_to
struct genapic apic_physflat = {
.name = "physical flat",
- .int_delivery_mode = dest_LowestPrio,
+ .int_delivery_mode = dest_Fixed,
.int_dest_mode = (APIC_DEST_PHYSICAL != 0),
- .int_delivery_dest = APIC_DEST_PHYSICAL | APIC_DM_LOWEST,
+ .int_delivery_dest = APIC_DEST_PHYSICAL | APIC_DM_FIXED,
.target_cpus = physflat_target_cpus,
.apic_id_registered = flat_apic_id_registered,
.init_apic_ldr = flat_init_apic_ldr,/*not needed, but shouldn't hurt*/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/8] x86_64: Reintroduce clustered_apic_check() for x86_64.
On Mon, Aug 01, 2005 at 01:20:18PM -0700, Ashok Raj wrote: > Auto selection of bigsmp patch removed this check from a shared common file > in arch/i386/kernel/acpi/boot.c. We still need to call this to determine > the right genapic code for x86_64. > Thanks venki, missed the check for lapic and smp_found_config before the call. Resending patch. -- Cheers, Ashok Raj - Open Source Technology Center Auto selection of bigsmp patch removed this check from a shared common file in arch/i386/kernel/acpi/boot.c. We still need to call this to determine the right genapic code for x86_64. Signed-off-by: Ashok Raj <[EMAIL PROTECTED]> --- arch/x86_64/kernel/setup.c |2 ++ 1 files changed, 2 insertions(+) Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/setup.c === --- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/setup.c +++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/setup.c @@ -663,6 +663,8 @@ void __init setup_arch(char **cmdline_p) * Read APIC and some other early information from ACPI tables. */ acpi_boot_init(); + if (acpi_lapic && smp_found_config) + clustered_apic_check(); #endif #ifdef CONFIG_X86_LOCAL_APIC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc3-mm3
On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> Could you get me some more information about the hang? A stacktrace would
> be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
> Well the device is able to run X so I guess that a slow kernel compile
> would work. At least the embedded device that I used to work on was
> capable of doing that (but then we had Debian on that thing which made
> doing stuff like that very easy).
I agree, it would probably do a slow compile. I have no compiler or
development tools on it though and only slow vfat disks other than the
internal flash. There are plenty of options to get such things working
but it will take me a while to setup.
Hopefully the memcpy clue will mean something?
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
* Lee Revell <[EMAIL PROTECTED]> wrote: > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote: > > ok - i've uploaded the -52-04 patch, does that fix it for you? > > Has anyone found their PS2 keyboard rather sluggish with this kernel? > I'm not sure whether it's an -RT problem, I'll have to try rc4. hm, i've got no other reports about that. 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/
[patch 8/8] x86_64: Choose physflat for AMD systems only when >8 CPUS.
It is not required to choose the physflat mode when CPU hotplug is enabled
and CPUs <=8 case. Use of genapic_flat with the mask version is capable of
doing the same, instead of doing the send_IPI_mask_sequence() where its a
unicast.
This is another change that Andi introduced with the physflat mode.
Andi: Do you think this is acceptable?
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/genapic.c |9 +
1 files changed, 1 insertion(+), 8 deletions(-)
Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic.c
===
--- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/genapic.c
+++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic.c
@@ -69,15 +69,8 @@ void __init clustered_apic_check(void)
}
/* Don't use clustered mode on AMD platforms. */
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (num_cpus > 8)) {
genapic = _physflat;
- /* In the CPU hotplug case we cannot use broadcast mode
- because that opens a race when a CPU is removed.
- Stay at physflat mode in this case. - AK */
-#ifdef CONFIG_HOTPLUG_CPU
- if (num_cpus <= 8)
- genapic = _flat;
-#endif
goto print;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 7/8] x86_64:Use common functions in cluster and physflat mode
Newly introduced physflat_* shares way too much with cluster with only
a very differences. So we introduce some common functions in that can be
reused in both cases.
In addition the following are also fixed.
- Use of non-existent CONFIG_CPU_HOTPLUG option renamed to actual one in use.
- Removed comment that ACPI would provide a way to select this dynamically
since ACPI_CONFIG_HOTPLUG_CPU already exists that indicates platform support
for hotplug via ACPI. In addition CONFIG_HOTPLUG_CPU only indicates logical
offline/online which is even used by Suspend/Resume folks where the same
support (for no-broadcast) is required.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/genapic.c | 52 +
arch/x86_64/kernel/genapic_cluster.c | 55 +++
arch/x86_64/kernel/genapic_flat.c| 49 +++
include/asm-x86_64/ipi.h |5 +++
4 files changed, 61 insertions(+), 100 deletions(-)
Index: linux-2.6.13-rc4-mm1/include/asm-x86_64/ipi.h
===
--- linux-2.6.13-rc4-mm1.orig/include/asm-x86_64/ipi.h
+++ linux-2.6.13-rc4-mm1/include/asm-x86_64/ipi.h
@@ -107,4 +107,9 @@ static inline void send_IPI_mask_sequenc
local_irq_restore(flags);
}
+extern cpumask_t generic_target_cpus(void);
+extern void generic_send_IPI_mask(cpumask_t mask, int vector);
+extern void generic_send_IPI_allbutself(int vector);
+extern void generic_send_IPI_all(int vector);
+extern unsigned int generic_cpu_mask_to_apicid(cpumask_t cpumask);
#endif /* __ASM_IPI_H */
Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_flat.c
===
--- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/genapic_flat.c
+++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_flat.c
@@ -134,56 +134,17 @@ struct genapic apic_flat = {
* overflows, so use physical mode.
*/
-static cpumask_t physflat_target_cpus(void)
-{
- return cpumask_of_cpu(0);
-}
-
-static void physflat_send_IPI_mask(cpumask_t cpumask, int vector)
-{
- send_IPI_mask_sequence(cpumask, vector);
-}
-
-static void physflat_send_IPI_allbutself(int vector)
-{
- cpumask_t allbutme = cpu_online_map;
- int me = get_cpu();
- cpu_clear(me, allbutme);
- physflat_send_IPI_mask(allbutme, vector);
- put_cpu();
-}
-
-static void physflat_send_IPI_all(int vector)
-{
- physflat_send_IPI_mask(cpu_online_map, vector);
-}
-
-static unsigned int physflat_cpu_mask_to_apicid(cpumask_t cpumask)
-{
- int cpu;
-
- /*
-* We're using fixed IRQ delivery, can only return one phys APIC ID.
-* May as well be the first.
-*/
- cpu = first_cpu(cpumask);
- if ((unsigned)cpu < NR_CPUS)
- return x86_cpu_to_apicid[cpu];
- else
- return BAD_APICID;
-}
-
struct genapic apic_physflat = {
.name = "physical flat",
.int_delivery_mode = dest_Fixed,
.int_dest_mode = (APIC_DEST_PHYSICAL != 0),
.int_delivery_dest = APIC_DEST_PHYSICAL | APIC_DM_FIXED,
- .target_cpus = physflat_target_cpus,
+ .target_cpus = generic_target_cpus,
.apic_id_registered = flat_apic_id_registered,
.init_apic_ldr = flat_init_apic_ldr,/*not needed, but shouldn't hurt*/
- .send_IPI_all = physflat_send_IPI_all,
- .send_IPI_allbutself = physflat_send_IPI_allbutself,
- .send_IPI_mask = physflat_send_IPI_mask,
- .cpu_mask_to_apicid = physflat_cpu_mask_to_apicid,
+ .send_IPI_all = generic_send_IPI_all,
+ .send_IPI_allbutself = generic_send_IPI_allbutself,
+ .send_IPI_mask = generic_send_IPI_mask,
+ .cpu_mask_to_apicid = generic_cpu_mask_to_apicid,
.phys_pkg_id = phys_pkg_id,
};
Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_cluster.c
===
--- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/genapic_cluster.c
+++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_cluster.c
@@ -57,56 +57,11 @@ static void cluster_init_apic_ldr(void)
apic_write_around(APIC_LDR, val);
}
-/* Start with all IRQs pointing to boot CPU. IRQ balancing will shift them. */
-
-static cpumask_t cluster_target_cpus(void)
-{
- return cpumask_of_cpu(0);
-}
-
-static void cluster_send_IPI_mask(cpumask_t mask, int vector)
-{
- send_IPI_mask_sequence(mask, vector);
-}
-
-static void cluster_send_IPI_allbutself(int vector)
-{
- cpumask_t mask = cpu_online_map;
- int me = get_cpu(); /* Ensure we are not preempted when we clear */
-
- cpu_clear(me, mask);
-
- if (!cpus_empty(mask))
- cluster_send_IPI_mask(mask, vector);
-
- put_cpu();
-}
-
-static void cluster_send_IPI_all(int vector)
-{
-
Re: [patch] Support powering sharp zaurus sl-5500 LCD up and down
On Wed, July 27, 2005 5:06 am, Richard Purdie said: > On Wed, 2005-07-27 at 11:53 +0200, Pavel Machek wrote: >> +/* read comadj */ >> +#ifdef CONFIG_MACH_POODLE >> +comadj = 118; >> +#else >> +comadj = 128; >> +#endif > > Can you go back to the Sharp source and confirm that these values should > be hardcoded in both the poodle and collie cases please? I know the > sharpsl_param code can provide them but I can't remember exactly which > models use which fields. I want to make sure this isn't a quick hack > John made before sharpsl_param was written :). No, those values were from the original sharp code... at some point I was going to investigate what values the sharpsl param stuff returned and see if those worked. If the sharpsl stuff works, then by all means use it. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > Ingo, > > > > What's with the "BUG: possible soft lockup detected on CPU..."? I'm > > getting a bunch of them from the IDE interrupt. It's not locking up, > > but it does things that probably do take some time. Is this really > > necessary? Here's an example dump: > > doh - it's Daniel not Cc:-ing lkml when sending me patches, so people > dont know what's going on ... > > here's the patch below. Could you try to revert it? You guys want me to always CC in the future? 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: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
> * Lee Revell <[EMAIL PROTECTED]> wrote: > > > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote: > > > ok - i've uploaded the -52-04 patch, does that fix it for you? > > > > Has anyone found their PS2 keyboard rather sluggish with this kernel? > > I'm not sure whether it's an -RT problem, I'll have to try rc4. There was one irq-redirection change done recently, i've undone it in -52-09, does it work any better? 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: Finding out which SCSI drive is mapped to which device
Anton Erasmus wrote: On Wed, 27 Jul 2005 16:58:20 -, Chiefy <[EMAIL PROTECTED]> wrote: 26 Jul 2005 20:04 UTC, Anton Erasmus typed: How can I find out which SCSI ID is mapped to which device ? Have a look at sg3_utils http://sg.torque.net/sg/index.html Thanks, These utilities seem to be for SCSI devices which are not disks, tapes or CD-ROMs. All my SCSI devices are disks. I only need to find out which SCSI ID maps to sda, and which ID to sdb etc. For human information "cat /proc/scsi/scsi" might do -- bill davidsen SBC/Prodigy Yorktown Heights NY data center http://newsgroups.news.prodigy.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> That number rapidly increases and so it looks like something is failing
> and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two different handle_pte_fault functions to get rid of the
macro mess:
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 15:08:31.0 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, entry, write_access);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
Index: linux-2.6.13-rc4-mm1/mm/memory.o
===
Binary files linux-2.6.13-rc4-mm1.orig/mm/memory.o 2005-08-01
15:03:10.0 -0700 and linux-2.6.13-rc4-mm1/mm/memory.o2005-08-01
15:09:50.0 -0700 differ
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Support powering sharp zaurus sl-5500 LCD up and down
Hi! > >> + /* read comadj */ > >> +#ifdef CONFIG_MACH_POODLE > >> + comadj = 118; > >> +#else > >> + comadj = 128; > >> +#endif > > > > Can you go back to the Sharp source and confirm that these values should > > be hardcoded in both the poodle and collie cases please? I know the > > sharpsl_param code can provide them but I can't remember exactly which > > models use which fields. I want to make sure this isn't a quick hack > > John made before sharpsl_param was written :). > > No, those values were from the original sharp code... at some point I was > going to investigate what values the sharpsl param stuff returned and see > if those worked. If the sharpsl stuff works, then by all means use it. I added code to read it from sharpsl, if it is not there, I use defaults above. It seems to work on my collie. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 rc4-mm1] drivers/char/isicom.c old api rewritten
Hello. Could you send me critics and bugs? Could somebody test it (but NOT now)? Thanks. drivers/char/isicom.c | 1610 - include/linux/isicom.h |8 2 files changed, 817 insertions(+), 801 deletions(-) Here it is (about 65 KiB): http://www.fi.muni.cz/~xslaby/lnx/isi.txt -- Jiri Slaby www.fi.muni.cz/~xslaby ~\-/~ [EMAIL PROTECTED] ~\-/~ 241B347EC88228DE51EE A49C4A73A25004CB2A10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> cmpxchg_fail_flag_update 1359210189
>
> That number rapidly increases and so it looks like something is failing
> and looping...
That looks like some trouble with the MMU. The time between pte read and
write has been shortened through the page fault scalability patches.
Does this patch fix it?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.0
-0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c2005-08-01 15:02:19.0 -0700
@@ -2105,6 +2105,7 @@
lazy_mmu_prot_update(entry);
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
pte_unmap(pte);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-rc3-mm3
On Mon, 2005-08-01 at 14:40 -0700, Christoph Lameter wrote: > Can you run kgdb on it to figure out what is going on? Maybe, depending on how easily kgdb cross compiles and how quickly I can learn to use it... > There are some variables in /proc/vmstat that may help: > > spurious_page_faults 0 > cmpxchg_fail_flag_update 0 > cmpxchg_fail_flag_reuse 0 > cmpxchg_fail_anon_read 0 > cmpxchg_fail_anon_write 0 In my case: spurious_page_faults 0 cmpxchg_fail_flag_update 1359210189 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 That number rapidly increases and so it looks like something is failing and looping... Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] MM, NUMA : sys_set_mempolicy() doesnt check if mode < 0
MM, NUMA : sys_set_mempolicy() doesnt check if mode < 0
A kernel BUG() is triggered by a call to set_mempolicy() with a negative first
argument.
This is because the mode is declared as an int, and the validity check doesnt
check < 0 values.
Alternatively, mode could be declared as unsigned int or unsigned long.
Thank you
Eric
-
Test program for x86_64:
-
#include
#include
#include
#include
#define __NR_set_mempolicy 238
#define __sys_set_mempolicy(mode, nmask, maxnode) _syscall3(int, set_mempolicy,
int, mode, unsigned long *, nmask, unsigned long, maxnode)
static __sys_set_mempolicy(mode, nmask, maxnode)
unsigned long nodes = 3;
int main()
{
int ret = set_mempolicy(-6, , 2);
printf("result=%d errno=%d\n", ret, errno);
return 0;
}
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- linux-2.6.13-rc4/mm/mempolicy.c 2005-07-29 00:44:44.0 +0200
+++ linux-2.6.13-rc4-ed/mm/mempolicy.c 2005-08-01 23:52:43.0 +0200
@@ -443,7 +443,7 @@
struct mempolicy *new;
DECLARE_BITMAP(nodes, MAX_NUMNODES);
- if (mode > MPOL_MAX)
+ if ((unsigned int)mode > MPOL_MAX)
return -EINVAL;
err = get_nodes(nodes, nmask, maxnode, mode);
if (err)
Re: [patch 2.6.13-rc4] fix get_user_pages bug
On Mon, 1 Aug 2005, Linus Torvalds wrote: > > Of course, if VM_MAYWRITE is not set, you could just convert it silently > to a MAP_PRIVATE at the VM level (that's literally what we used to do, > back when we didn't support writable shared mappings at all, all those > years ago), so at least now the COW behaviour would match the vma_flags. Heh. I just checked. We still do exactly that: if (!(file->f_mode & FMODE_WRITE)) vm_flags &= ~(VM_MAYWRITE | VM_SHARED); some code never dies ;) However, we still set the VM_MAYSHARE bit, and thats' the one that mm/rmap.c checks for some reason. I don't see quite why - VM_MAYSHARE doesn't actually ever do anything else than make sure that we try to allocate a mremap() mapping in a cache-coherent space, I think (ie it's a total no-op on any sane architecture, and as far as rmap is concerned on all of them). 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] 2.6.13-rc4-git3: snd_intel8x0: handle irq_request failure on resume
On Monday, 1 of August 2005 14:15, Takashi Iwai wrote: > Hi Rafael, > > At Sun, 31 Jul 2005 12:43:21 +0200, > Rafael J. Wysocki wrote: > > > > Hi, > > > > This patch adds the handling of irq_request() failures during resume to > > the snd_intel8x0 driver. > > > > Please consider for applying, > > Rafael > > Not directly with the patch but I have a question about your first > patch. I found you changed from the second argument of > snd_intel8x0_chip_init() from 0 to 1. Is it intentional? Yes. My box hangs solid while executing snd_intel8x0_chip_init(0) after requesting the IRQ in _resume(). Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: that sk98lin suspend/resume patch
On Monday, 1 of August 2005 01:39, Kasper Sandberg wrote: > hello, i run 2.6.13-rc4-git2, and i am experiencing problems with > sk98lin, suddenly it just stops working, and i need to reboot to get > network up again, does this fix it? Unfortunately, it doesn't. It is only relevant if you suspend/resume your box. You can try the skge driver however. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.13-rc4: yenta_socket and swsusp
[now sending to lkml as sending to the pcmcia list without being subscribed seems to go to /dev/null] I do have problems with yenta_socket on my x86_64 laptop which appear when using swsusp (suspend to disk mode). 1. When I do not access any pcmcia device from initrd during boot I have to terminate cardmgr, otherwise suspend to disk hangs. For 2.6.11 it was sufficient to call 'cardctl eject'. 2. When I have to access a pcmcia device from initrd during boot (there's required crypto keys stored on a pcmcia flash disk) and I do not unload yenta_socket prior to suspend the laptop spontaneously reboots or just hangs on resume when swsusp has finished loading. 3. If I do not unload the pcmcia modules prior to suspend with rmmod -w unloading yenta_socket fails. 4. If I do unload the pcmcia modules in a loop with rmmod -w but no delay between unloading the modules it happens from time to time that yenta_socket unloading hangs with a use count of 2 when there is definitely no more user of the module. A delay of 50 msec after unload of each pcmcia module seems to cure this. 5. If I insert yenta_socket within the first few seconds after resume the laptop spontaneously reboots. A 5 second delay seems to cure this most of the time. BTW: Did I read this right? PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) scheduled for removal in november *this* year? So a 3 month warning for everybody is sufficient? Probably only one kernel release? So much for sufficient backwards compatability. Especially as the tools stated to be required aren't even released as of today (hint: module-init-tools 3.2). Grrr. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] i386: fix incorrect TSS entry for LDT
noticed by Chuck Ebbert: the .ldt entry of the TSS was set up
incorrectly. It never mattered since this was a leftover from
old times, so remove it.
From: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was sent by Ingo Molnar on:
- 1 Jul 2005
--- linux.orig/include/asm-i386/processor.h
+++ linux/include/asm-i386/processor.h
@@ -474,7 +474,6 @@ struct thread_struct {
.esp0 = sizeof(init_stack) + (long)_stack, \
.ss0= __KERNEL_DS, \
.ss1= __KERNEL_CS, \
- .ldt= GDT_ENTRY_LDT,\
.io_bitmap_base = INVALID_IO_BITMAP_OFFSET, \
.io_bitmap = { [ 0 ... IO_BITMAP_LONGS] = ~0 },\
}
k
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.13-rc4] fix get_user_pages bug
On Mon, 1 Aug 2005, Hugh Dickins wrote: > > > > We have always just done a COW if it's read-only - even if it's shared. > > > > The point being that if a process mapped did a read-only mapping, and a > > tracer wants to modify memory, the tracer is always allowed to do so, but > > it's _not_ going to write anything back to the filesystem. Writing > > something back to an executable just because the user happened to mmap it > > with MAP_SHARED (but read-only) _and_ the user had the right to write to > > that fd is _not_ ok. > > I'll need to think that through, but not right now. It's a surprise > to me, and it's likely to surprise the current kernel too. Well, even if you did the write-back if VM_MAYWRITE is set, you'd still have the case of having MAP_SHARED, PROT_READ _without_ VM_MAYWRITE being set, and I'd expect that to actually be the common one (since you'd normally use O_RDONLY to open a fd that you only want to map for reading). And as mentioned, MAP_SHARED+PROT_READ does actually happen in real life. Just do a google search on "MAP_SHARED PROT_READ -PROT_WRITE" and you'll get tons of hits. For good reason too - because MAP_PRIVATE isn't actually coherent on several old UNIXes. So you'd still have to convert such a case to a COW mapping, so it's not like you can avoid it. Of course, if VM_MAYWRITE is not set, you could just convert it silently to a MAP_PRIVATE at the VM level (that's literally what we used to do, back when we didn't support writable shared mappings at all, all those years ago), so at least now the COW behaviour would match the vma_flags. > I'd prefer to say that if the executable was mapped shared from a writable fd, > then the tracer will write back to it; but you're clearly against that. Absolutely. I can just see somebody mapping an executable MAP_SHARED and PROT_READ, and something as simple as doing a breakpoint while debugging causing system-wide trouble. I really don't think that's acceptable. And I'm not making it up - add PROT_EXEC to the google search around, and watch it being done exactly that way. Several of the hits mention shared libraries too. I strongly suspect that almost all cases will be opened with O_RDONLY, but still.. 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: revert yenta free_irq on suspend
On Monday, 1 of August 2005 22:34, Hugh Dickins wrote: > On Sun, 31 Jul 2005, Rafael J. Wysocki wrote: > > On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote: > > > > > > Linus has apparently dropped that patch for yenta, but in case it is > > > reintroduced in the future you will probably need a patch to make the > > > network > > > driver cooperate. I'll try to prepare one tomorrow, if I can, but I have > > > no hardware > > > to test it. > > > > The patch follows. It compiles and should work, though I haven't tested it. > > Thanks for making the effort, Rafael, > but I'm afraid your patch does not solve it. > > Prior to -rc4, or in current -git which has the yenta patch reverted, > my laptop manages APM resume from RAM with the following 8 messages > (I won't complain that it could list even more permutations!) > > PCI: Found IRQ 11 for device :00:1f.1 > PCI: Sharing IRQ 11 with :02:00.0 > PCI: Found IRQ 11 for device :02:00.0 > PCI: Sharing IRQ 11 with :00:1f.1 > PCI: Found IRQ 11 for device :02:01.0 > PCI: Sharing IRQ 11 with :02:01.1 > PCI: Found IRQ 11 for device :02:01.1 > PCI: Sharing IRQ 11 with :02:01.0 > > Unpatched -rc4 locks up on resume, showing none of those messages. > -rc4 with your drivers/net/3c59x.c patch locks up on resume, > after showing just the first four of those messages. Thanks for testing. The results you observe mean that the problem is in fact more complicated than I thought. It seems to make up a good test case but I wouldn't like to bother you any more. :-) > Whatever, I very much share the position Linus has expressed so > forcefully: it's foolish suddenly to demand changes in an indeterminate > number of drivers (surely yenta and 3c59x aren't the end of it?), > especially in the final days leading up to a release. Fully agreed. > I surely would not have asked him to revert the yenta patch, nor would > he have done so (thank you, Linus), if my machine were the only problem. > It's very easy for me to carry my own patches to get working, but we > fear the trouble seen here gives a foretaste of others' trouble if > the changes were to remain in the release. Indeed. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Time conversion error in linux-2.6.11.10/net/sunrpoc/svcsock.c
Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong: skb->stamp.tv_usec = xtime.tv_nsec * 1000; To convert nsec to usec, one should divide instead of multiplying: skb->stamp.tv_usec = xtime.tv_nsec / 1000; The same bug could be present in the latest kernels, although I haven't checked. This bug makes svc_udp_recvfrom() timestamps incorrect. Sincerely, Josip - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/8] x86_64: Reintroduce clustered_apic_check() for x86_64.
Auto selection of bigsmp patch removed this check from a shared common file in arch/i386/kernel/acpi/boot.c. We still need to call this to determine the right genapic code for x86_64. Signed-off-by: Ashok Raj <[EMAIL PROTECTED]> --- arch/x86_64/kernel/setup.c |1 + 1 files changed, 1 insertion(+) Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/setup.c === --- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/setup.c +++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/setup.c @@ -663,6 +663,7 @@ void __init setup_arch(char **cmdline_p) * Read APIC and some other early information from ACPI tables. */ acpi_boot_init(); + clustered_apic_check(); #endif #ifdef CONFIG_X86_LOCAL_APIC -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11.3 2.6.11.6 2.6.12 2.6.13rc3 +rc4 Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424 pppd problem ?
Hi i did run the systen half an hour without ppp . there was no badness in the logs in the time. after after starting the internet without the firewall the messages about the badness were after a few minutes in the log. so the bug is not in the iptables code. it might be in the pppd driver . I use pppoe (ADSL) using the userspace pppoe driver. On my old Installation I used the kernel space driver , were the badness also also was. my ethernet driver is 8139too I use pppd 2.4.3 see also http://bugzilla.kernel.org/show_bug.cgi?id=4438 - Nachricht von [EMAIL PROTECTED] - Datum: Mon, 01 Aug 2005 13:06:02 +0200 Von: Tobias <[EMAIL PROTECTED]> Antwort an: Tobias <[EMAIL PROTECTED]> Betreff: Re: 2.6.11.3 2.6.11.6 2.6.12 2.6.13rc3 +rc4 Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424 An: linux-kernel@vger.kernel.org HI I updated to rc4 It still happens i atached my bootlog . and config.gz the output of /scripts/ver_linux: ## If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux fujitsu.ti 2.6.13-rc4 #1 Mon Aug 1 11:19:36 CEST 2005 i686 pentium3 i386 GNU/Linux Gnu C 3.4.3 Gnu make 3.80 binutils 2.15.94.0.2.2 util-linux 2.12q mount 2.12q module-init-tools 3.1 e2fsprogs 1.37 jfsutils 1.1.7 reiserfsprogs 3.6.19 reiser4progs line xfsprogs 2.6.25 quota-tools3.12. PPP2.4.3 nfs-utils 1.0.6 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Linux C++ Library 6.0.3 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 058 Modules Loaded snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss nfsd lockd sunrpc ip6t_limit ip6table_filter ip6_tables ipt_MASQUERADE ipt_TCPMSS ipt_state ipt_REJECT ipt_LOG ipt_limit iptable_mangle iptable_nat iptable_filter ip_conntrack_ftp ip_conntrack_irc r128 drm ip_conntrack ip_tables af_packet ppp_synctty ppp_async crc_ccitt ppp_generic slhc cls_route cls_u32 cls_fw sch_sfq sch_htb ohci_hcd ehci_hcd tsdev psmouse 8250_pnp 8250 serial_core floppy pcspkr rtc aty128fb snd_es1938 gameport snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd i2c_viapro i2c_core uhci_hcd usbcore pci_hotplug via_agp agpgart evdev autofs4 squashfs zlib_inflate nls_iso8859_1 nls_cp437 vfat fat xfs exportfs jfs loop ipv6 binfmt_misc parport_pc lp parport 8139too mii ide_cd cdrom capability commoncap via82cxxx video thermal processor fan button battery ac unix - Nachricht von [EMAIL PROTECTED] - Datum: Sun, 31 Jul 2005 16:07:04 +0200 Von: Tobias <[EMAIL PROTECTED]> Antwort an: Tobias <[EMAIL PROTECTED]> Betreff: 2.6.11.3 2.6.11.6 2.6.12 2.6.13rc3 Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424 An: linux-kernel@vger.kernel.org Hi I tried 2.6.11.3 2.6.11.6 2.6.12 2.6.13rc3 In all these Kernels syslog reports me every few minutes log-entries like this Badness in blk_remove_plug at drivers/block/ll_rw_blk.c:1424 [] blk_remove_plug+0x69/0x70 [] __generic_unplug_device+0x1a/0x30 [] __make_request+0x248/0x5a0 [] mempool_alloc+0x33/0x110 [] autoremove_wake_function+0x0/0x60 [] generic_make_request+0x11d/0x210 [] autoremove_wake_function+0x0/0x60 [] find_lock_page+0xaf/0xe0 [] autoremove_wake_function+0x0/0x60 [] mempool_alloc+0x33/0x110 [] _pagebuf_lookup_pages+0x1a2/0x2f0 [xfs] [] submit_bio+0x56/0xf0 [] bio_alloc_bioset+0x130/0x1f0 [] bio_add_page+0x34/0x40 [] _pagebuf_ioapply+0x19f/0x2d0 [xfs] [] default_wake_function+0x0/0x20 [] default_wake_function+0x0/0x20 [] pagebuf_iorequest+0x48/0x1b0 [xfs] [] default_wake_function+0x0/0x20 [] default_wake_function+0x0/0x20 [] xfs_bdstrat_cb+0x38/0x50 [xfs] [] pagebuf_iostart+0x46/0xa0 [xfs] [] xfs_bdstrat_cb+0x0/0x50 [xfs] [] xfs_iflush+0x2b8/0x4e0 [xfs] [] xfs_inode_flush+0x157/0x220 [xfs] [] linvfs_write_inode+0x40/0x80 [xfs] [] __sync_single_inode+0x132/0x270 [] __writeback_single_inode+0x3f/0x180 [] enable_8259A_irq+0x48/0x90 [] __do_IRQ+0x111/0x160 [] sync_sb_inodes+0x1a5/0x300 [] writeback_inodes+0xed/0x130 [] wb_kupdate+0xb6/0x140 [] pdflush+0x0/0x30 [] __pdflush+0xd8/0x200 [] pdflush+0x26/0x30 [] wb_kupdate+0x0/0x140 [] pdflush+0x0/0x30 [] kthread+0xa9/0xf0 [] kthread+0x0/0xf0 [] kernel_thread_helper+0x5/0x10 In bugzilla I found it here to: http://bugzilla.kernel.org/show_bug.cgi?id=4837 First I reportet it here : http://bugzilla.kernel.org/show_bug.cgi?id=4438 This message was sent using IMP, the Internet Messaging Program. ( http://www.horde.org ) - To
Re: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote: > > IP Not changing? Could it be in a loop doing faults for the same memory > > location that you cannot observe with gdb? Or is there some hardware fault > > that has stopped the processor? > > I'm not the worlds most experienced user of gdb but I can't see any > evidence of a hardware fault and the processor shows all indications of > running. It seems likely to be looping with memory faults or otherwise > jammed somehow. Can you run kgdb on it to figure out what is going on? > Is there anything I can use in /proc to monitor page faults or anything > I can do with gdb to help narrow this down? Run kgdb and see what is going on in the fault handler. There are some variables in /proc/vmstat that may help: spurious_page_faults 0 cmpxchg_fail_flag_update 0 cmpxchg_fail_flag_reuse 0 cmpxchg_fail_anon_read 0 cmpxchg_fail_anon_write 0 etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Power consumption HZ100, HZ250, HZ1000: new numbers
On Mon, Aug 01, 2005 at 12:18:18PM -0400, James Bruce wrote: > > The tradeoff is a realistic 4.4% power savings vs a 300% increase in the > minimum sleep period. A user will see zero power savings if they have a > USB mouse (probably 99% of desktops). On top of that, we can throw in > Con's disturbing AV benchmark results (1). As a result, some of us > don't think 250HZ is a great tradeoff to make _for_the_default_value_. Most laptops (including mine, a Thinkpad T40) use a PS/2 mouse. So in the places where power consumption savins matters most, it's usually quite possible to function without needing any USB devices. The 90% figure isn't at all right; in fact, it may be that over 90% of the laptops still use PS/2 mice and keyboards. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
wakeup race checking for RT
In the interest of CC'ing everyone here's another patch .
This checks for wake_up_process() calls inside was preempt off sections.
So if it was a spinlock , and you call wake_up_process() it will trigger
a warning.. These are problematic cause in RT the wake_up_process() (if
it's an RT task) will cause a context switch immediately , but with out
RT you don't context switch till you unlock the last spinlock ..
There is also some checking on lock_depth , includes all types of locks
that are not rt_mutex types. I noticed that my test system went to lock
depth ~17 !
Daniel
Index: linux-2.6.12/include/linux/init_task.h
===
--- linux-2.6.12.orig/include/linux/init_task.h 2005-07-31 19:19:42.0
+
+++ linux-2.6.12/include/linux/init_task.h 2005-07-31 19:23:53.0
+
@@ -63,6 +63,12 @@
extern struct group_info init_groups;
+#ifdef CONFIG_DEBUG_PREEMPT
+# define INIT_LOCK_COUNT(x).lock_count = x,
+#else
+# define INIT_LOCK_COUNT(x)
+#endif
+
/*
* INIT_TASK is used to set up the first task table, touch at
* your own risk!. Base=0, limit=0x1f (=2MB)
@@ -74,6 +80,7 @@ extern struct group_info init_groups;
.usage = ATOMIC_INIT(2), \
.flags = 0,\
.lock_depth = -1, \
+ INIT_LOCK_COUNT(0) \
.prio = MAX_PRIO-20, \
.static_prio= MAX_PRIO-20, \
.normal_prio= MAX_PRIO-20, \
Index: linux-2.6.12/include/linux/rt_lock.h
===
--- linux-2.6.12.orig/include/linux/rt_lock.h 2005-07-31 19:19:42.0
+
+++ linux-2.6.12/include/linux/rt_lock.h2005-07-31 19:23:53.0
+
@@ -80,6 +80,9 @@ struct rt_mutex {
char*name, *file;
int line;
# endif
+# ifdef CONFIG_DEBUG_PREEMPT
+ int was_preempt_off;
+# endif
};
/*
@@ -96,6 +99,12 @@ struct rt_mutex_waiter {
#endif
};
+#ifdef CONFIG_DEBUG_PREEMPT
+# define __WAS_PREEMPT_OFF(x) , .was_preempt_off = x
+#else
+# define __WAS_PREEMPT_OFF(x) , .was_preempt_off = x
+#endif
+
#ifdef CONFIG_RT_DEADLOCK_DETECT
# define __RT_MUTEX_DEADLOCK_DETECT_INITIALIZER(lockname) \
, .name = #lockname, .file = __FILE__, .line = __LINE__
@@ -124,6 +133,7 @@ struct rt_mutex_waiter {
#define __RT_MUTEX_INITIALIZER(lockname) \
{ .wait_lock = __RAW_SPIN_LOCK_UNLOCKED \
__PLIST_INIT(lockname) \
+ __WAS_PREEMPT_OFF(0)\
__RT_MUTEX_DEADLOCK_DETECT_INITIALIZER(lockname) \
__RT_MUTEX_DEBUG_RT_LOCKING_MODE_INITIALIZER }
@@ -155,6 +165,7 @@ typedef struct {
.wait_lock = __RAW_SPIN_LOCK_UNLOCKED, .save_state = 1 \
__PLIST_INIT((lockname).lock.lock) \
, .file = __FILE__, .line = __LINE__ \
+ __WAS_PREEMPT_OFF(1)\
__RT_MUTEX_DEBUG_RT_LOCKING_MODE_INITIALIZER
# define _RW_LOCK_UNLOCKED(lockname) \
(rwlock_t) { { { __RW_LOCK_UNLOCKED(lockname), .name = #lockname } } }
@@ -188,6 +199,7 @@ typedef struct {
.wait_lock = __RAW_SPIN_LOCK_UNLOCKED \
__PLIST_INIT(((lockname).lock)) \
, .save_state = 1, .file = __FILE__, .line = __LINE__ \
+ __WAS_PREEMPT_OFF(1)\
__RT_MUTEX_DEBUG_RT_LOCKING_MODE_INITIALIZER
# define _SPIN_LOCK_UNLOCKED(lockname) \
(spinlock_t) { { __SPIN_LOCK_UNLOCKED(lockname), .name = #lockname } }
Index: linux-2.6.12/include/linux/sched.h
===
--- linux-2.6.12.orig/include/linux/sched.h 2005-07-31 19:19:42.0
+
+++ linux-2.6.12/include/linux/sched.h 2005-07-31 19:39:38.0 +
@@ -54,6 +54,14 @@ extern int debug_direct_keyboard;
# define debug_direct_keyboard 0
#endif
+#if defined(CONFIG_DEBUG_PREEMPT) && defined(CONFIG_PREEMPT_RT)
+extern int check_locking_preempt_off(struct task_struct *p);
+extern void check_preempt_wakeup(struct task_struct * p);
+#else
+#define check_locking_preempt_off(x) (0)
+#define check_preempt_wakeup(p)do { } while(0)
+#endif
+
#ifdef CONFIG_RT_DEADLOCK_DETECT
extern void deadlock_trace_off(void);
extern void show_held_locks(struct task_struct *filter);
@@ -889,14 +897,19 @@ struct task_struct {
/* Protection of proc_dentry: nesting proc_lock, dcache_lock,
write_lock_irq(_lock); */
spinlock_t proc_lock;
-#define MAX_PREEMPT_TRACE 16
+#define MAX_PREEMPT_TRACE 20
#ifdef CONFIG_PREEMPT_TRACE
unsigned long preempt_trace_eip[MAX_PREEMPT_TRACE];
unsigned long preempt_trace_parent_eip[MAX_PREEMPT_TRACE];
#endif
+
+#define MAX_LOCK_STACK MAX_PREEMPT_TRACE
Re: revert yenta free_irq on suspend
Hi, On Monday, 1 of August 2005 04:06, Andrew Morton wrote: > Shaohua Li <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > In general, I think that calling free_irq is the right behavior. > > > Although irqs changing after suspend is rare, there are also some > > > more serious issues. This has been discussed in the past, and a > > > summary is as follows: > > > > irqs actually isn't changed after suspend currently, it's a considering > > for future usage like hotplug. > > Calling free_irq actually isn't a complete ACPI issue, but ACPI requires > > it to solve nasty 'sleep in atomic' warning. > > Is that the only problem? If so, then surely we can make free_irq() run > happily with interrupts disabled: unlink the IRQ handler synchronously, > defer the /proc teardown or something like that. > > > You will find such break > > with swsusp without ACPI. Could we revert the ACPI change in Linus's > > tree but keep it in -mm tree? So we get a chance to fix drivers. > > That depends on the amount of brokenness involved: if it's significant then > I'll get a ton of bug reports concerning something which we already know is > broken and we'll drive away our long-suffering testers. Well, IMO there's no such danger. ;-) The relevent ACPI change has been in -mm since 2.6.12-rc1-mm1 and _nobody_ except for me has reported _any_ problems with it. :-) OTOH, if the change is kept in -mm, we hopefully will be able to identify the drivers that need to be converted first, on the basis of the bug reports. And the testers need not be driven away if the issues they report are fixed in a timely manner, which is quite simple in this particuar case, because we know what's potentially broken, we know how to fix it, and the fix is quite not that complicated. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-08-01 at 23:03 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > - struct semaphore stop;
> > > + struct compat_semaphore stop;
> >
> > i think it's policy->lock that is the issue here?
> >
>
> I was looking at Luca's original message where he showed the bug of
> -- drivers/char/watchdog/cpu5wdt.c: "cpu5wdt: Unknown symbol
> there_is_no_init_MUTEX_LOCKED_for_RT_semaphores") --
> Looking into this file the only init_MUTEX_LOCKED that I found was
>
> static int __devinit cpu5wdt_init(void)
> {
> unsigned int val;
> int err;
>
> [...]
>
> /* watchdog reboot? */
> val = inb(port + CPU5WDT_STATUS_REG);
> val = (val >> 2) & 1;
> if ( !val )
> printk(KERN_INFO PFX "sorry, was my fault\n");
>
> init_MUTEX_LOCKED(_device.stop);
> cpu5wdt_device.queue = 0;
>
> clear_bit(0, _device.inuse);
>
>
>
> Here I see that cpu5wdt_device.stop is being initialized with
> init_MUTEX_LOCKED, so that is what I went to fix. I even added the
> driver to my config and compiled it before sending it in. I don't
> have the device, but the driver compiled :-)
ok - the fix is in -52-10.
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] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
On Mon, 2005-08-01 at 23:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > - struct semaphore stop;
> > + struct compat_semaphore stop;
>
> i think it's policy->lock that is the issue here?
>
I was looking at Luca's original message where he showed the bug of
-- drivers/char/watchdog/cpu5wdt.c: "cpu5wdt: Unknown symbol
there_is_no_init_MUTEX_LOCKED_for_RT_semaphores") --
Looking into this file the only init_MUTEX_LOCKED that I found was
static int __devinit cpu5wdt_init(void)
{
unsigned int val;
int err;
[...]
/* watchdog reboot? */
val = inb(port + CPU5WDT_STATUS_REG);
val = (val >> 2) & 1;
if ( !val )
printk(KERN_INFO PFX "sorry, was my fault\n");
init_MUTEX_LOCKED(_device.stop);
cpu5wdt_device.queue = 0;
clear_bit(0, _device.inuse);
Here I see that cpu5wdt_device.stop is being initialized with
init_MUTEX_LOCKED, so that is what I went to fix. I even added the
driver to my config and compiled it before sending it in. I don't have
the device, but the driver compiled :-)
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Mon, 2005-08-01 at 14:16 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> > of the trace is junk as glibc's arm memcpy implementation will have
> > destroyed the frame pointer. The current instruction is a store to
> > memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
> > changing...
>
> IP Not changing? Could it be in a loop doing faults for the same memory
> location that you cannot observe with gdb? Or is there some hardware fault
> that has stopped the processor?
I'm not the worlds most experienced user of gdb but I can't see any
evidence of a hardware fault and the processor shows all indications of
running. It seems likely to be looping with memory faults or otherwise
jammed somehow.
Is there anything I can use in /proc to monitor page faults or anything
I can do with gdb to help narrow this down?
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > > here's the patch below. Could you try to revert it? > > Thanks Ingo. > > If Daniel was trying to detect soft lock ups of lower priority tasks > (tasks that block all tasks lower than itself), I've added a counter > to Daniels patch to keep from showing this for the one time case. > This doesn't spit anything out for me anymore. But I guess this could > detect a higher priority task blocking lower ones, as long as higher > tasks don't run often (thus reseting the count). thanks. In -52-09 i've unapplied the original patch, and i've now uploaded -52-10 with Daniel's original patch plus your patch applied. I think 10 seconds is pretty reasonable - if an RT task runs uninterrupted for that long time i think we want to know about it. It's not illegal for an RT task to monopolize the CPU for that long, but it's certainly unusual enough to warn about. (and the warning can be turned off) 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote: > Ingo, > > What's with the "BUG: possible soft lockup detected on CPU..."? I'm > getting a bunch of them from the IDE interrupt. It's not locking up, > but it does things that probably do take some time. Is this really > necessary? Here's an example dump: > > -- Steve > > Note: I added the curr=%s:%d,current->comm,current->pid just to see who > was at fault. It means that IRQ 14 is running for a long time as an RT task .. btw, the curr=%s:%d information duplicates some in the "show all held locks" section . I could base it off current_sched_time() to only trigger if the task has actually been running for 10 seconds, instead of just assuming that it has.. 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: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
* Daniel Walker <[EMAIL PROTECTED]> wrote: > > here's the patch below. Could you try to revert it? > > You guys want me to always CC in the future? well if it's somewhat larger than a trivial fix then it would definitely be useful to always Cc: lkml. Trivial fixes can go to lkml too, just in case i dont upload fast enough and someone else wants the fix too. Generally, Cc:-ing the mailing list also puts less of a burden on me, because others might find flaws in patches i dont spot right away. 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things that probably do take some time. Is this really
> > necessary? Here's an example dump:
>
> doh - it's Daniel not Cc:-ing lkml when sending me patches, so people
> dont know what's going on ...
>
> here's the patch below. Could you try to revert it?
Thanks Ingo.
If Daniel was trying to detect soft lock ups of lower priority tasks
(tasks that block all tasks lower than itself), I've added a counter to
Daniels patch to keep from showing this for the one time case. This
doesn't spit anything out for me anymore. But I guess this could detect
a higher priority task blocking lower ones, as long as higher tasks
don't run often (thus reseting the count).
-- Steve
Index: linux_realtime_ernie/kernel/softlockup.c
===
--- linux_realtime_ernie/kernel/softlockup.c(revision 266)
+++ linux_realtime_ernie/kernel/softlockup.c(working copy)
@@ -22,6 +22,7 @@
static DEFINE_PER_CPU(unsigned long, print_timestamp) = INITIAL_JIFFIES;
static DEFINE_PER_CPU(struct task_struct *, prev_task);
static DEFINE_PER_CPU(struct task_struct *, watchdog_task);
+static DEFINE_PER_CPU(unsigned long, task_counter);
static int did_panic = 0;
static int softlock_panic(struct notifier_block *this, unsigned long event,
@@ -61,18 +62,21 @@
if (per_cpu(prev_task, this_cpu) != current ||
!rt_task(current)) {
per_cpu(prev_task, this_cpu) = current;
+ per_cpu(task_counter, this_cpu) = 0;
}
- else if (printk_ratelimit()) {
+ else if ((++per_cpu(task_counter, this_cpu) > 10) &&
printk_ratelimit()) {
spin_lock(_lock);
printk(KERN_ERR "BUG: possible soft lockup detected on
CPU#%u! %lu-%lu(%lu)\n",
this_cpu, jiffies, timestamp, timeout);
+ printk("curr=%s:%d\n",current->comm,current->pid);
+
dump_stack();
#if defined(__i386__) && defined(CONFIG_SMP)
nmi_show_all_regs();
#endif
spin_unlock(_lock);
-
+ per_cpu(task_counter, this_cpu) = 0;
}
wake_up_process(per_cpu(watchdog_task, this_cpu));
@@ -97,6 +101,7 @@
nmi_show_all_regs();
#endif
spin_unlock(_lock);
+ per_cpu(task_counter, this_cpu) = 0;
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> > Could you get me some more information about the hang? A stacktrace would
> > be useful.
>
> I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> of the trace is junk as glibc's arm memcpy implementation will have
> destroyed the frame pointer. The current instruction is a store to
> memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
> changing...
IP Not changing? Could it be in a loop doing faults for the same memory
location that you cannot observe with gdb? Or is there some hardware fault
that has stopped the processor?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled
No need to enforce_max_cpus when hotplug code is enabled. This
nukes out cpu_present_map and cpu_possible_map making it impossible to add
new cpus in the system.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/smpboot.c | 40 +++-
1 files changed, 23 insertions(+), 17 deletions(-)
Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/smpboot.c
===
--- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/smpboot.c
+++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/smpboot.c
@@ -893,23 +893,6 @@ static __init void disable_smp(void)
cpu_set(0, cpu_core_map[0]);
}
-/*
- * Handle user cpus=... parameter.
- */
-static __init void enforce_max_cpus(unsigned max_cpus)
-{
- int i, k;
- k = 0;
- for (i = 0; i < NR_CPUS; i++) {
- if (!cpu_possible(i))
- continue;
- if (++k > max_cpus) {
- cpu_clear(i, cpu_possible_map);
- cpu_clear(i, cpu_present_map);
- }
- }
-}
-
#ifdef CONFIG_HOTPLUG_CPU
/*
* cpu_possible_map should be static, it cannot change as cpu's
@@ -929,6 +912,29 @@ static void prefill_possible_map(void)
for (i = 0; i < NR_CPUS; i++)
cpu_set(i, cpu_possible_map);
}
+
+/*
+ * Dont need this when we have hotplug enabled
+ */
+#define enforce_max_cpus(x)
+
+#else
+/*
+ * Handle user cpus=... parameter.
+ */
+static __init void enforce_max_cpus(unsigned max_cpus)
+{
+ int i, k;
+ k = 0;
+
+ for_each_cpu(i) {
+ if (++k > max_cpus) {
+ cpu_clear(i, cpu_possible_map);
+ cpu_clear(i, cpu_present_map);
+ }
+ }
+}
+
#endif
/*
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode.
the use of non-shortcut version of routines breaking CPU hotplug. The option
to select this via cmdline also is deleted with the physflat patch, hence
directly placing this code under CONFIG_HOTPLUG_CPU.
We dont want to use broadcast mode IPI's when hotplug is enabled. This causes
bad effects in send IPI to a cpu that is offline which can trip when the
cpu is in the process of being kicked alive.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/genapic_flat.c |8
1 files changed, 8 insertions(+)
Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_flat.c
===
--- linux-2.6.13-rc4-mm1.orig/arch/x86_64/kernel/genapic_flat.c
+++ linux-2.6.13-rc4-mm1/arch/x86_64/kernel/genapic_flat.c
@@ -78,8 +78,16 @@ static void flat_send_IPI_mask(cpumask_t
static void flat_send_IPI_allbutself(int vector)
{
+#ifndef CONFIG_HOTPLUG_CPU
if (((num_online_cpus()) - 1) >= 1)
__send_IPI_shortcut(APIC_DEST_ALLBUT, vector,APIC_DEST_LOGICAL);
+#else
+ cpumask_t allbutme = cpu_online_map;
+ int me = get_cpu(); /* Ensure we are not preempted when we clear */
+ cpu_clear(me, allbutme);
+ flat_send_IPI_mask(allbutme, vector);
+ put_cpu();
+#endif
}
static void flat_send_IPI_all(int vector)
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > - struct semaphore stop; > + struct compat_semaphore stop; i think it's policy->lock that is the issue here? 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 2.6.13-rc4] fix get_user_pages bug
On Mon, 1 Aug 2005, Linus Torvalds wrote: > On Mon, 1 Aug 2005, Hugh Dickins wrote: > > > > > Aside, that brings up an interesting question - why should readonly > > > mappings of writeable files (with VM_MAYWRITE set) disallow ptrace > > > write access while readonly mappings of readonly files not? Or am I > > > horribly confused? > > > > Either you or I. You'll have to spell that out to me in more detail, > > I don't see it that way. > > We have always just done a COW if it's read-only - even if it's shared. > > The point being that if a process mapped did a read-only mapping, and a > tracer wants to modify memory, the tracer is always allowed to do so, but > it's _not_ going to write anything back to the filesystem. Writing > something back to an executable just because the user happened to mmap it > with MAP_SHARED (but read-only) _and_ the user had the right to write to > that fd is _not_ ok. I'll need to think that through, but not right now. It's a surprise to me, and it's likely to surprise the current kernel too. I'd prefer to say that if the executable was mapped shared from a writable fd, then the tracer will write back to it; but you're clearly against that. We may need to split the vma to handle your semantics correctly. > Using the dirty flag for a "page is _really_ writable" is admittedly kind > of hacky, but it does have the advantage of working even when the -real- > write bit isn't set due to "maybe_mkwrite()". If it forces the s390 people > to add some more hacks for their strange VM, so be it.. I'll concentrate on this for now. s390 used to have the same semantics as everyone else, they made a conscious choice to diverge, and keep dirty bit in separate array indexed by struct page, and page_test_and_clear_dirty macro they use instead of clearing pte_dirty. It works all right, and I don't think it will prevent us communicating between maybe_mkwrite and get_user_pages by a pte flag that would be the usual pte_dirty on every other architecture. Just need to be careful to handle the right one right. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kernel cached memory
Gábor Lénárt wrote: On Mon, Jul 25, 2005 at 12:47:50PM -0400, Bill Davidsen wrote: Gábor Lénárt wrote: On Fri, Jul 22, 2005 at 05:46:58PM +0800, Ashley wrote: I've a server with 2 Operton 64bit CPU and 12G memory, and this server is used to run applications which will comsume huge memory, the problem is: when this aplications exits, the free memory of the server is still very low(accroding to the output of "top"), and from the output of command "free", I can see that many GB memory was cached by kernel. Does anyone know how to free the kernel cached memory? thanks in advance. It's a very - very - very old and bad logic (at least nowdays) from the stone age to free up memory. It's very Microsoft to claim that the OS always knows best, and not let the user tune the system the way they want it tuned. And if that means to leave a bunch of free memory for absolute fastest availability, the admin should have that option. Sure, sorry if my comment can be treated in this way ... I mean surprising amount of people I've met criticised Linux (well, some years ago when DOS was popular) that he/she want to see that 'free memory' field reported eg by 'top' should be the maximum all the time ... I mean this way: this is the behaviour which is quite wrong, I've written about this. Sure, because of my not too good English, I may have missed the real meaning of the mail, sorry about it! Well, I thought I understood "from the stone age" but I may have taken it slightly too literally. But I really would like to have more control over Linux memory use, because it does cause bad behaviour at times. If I have 4GB of RAM, I'd like to set 200MB or so aside for programs, and never page out the window I'm going to uncover later. Likewise when I write a DVD image, I would like to avoid buffering a few GB without i/o and then driving the disk totally busy while it gets written out (after it has pushed out things I will use again). The old 2.4.x-aa kernels had some tunables to make the kernel aggressive about writing pages to disk quickly, and I haven't been able to match that behaviour without patches in 2.6. I may be missing a tunable, but swappiness doesn't seem to be the one I want. I have a patch I'm playing with, but it's not ready for prime time, and is probably counter to the current philosophy of memory management. Thanks for clarifying. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
skge missing ifdefs.
with CONFIG_PM undefined, the build breaks due to
undefined symbols.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
-- linux-2.6.12/drivers/net/sk98lin/skge.c~ 2005-08-01 16:32:42.0
-0400
+++ linux-2.6.12/drivers/net/sk98lin/skge.c 2005-08-01 16:33:10.0
-0400
@@ -5233,8 +5233,10 @@ static struct pci_driver skge_driver = {
.id_table = skge_pci_tbl,
.probe = skge_probe_one,
.remove = __devexit_p(skge_remove_one),
+#ifdef CONFIG_PM
.suspend= skge_suspend,
.resume = skge_resume,
+#endif
};
static int __init skge_init(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Driver for sata adapter promise sata300 tx4
Jens Axboe wrote: On Mon, Aug 01 2005, Jeff Garzik wrote: Jens Axboe wrote: Oh, and forget TCQ. It's a completely worthless technology inherited from PATA, Agreed. There are a few controllers where we may -eventually- add TCQ support, controllers that do 100% of TCQ in hardware. But that's so far down the priority list, it's below just about everything else. There may just be little motivation to -ever- support TCQ, even when libata is the 'main' IDE driver, sometime in the future. Host supported TCQ only removes the pain from the software side, it still doesn't make it a fast techology. The only reason you would want to support that would be "it's easy, why not...". From my POV, I would refuse to support it just from an ideological standpoint :-) Legacy TCQ, hell no, not in a million years. This is largely a confusion of terminology. On the SATA page, "host-based TCQ" == host controller has a hardware queue (DMA ring, or whatnot) "legacy TCQ" == making use of READ/WRITE DMA QUEUED commands. I would only consider accepting the -intersection- of these two feature sets, where host TCQ and legacy TCQ are -both- present. As an extremely low, low priority. :) As a terminology side note, the SATA community refers to "everything that is not NCQ" as "legacy TCQ". Legacy TCQ doesn't necessarily imply use of the standard PCI IDE interface, handling SERV interrupts and all that nastiness. Patches to software-status.html to make this more clear are certainly welcome, as well :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Real-Time Preemption V0.7.52-07: rt_init_MUTEX_LOCKED declaration
* Luca Falavigna <[EMAIL PROTECTED]> wrote: > This patch fixes broken rt_init_MUTEX_LOCKED declaration using > rt_sema_init() macro. This way we fix a potential compile bug: > rt_init_MUTEX_LOCKED calls > there_is_no_init_MUTEX_LOCKED_for_RT_semaphores, which is not > referenced. (e.g. drivers/char/watchdog/cpu5wdt.c: "cpu5wdt: Unknown > symbol there_is_no_init_MUTEX_LOCKED_for_RT_semaphores") the right solution would be to mark policy->lock as a compat_semaphore. That will revert things back to the stock semantics. (at the price of not having PI, which isnt a big issue in this case.) > -+extern void there_is_no_init_MUTEX_LOCKED_for_RT_semaphores(void); the reason for not allowing init_MUTEX_LOCKED() is that in basically every case that does it, the semaphore is not used as a true mutex in the strict sense. So the affected semaphore should be changed to compat_semaphore, to gain full semantics. 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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> getting a bunch of them from the IDE interrupt. It's not locking up,
> but it does things that probably do take some time. Is this really
> necessary? Here's an example dump:
doh - it's Daniel not Cc:-ing lkml when sending me patches, so people
dont know what's going on ...
here's the patch below. Could you try to revert it?
Ingo
On Sun, 2005-07-31 at 20:27 +0200, Ingo Molnar wrote:
> looks good, but i'd suggest to use printk_ratelimit(). (and the use of
> u16 can be a performance hit on x86 due to potential 16-bit prefixes -
> the best thing to use is an 'int' on pretty much every arch. with
> printk_ratelimit() this flag go away anyway.)
Ok, here's with your suggestions.
Index: linux-2.6.12/kernel/softlockup.c
===
--- linux-2.6.12.orig/kernel/softlockup.c 2005-07-31 15:31:09.0
+
+++ linux-2.6.12/kernel/softlockup.c2005-07-31 18:43:35.0 +
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -19,6 +20,7 @@ static DEFINE_RAW_SPINLOCK(print_lock);
static DEFINE_PER_CPU(unsigned long, timeout) = INITIAL_JIFFIES;
static DEFINE_PER_CPU(unsigned long, timestamp) = INITIAL_JIFFIES;
static DEFINE_PER_CPU(unsigned long, print_timestamp) = INITIAL_JIFFIES;
+static DEFINE_PER_CPU(struct task_struct *, prev_task);
static DEFINE_PER_CPU(struct task_struct *, watchdog_task);
static int did_panic = 0;
@@ -56,6 +58,23 @@ void softlockup_tick(void)
if (!per_cpu(watchdog_task, this_cpu))
return;
+ if (per_cpu(prev_task, this_cpu) != current ||
+ !rt_task(current)) {
+ per_cpu(prev_task, this_cpu) = current;
+ }
+ else if (printk_ratelimit()) {
+
+ spin_lock(_lock);
+ printk(KERN_ERR "BUG: possible soft lockup detected on
CPU#%u! %lu-%lu(%lu)\n",
+ this_cpu, jiffies, timestamp, timeout);
+ dump_stack();
+#if defined(__i386__) && defined(CONFIG_SMP)
+ nmi_show_all_regs();
+#endif
+ spin_unlock(_lock);
+
+ }
+
wake_up_process(per_cpu(watchdog_task, this_cpu));
per_cpu(timeout, this_cpu) = jiffies + msecs_to_jiffies(1000);
}
@@ -71,7 +90,7 @@ void softlockup_tick(void)
per_cpu(print_timestamp, this_cpu) = timestamp;
spin_lock(_lock);
- printk(KERN_ERR "BUG: soft lockup detected on CPU#%d!
%ld-%ld(%ld)\n",
+ printk(KERN_ERR "BUG: soft lockup detected on CPU#%u!
%lu-%lu(%lu)\n",
this_cpu, jiffies, timestamp, timeout);
dump_stack();
#if defined(__i386__) && defined(CONFIG_SMP)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
