- Original Message
From: Martin Knoblauch [EMAIL PROTECTED]
To: Chris Snook [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; spam trap [EMAIL
PROTECTED]
Sent: Saturday, December 29, 2007 12:11:08 PM
Subject: Re: Strange NFS write performance
On Jan 10, 2008 10:11 AM, Marc Pignat [EMAIL PROTECTED] wrote:
watchdog driver for embedded systems with a supervisor watchdog (MAX823 or so)
connected to a gpio. This is the platform_driver and needs platform_data for
defining the gpio pin and the watchdog timeout.
generic gpio watchdog is
On Mon, Jan 14 2008, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
because a perfectly working system is:
a user's .config that worked before should work with the new kernel
too
not:
a user's .config that worked before should work now too, with random
Jeremy Fitzhardinge [EMAIL PROTECTED] 11.01.08 18:28
Jan Beulich wrote:
Don't rely on kmalloc(PAGE_SIZE) returning PAGE_SIZE aligned memory
(Xen requires GDT *and* LDT to be page-aligned).
Can kmalloc return non-page-aligned PAGE_SIZE allocations?
Documentation says it's to return
(lkml Cc:-ed)
* Carlos R. Mafra [EMAIL PROTECTED] wrote:
choice
prompt Timer frequency
+ depends on !NO_HZ
default HZ_250
help
Allows the configuration of the timer frequency. It is customary
we are not there yet to be able to do this. With NO_HZ the tick is
On Sun, 2008-01-13 at 15:54 -0500, Steven Rostedt wrote:
OK, -rt2 will take a bit more beating from me before I release it, so it
might take some time to get it out (expect it out on Monday).
Ah, that reminds me (tests, yup) I still need the patchlet below to
resume from ram without black
* Chris Wright [EMAIL PROTECTED] wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
thanks for tracking it down. I pulled that commit for now. But it would
be nice to figure out what's going on there.
Zach was right. The unification was broken for 32-bit; it was missing
the actual
On Mon, 2008-01-14 at 09:25 +0100, Ingo Molnar wrote:
(lkml Cc:-ed)
* Carlos R. Mafra [EMAIL PROTECTED] wrote:
choice
prompt Timer frequency
+ depends on !NO_HZ
default HZ_250
help
Allows the configuration of the timer frequency. It is customary
we are not
--- 2.6.24-rc7-initconst.orig/include/linux/init.h
+++ 2.6.24-rc7-initconst/include/linux/init.h
@@ -269,11 +269,13 @@ void __init parse_early_param(void);
#ifdef CONFIG_HOTPLUG_CPU
#define __cpuinit
#define __cpuinitdata
+#define __cpuinitconst const
#define __cpuexit
#define
* Ingo Molnar [EMAIL PROTECTED] wrote:
because a perfectly working system is:
a user's .config that worked before should work with the new kernel
too
not:
a user's .config that worked before should work now too, with random
new kernel features enabled as well.
the latter
On Jan 11, 2008 11:40 AM, Florian Fainelli
[EMAIL PROTECTED] wrote:
Did you look into hooking into Wim's uniform watchdog driver :
http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-experimental.git;a=commit;h=732c54027e6c866f98857c4a6d1c6c466459dcd5
Maybe you can save some code
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
This patchset addresses the kernel bloat that occurs when NR_CPUS is
increased. The memory numbers below are with NR_CPUS = 1024 which I've
been testing (4 and 32 real processors, the rest possible using the
additional_cpus start option.) These
* Chris Wright [EMAIL PROTECTED] wrote:
Refactor ioport unification to pull out common code.
thanks, applied. Looks quite a bit more logical this way.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Sam Ravnborg [EMAIL PROTECTED] 13.01.08 22:42
And I found another small buglet too. I hope to post a complete
solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The problem was the modpost structure
were not prepared for adding such
* Chuck Ebbert [EMAIL PROTECTED] wrote:
Subject: x86: Add the print code before the trapping instruction feature
to 64 bit
From: Arjan van de Ven [EMAIL PROTECTED]
The 32 bit x86 tree has a very useful feature that prints the Code:
line for the code even before the trapping
Folks, this is getting a little silly.
Even if CONFIG_NO_HZ is new this is a an important regression, and
yes we should avoid regressions wherever we can, and for such a quite
important feature we should fix it. On the other hand blktrace is using
the wrong interface, and it has been told
Joonwoo Park wrote:
2008/1/11, Chatre, Reinette [EMAIL PROTECTED]:
On Thursday, January 10, 2008 5:25 PM, Joonwoo Park wrote:
What modification are you considering?
Roughly, I'm considering make synchronize_irq() be moved into
iwl_disable_interrupts() and fix iwl_irq_tasket not to call
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
The regression is:
1)stoakley with 2 qual-core processors: 11%;
2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
I have new update on this issue and also cc to netdev maillist.
Thank
On Mon 2008-01-14 00:29:12, Russell King wrote:
On Fri, Jan 11, 2008 at 10:17:21AM +, Pavel Machek wrote:
On Tue 2008-01-08 11:57:03, Russell King wrote:
+ if (!tries)
+ printk(KERN_ERR %s%s%s%d: Unable to drain
transmitter\n,
+
#include linux/gpio_wdt.h
perhaps watchdog rather than wdt considering it's already
linux/watchdog.h ?
or _wdt/wdt_ like the rest of the watchdog code uses for watchdog names
(wdt -watchdog timer).
+ case WDIOC_KEEPALIVE:
+ gpio_wdt_keepalive(wdt);
+
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
regression is between 16%~11%.
I tried to use bisect to locate the
Nick Piggin wrote:
On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote:
Nick,
Is this supposed to apply to the latest Linus tree? I applied it here
and the mspec driver lights up in beautiful fireworks :-( I'll give the
-mm tree a try next.
Hi Jes,
(reply to all this time).
It is
Hi,
When I halt -p, lockdep warnings triggered as following (hand copy):
WARNING : at kernel/lockdep.c: 700 lookup_lock_class()
snip
lock_acquire
cleanup_workqueue_thread
workqueue_cpu_callback
notifier_call_chain
__raw_notifier_call_chain
raw_notifier_call_chain
__cpu_down
disable_nonboot_cpus
On Jan 14, 2008 4:03 AM, Alan Cox [EMAIL PROTECTED] wrote:
+static char banner[] __initdata = KERN_INFO PFX fixed %d.%03d seconds
timeout (nowayout= %d)\n;
this only gets used once in the init function ... having it be broken
out like this is kind of silly
Saves memory - you can't
* Ingo Molnar [EMAIL PROTECTED] wrote:
32cpus1kcpus-before 1kcpus-after
7172678 Total +23314404 Total -147590 Total
1kcpus-after means it's +23314404-147590, i.e. +23166814? (i.e. a 0.6%
reduction of the bloat?)
or if it's
even when designed for Redmond products.
I find it hard to believe that even they have their drivers do PCI config
access via ports directly from the drivers,
and especially in driver reference code...
Microsoft may not but the standard of Taiwanese driver code (and by
reference I mean
On Mon, Jan 14, 2008 at 08:33:35AM +, Jan Beulich wrote:
Sam Ravnborg [EMAIL PROTECTED] 13.01.08 22:42
And I found another small buglet too. I hope to post a complete
solution later today.
The modpost bits turned out to take longer than expected so
they are not done yet. The
On Mon, 2008-01-14 at 17:04 +0800, Dave Young wrote:
Hi,
When I halt -p, lockdep warnings triggered as following (hand copy):
WARNING : at kernel/lockdep.c: 700 lookup_lock_class()
snip
lock_acquire
cleanup_workqueue_thread
workqueue_cpu_callback
notifier_call_chain
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in
static char __cpuinitcdata
On Mon, Jan 14, 2008 at 10:04:59AM +0100, Pavel Machek wrote:
On Mon 2008-01-14 00:29:12, Russell King wrote:
If you're suspending because your battery is almost dead what would you
prefer - the system being prevented from suspending and losing complete
power unexpectedly, resulting in
On Mon, 2008-01-14 at 11:21 +0200, Ilpo J�rvinen wrote:
On Mon, 14 Jan 2008, Ilpo J�rvinen wrote:
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
On Jan 14, 2008 4:29 AM, Alan Cox [EMAIL PROTECTED] wrote:
Saves memory - you can't make inlined strings __initdata without breaking
some compilers. So it is correct.
you could make the same argument about all strings used in all __init
functions. making a special case for this one
I'm so sorry for mangled patch.
resending patch with preformat html from thunderbird.
After disabling interrupts, it's possible irq tasklet is pending or running
This patch eleminates races for down iwlwifi.
Since synchronize_irq can introduce iwl_irq_tasklet, tasklet_kill should be
called
Saves memory - you can't make inlined strings __initdata without breaking
some compilers. So it is correct.
you could make the same argument about all strings used in all __init
functions. making a special case for this one string is just
confusing. this is also used from the *platfrom
* Andi Kleen [EMAIL PROTECTED] wrote:
i.e. we've got ~22K bloat per CPU - which is not bad, but because
it's a static component, it hurts smaller boxes. For distributors to
enable CONFIG_NR_CPU=1024 by default i guess that bloat has to drop
below 1-2K per CPU :-/ [that would still
On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote:
[...]
ntpdate isn't run by any of the init scripts. ntpd is, but like I
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
Add your timeservers in
On Mon, Jan 14, 2008 at 09:25:54AM +, Jan Beulich wrote:
The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.
static const char __cpuinitcdata example[];
and (accidentally) omitting the 'const' (as it's really an
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
It isn't, right after boot. But while the system is on, it sometimes
starts advancing very fast, 15min a day or so.
On Mon, Jan 14, 2008 at 12:49:59AM +, Alan Cox wrote:
Is printk() enough for 'we've just lost your data' condition? Maybe we
should abort suspend if we can't drain fifo?
No way. Think about this from a users' perspective. No one wants suspend
to ram or hibernate functionality that
On Mon, Jan 14, 2008 at 11:54:39AM +0800, Fengguang Wu wrote:
particular this bug is triggered because the dir mapping page has
PAGECACHE_TAG_DIRTY set and PG_dirty cleared, staying in an
inconsistent state.
Just found that a deleted dir will enter that inconsistent state when
someone
watchdog driver for embedded systems with a supervisor watchdog (MAX823 or so)
connected to a gpio. This is the platform_driver and needs platform_data for
defining the gpio pin and the watchdog timeout.
Signed-off-by: Marc Pignat [EMAIL PROTECTED]
---
Hi!
Changes form take1:
* corrected
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as there is
no real guarantee that your clock is not far off.
It isn't, right after boot. But while the system is
Tuomo Valkonen [EMAIL PROTECTED] writes:
It isn't, right after boot. But while the system is on, it sometimes
starts advancing very fast, 15min a day or so.
So why don't you fix it first? Correct system time is essential.
I guess I would upgrade to some newer version, perhaps one which isn't
i.e. we've got ~22K bloat per CPU - which is not bad, but because it's a
static component, it hurts smaller boxes. For distributors to enable
CONFIG_NR_CPU=1024 by default i guess that bloat has to drop below 1-2K
per CPU :-/ [that would still mean 1-2MB total bloat but that's much
more
On Mon, Jan 14, 2008 at 01:40:16PM +1100, [EMAIL PROTECTED] wrote:
Hi.
Alan Cox wrote:
Is printk() enough for 'we've just lost your data' condition? Maybe we
should abort suspend if we can't drain fifo?
No way. Think about this from a users' perspective. No one wants suspend
to ram or
On Sat 12-01-08 14:13:31, Marcin Slusarz wrote:
On Fri, Jan 11, 2008 at 12:24:49AM +0100, Jan Kara wrote:
On Thu 10-01-08 23:06:26, [EMAIL PROTECTED] wrote:
Signed-off-by: Marcin Slusarz [EMAIL PROTECTED]
CC: Jan Kara [EMAIL PROTECTED]
CC: Christoph Hellwig [EMAIL PROTECTED]
Just
Hi
I am having serious issue with one of servers.
It is very difficult to reproduce bug, and also difficult to catch screen,
cause server installed in rack in another country, and local staff had under
hands only phone camera, and new messages was appearing non-stop on screen,
so i had some
- what if its a port with 256 characters in the FIFO, and its programmed
for 110 baud?
- what if loopback isn't supported?
- what if, while doing this operation, the remote end is sending characters
because you can't deassert RTS?
More importantly it is unlikely that serial state will or
Stefan Richter wrote:
Greg KH wrote:
On Sat, Jan 12, 2008 at 01:20:46PM +0300, Al Boldi wrote:
Greg KH wrote:
On Sat, Jan 05, 2008 at 06:40:38PM +0300, Al Boldi wrote:
Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device
Driver Menu. ?This helps the USB Kconfig Menu to
Hi
Correction, it is appearing from 2.6.22, oldest kernel i found on server is
2.6.22. Older kernels i didn't try, and probably will be difficult to try.
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Jan Engelhardt, le Mon 14 Jan 2008 02:40:08 +0100, a écrit :
On Jan 14 2008 00:52, Samuel Thibault wrote:
In many cases, one prefers to have e.g. the NumLock on by default. In
many cases, one doesn't want to have it by default, e.g. on laptops.
Distributions actually have a very hard time
* Chuck Ebbert [EMAIL PROTECTED] wrote:
it's a 2.6.24.1 candidate i believe. We trigger plenty of various
crashes during x86.git maintenance and others hit various crashes in
-mm, so by the time .1 is released we'll have it in .25 and can
backport it. Most folks/distros will update to
H. Peter Anvin, le Sun 13 Jan 2008 19:50:34 -0800, a écrit :
Actually, what would be perfect would be to use the configuration that
the BIOS sets at boot by default. That is device-dependent, however.
It is, but it can be read out either by INT calls at initialization
time, or by reading
When I halt -p, lockdep warnings triggered as following (hand copy):
WARNING : at kernel/lockdep.c: 700 lookup_lock_class()
snip
lock_acquire
cleanup_workqueue_thread
workqueue_cpu_callback
notifier_call_chain
__raw_notifier_call_chain
raw_notifier_call_chain
__cpu_down
On Mon, 2008-01-14 at 11:35 +0100, Johannes Berg wrote:
When I halt -p, lockdep warnings triggered as following (hand copy):
WARNING : at kernel/lockdep.c: 700 lookup_lock_class()
snip
lock_acquire
cleanup_workqueue_thread
workqueue_cpu_callback
notifier_call_chain
Substantial code cleanup of the sys_msync() function:
1) using the PAGE_ALIGN() macro instead of manual alignment;
2) improved readability of the loop traversing the process memory regions.
Thanks for doing this. See comments below.
Signed-off-by: Anton Salikhmetov [EMAIL PROTECTED]
---
This patch tries to re-organize the macro expansion of PIDMAP_ENTRIES
(possibly) to a more clear one.
Thanks,
- Ratnadeep Joshi
diff --git a/include/linux/pid_namespace.h
b/include/linux/pid_namespace.h
index 1689e28..06e3e99 100644
--- a/include/linux/pid_namespace.h
+++
The warning that triggered (lockdep.c:700) means that one class (key)
was used with more than one name.
Right.
Looking at cleanup_workqueue_thread(), the lock_acquire() there works on
wq-lockdep_map, and that is only initialized at one spot:
__create_workqueue_key(), thus it stands to
On Mon, Jan 14, 2008 at 08:44:40AM +, Ilpo Järvinen wrote:
I tried to use bisect to locate the bad patch between 2.6.22 and
2.6.23-rc1,
but the bisected kernel wasn't stable and went crazy.
TCP work between that is very much non-existing.
Make sure you haven't switched between
reMark Brown wrote:
Signed-off-by: Liam Girdwood [EMAIL PROTECTED]
Signed-off-by: Graeme Gregory [EMAIL PROTECTED]
Signed-off-by: Mike Arthur [EMAIL PROTECTED]
Signed-off-by: Mark Brown [EMAIL PROTECTED]
Cc: Stanley Cai [EMAIL PROTECTED]
Cc: Rodolfo Giometti [EMAIL PROTECTED]
Cc: Russell
On Mon, 14 Jan 2008 10:57:09 +0100
Bernd Petrovitsch [EMAIL PROTECTED] wrote:
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as
there is no real guarantee that
On Sun, 13 Jan 2008, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL
At Sat, 12 Jan 2008 12:11:20 -0500,
Daniel Hazelton wrote:
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote:
Takashi Iwai wrote:
At Thu, 10 Jan 2008 23:02:53 +0100,
Harald Dunkel wrote:
Takashi Iwai wrote:
Hm... Just to be sure, try the patch below. It's a clean up
* Andi Kleen [EMAIL PROTECTED] wrote:
Otherwise modular tcrypt, kvm-intel have unresolved symbols.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/arch/x86/kernel/rtc.c
===
--- linux.orig/arch/x86/kernel/rtc.c
+++
Hi Marc,
Le lundi 14 janvier 2008, Marc Pignat a écrit :
+static int gpio_wdt_keepalive(struct gpio_wdt *wdt)
+{
+ gpio_set_value(wdt-pdata-pin, 0);
+ gpio_set_value(wdt-pdata-pin, 1);
+ return 0;
+}
I would like this function to be supplied by the platform_data structure
Gidday
I've released man-pages-2.76.
This release is now available for download at:
http://www.kernel.org/pub/linux/docs/man-pages
or ftp://ftp.kernel.org/pub/linux/docs/man-pages
Changes in this release can be seen at
http://www.kernel.org/doc/man-pages/changelog.html#release_2.76
A
Otherwise modular tcrypt, kvm-intel have unresolved symbols.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/arch/x86/kernel/rtc.c
===
--- linux.orig/arch/x86/kernel/rtc.c
+++ linux/arch/x86/kernel/rtc.c
@@ -200,3 +200,5
On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote:
On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote:
That leads to the question why the clock starts to run like crazy at
some time so that `ntpd` can't cope with it.
I do wonder whether the PSU could've been causing it. Now that
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
But for normal PCs, I don't know how much the quality of a PSU is
relevant for the speed of the clock.
Can you test with a different PSU?
I am testing right now. After all I had to get a new PSU, the old one
being as dead as a rock. But
Am Montag, 14. Januar 2008 schrieb Fengguang Wu:
Joerg, this patch fixed the bug for me :-)
Fengguang, congratulations, I can confirm that your patch fixed the bug! With
previous kernels the bug showed up after each reboot. Now, when booting the
patched kernel everything is fine and there is
i think this patchset already gives a net win, by moving stuff from
NR_CPUS arrays into per_cpu area. (Travis please confirm that this is
indeed what the numbers show)
Yes that is what his patchkit does, although I'm not sure he has addressed all
NR_CPUS
pigs yet. The basic idea came out
On Mon, 2008-01-14 at 12:30 +0100, Joerg Platte wrote:
Am Montag, 14. Januar 2008 schrieb Fengguang Wu:
Joerg, this patch fixed the bug for me :-)
Fengguang, congratulations, I can confirm that your patch fixed the bug! With
previous kernels the bug showed up after each reboot. Now,
2008/1/14, Miklos Szeredi [EMAIL PROTECTED]:
Substantial code cleanup of the sys_msync() function:
1) using the PAGE_ALIGN() macro instead of manual alignment;
2) improved readability of the loop traversing the process memory regions.
Thanks for doing this. See comments below.
2008/1/14, Miklos Szeredi [EMAIL PROTECTED]:
http://bugzilla.kernel.org/show_bug.cgi?id=2645
Changes for updating the ctime and mtime fields for memory-mapped files:
1) new flag triggering update of the inode data;
2) new function to update ctime and mtime for block device files;
3)
On Mon, Jan 14, 2008 at 3:27 AM, in message
[EMAIL PROTECTED], Mike Galbraith [EMAIL PROTECTED]
wrote:
On Sun, 2008-01-13 at 15:54 -0500, Steven Rostedt wrote:
OK, -rt2 will take a bit more beating from me before I release it, so it
might take some time to get it out (expect it out on
On Sat, 12 Jan 2008 17:47:54 +0800,
Dave Young [EMAIL PROTECTED] wrote:
Minor style suggestion (same for class_find_child):
+struct device *class_find_device(struct class *class, void *data,
+int (*match)(struct device *, void *))
+{
+ struct device *dev;
On Fri 11-01-08 15:33:54, Andrew Morton wrote:
On Fri, 11 Jan 2008 15:21:31 +0100
Jan Kara [EMAIL PROTECTED] wrote:
On Thu 10-01-08 16:36:35, Andrew Morton wrote:
On Thu, 10 Jan 2008 16:55:13 +0100
Jan Kara [EMAIL PROTECTED] wrote:
Hi,
sorry for the previous empty
On Mon, 14 Jan 2008 04:45:25 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
there is no hard requirement anywhere that says platform resources
must be in the board resources file. marking the functions as __init
instead of __devinit will basically cause a kernel crash if someone
tries to use
On Jan 14, 2008 7:14 AM, Haavard Skinnemoen [EMAIL PROTECTED] wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
there is no hard requirement anywhere that says platform resources
must be in the board resources file. marking the functions as __init
instead of __devinit will basically cause a
On (13/01/08 10:34), [EMAIL PROTECTED] didst pronounce:
Change the size of APICIDs from u8 to u16. This partially
supports the new x2apic mode that will be present on future
processor chips. (Chips actually support 32-bit APICIDs, but that
change is more intrusive. Supporting 16-bit is
Subject was wrong of course -- it was a recursive oops, not a double fault.
Sorry for the inaccuracy.
Hopefully it can be fixed soon because it inhibits further testing here.
-Andi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Mon, 14 Jan 2008 15:05:19 +0800,
Dave Young [EMAIL PROTECTED] wrote:
On Jan 12, 2008 7:09 AM, Gabor Gombas [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:11:17AM +0800, Dave Young wrote:
For bluetooth device_move, the only child device of hci_conn dev is
the rfcomm tty_dev. How
Hi,
Mike Frysinger [EMAIL PROTECTED] writes:
wonder if we could design a printk designed for __init functions to
address this in a clean fashion.
#define init_printk(fmt, __VA_ARGS__) \
do { \
static const __init char __fmt[] = fmt; \
printk(__fmt , ## __VA_ARGS__); \
} while
Tuomo Valkonen [EMAIL PROTECTED] writes:
So why don't you fix it first? Correct system time is essential.
I've tried tuning it with adjtimex and everything, and sometimes it
works for days, but then just suddenly the clock starts advancing.
Nothing will make it work reliably if the system
On Mon, 14 Jan 2008, Matthew Garrett wrote:
Userspace is in a better position to make this determination. Of course,
That's fine with me.
this also means not passing the Linux OSI to the firmware. Our hardware
interaction is sufficiently in flux that any attempt to work around it
in the
On Mon, 2008-01-14 at 07:13 -0500, Gregory Haskins wrote:
On Mon, Jan 14, 2008 at 3:27 AM, in message
[EMAIL PROTECTED], Mike Galbraith [EMAIL PROTECTED]
wrote:
On Sun, 2008-01-13 at 15:54 -0500, Steven Rostedt wrote:
OK, -rt2 will take a bit more beating from me before I release
On Sat, Jan 12, 2008 at 02:54:49PM +, Russell King wrote:
It might be a good idea if there was some co-ordination with people
involved in the duplicate include removal work...
Sorry for the inconvenience! I did not realise that Lucas was working on
this and hence missed his patches.
Best
Hi Len,
in two cases you just introduce the 'warned' variable but do not set
them to '1' after the printk() which is the intetion to print it just
one time. Namely in pnpacpi_parse_allocated_ioresource() and
pnpacpi_parse_allocated_memresource() the 'warned = 1' is missing.
On Jan 14, 2008 7:49 AM, Johannes Weiner [EMAIL PROTECTED] wrote:
Mike Frysinger [EMAIL PROTECTED] writes:
wonder if we could design a printk designed for __init functions to
address this in a clean fashion.
#define init_printk(fmt, __VA_ARGS__) \
do { \
static const __init char
On Mon, Jan 14, 2008 at 05:28:44PM +1100, Neil Brown wrote:
On Monday January 14, [EMAIL PROTECTED] wrote:
Thanks. I'll see what I can some up with.
How about this, against current -mm
On both the read and write path for an rdev attribute, we
call mddev_lock, first checking that
Hi Florian!
On Monday 14 January 2008, Florian Fainelli wrote:
...
I would like this function to be supplied by the platform_data structure
because as I mentioned before, not all GPIO connected watchdog will simply
need a single bit to be toggled, but also sometimes a full GPIO line.
I
Andrew Paprocki wrote:
I started debugging a problem I was having with my sky2 network driver
under 2.6.23.13. The investigation led me to find that the HPET timer
wasn't working at all, causing the sky2 driver to not work properly.
Simple example:
* Andi Kleen [EMAIL PROTECTED] wrote:
Subject was wrong of course -- it was a recursive oops, not a double
fault. Sorry for the inaccuracy.
Hopefully it can be fixed soon because it inhibits further testing
here.
no context. Your first mail did not seem to make it to lkml. (yet)
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the
2008/1/14, Miklos Szeredi [EMAIL PROTECTED]:
http://bugzilla.kernel.org/show_bug.cgi?id=2645
Changes for updating the ctime and mtime fields for memory-mapped files:
1) new flag triggering update of the inode data;
2) new function to update ctime and mtime for block device
More fun, it would require marking them RO but leaving the dirty bit
set, because this ext3 fudge where we confuse the page dirty state - or
did that get fixed?
That got fixed by Nick, I think.
The alternative to marking pages RO, is to walk the PTEs in MS_ASYNC,
note the dirty bit
s/litle/little
Signed-off-by: Ohad Ben-Cohen [EMAIL PROTECTED]
---
fs/binfmt_elf.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index f0b3171..5465c63 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -116,7 +116,7 @@ static int
* Adrian Bunk [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
Technically you are the one who has to deal with problems in your
patches, not the people pointing at the problems.
If you believe that my
On Mon, Jan 14, 2008 at 02:06:20PM +0100, Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
Subject was wrong of course -- it was a recursive oops, not a double
fault. Sorry for the inaccuracy.
Hopefully it can be fixed soon because it inhibits further testing
here.
no
On Mon, Jan 14, 2008 at 12:59:39PM +, Al Viro wrote:
I really don't like the entire scheme, to be honest. BTW, what happens
if you try to add the same device to the same array after having it kicked
out? If that comes before your delayed kobject_del(), the things will
get nasty since
1 - 100 of 988 matches
Mail list logo
