- 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 Linux->
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 i
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
>>> 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 ret
(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 th
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 sc
* 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 actu
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 cust
>> --- 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
>
* 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."
>
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 som
* [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.
* 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 m
>>> 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 ad
* 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 th
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 multip
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
i
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> please check the one against x86.git it will use fix e820 for gart.
thanks, applied.
Sidenote - there were a few checkpatch failures:
ERROR: use tabs not spaces
#121: FILE: arch/x86/kernel/aperture_64.c:233:
+return 0;$
ERROR: use tabs not
On Mon, Jan 14 2008, Christoph Hellwig wrote:
>
> Folks, this is getting a little silly.
It is
> 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 blk
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.
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
>
> 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 bi
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 t
Hi,
When I "halt -p", lockdep warnings triggered as following (hand copy):
WARNING : at kernel/lockdep.c: 700 lookup_lock_class()
lock_acquire
cleanup_workqueue_thread
workqueue_cpu_callback
notifier_call_chain
__raw_notifier_call_chain
raw_notifier_call_chain
__cpu_down
disable_nonboot_cpus
ke
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 mem
* 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'
> > 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 me
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
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()
>
>
> lock_acquire
> cleanup_workqueue_thread
> workqueue_cpu_callback
> notifier_call_chain
> __raw_
>> 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
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 i
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
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 fo
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 a
> > 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 *pl
* 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
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 /etc/ntp/step-ticker
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
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
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 functio
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
> so
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 incl
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 sys
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
> 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
> m
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
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 PROTE
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 he
> - 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 wil
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 US
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 har
* 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
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
> > When I "halt -p", lockdep warnings triggered as following (hand copy):
> >
> > WARNING : at kernel/lockdep.c: 700 lookup_lock_class()
> >
> >
> > lock_acquire
> > cleanup_workqueue_thread
> > workqueue_cpu_callback
> > notifier_call_chain
> > __raw_notifier_call_chain
> > raw_notifier_call_
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()
> > >
> > >
> > > lock_acquire
> > > cleanup_workqueue_thread
> > > workqueue_cpu_callback
> >
> 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
+++ b/include/linux/pid_name
> 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 switche
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]
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 gua
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 Delv
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
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 think
about it, I got the PSU around two years ago, just like I c
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Change the following static arrays sized by NR_CPUS to
> per_cpu data variables:
>
> char cpu_to_node_map[NR_CPUS];
x86.git randconfig testing found the !NUMA build bugs below.
Ingo
--->
---
arch/x86/kernel/setup_64.c
> > 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) new helper function to update
* 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/
> 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) new helper function to update ctime and mtim
On 2008-01-14 11:06 +0100, Krzysztof Halasa wrote:
> 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.
> I guess I would upgrade to some newer vers
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 struct
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 su
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 tha
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.
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. No
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 bel
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
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
>>> 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 i
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 *
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,
> > > >
> > > >
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
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 basical
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 suf
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 PROTE
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 rfc
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__); \
>
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 sys
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 th
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 b
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.
http://git.kernel.org/
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 con
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
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 und
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:
>
> am2:/sys/devices/system/clocksource/cl
1 - 100 of 509 matches
Mail list logo
