Dror Levin <[EMAIL PROTECTED]> writes:
> looking at the kernel source, after constant failures to boot linux on a core
> 2 imac, has made me understand that only i386 and ia64 support efi booting,
> but x86_64 does not.
x86-64 UEFI support is still being worked on.
Anyways, you should be able t
On Sat, 2006-11-18 at 14:12 +0100, Christian wrote:
> Hello lkml!
>
> Im currently testing 2.6.19-rc5-mm1. Everything works really fine except the
> little wart with bad multimedia interactivity with a kernel compiling in the
> background. So I tried to narrow it down as much
> as possible.
>
On 2006-11-19, Matthew Wilcox wrote:
[]
> Someone with more time might find a more elegant fix for either or both
> of these problems. But now my qlogic adapter can find its firmware without
> being turned into a module.
Please check "initramfs-handle-more-than-one-source-dir-or-file-list.patch"
On Sun, Nov 19, 2006 at 12:24:14AM +0100, Jan Engelhardt wrote:
>
> On Nov 18 2006 21:51, Oleg Verych wrote:
> >On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
> >> >Then, who you think prints that "Killed" or "Segmentation fault"
> >> >messages in *stderr*?
> >> >[Hint: libc's def
From: Tobias Diedrich <[EMAIL PROTECTED]>
Date: Fri, 17 Nov 2006 17:31:51 +0100
> David Miller wrote:
>
> > One should always contact the postmaster for more information when
> > they are unsubscribed from the mailing list.
>
> What about when I knew I was bouncing due to a misconfig,
> expected
I am trying to debug a bcm43xx DMA problem on an x86_64 system with 3 GB RAM. Depending on the
particular chip and its implementation, dma transfers may use 64-, 32-, or 30-bit addressing, with
the problem interface using 30-bit addressing. From test prints, the correct mask (0x3FFF) is
supp
On Sunday 19 November 2006 05:22, Randy Dunlap wrote:
> With CONFIG_NET=n and REISERFS_FS=m (randconfig), kernel build ends with
>
> Kernel: arch/x86_64/boot/bzImage is ready (#15)
> Building modules, stage 2.
> MODPOST 137 modules
> WARNING: "csum_partial" [fs/reiserfs/reiserfs.ko] undefined
The Kconfig help for INITRAMFS_SOURCE claims that you can specify multiple
space-separated sources in order to allow unprivileged users to build an
image. There are two bugs in the current implementation that prevent
this from working.
First, we pass "file1 dir2" to the gen_initramfs_list.sh scr
Randy Dunlap wrote:
From: Randy Dunlap <[EMAIL PROTECTED]>
NAK. Andrew already has a patch that fixes this properly.
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
With CONFIG_NET=n and REISERFS_FS=m (randconfig), kernel build ends with
Kernel: arch/x86_64/boot/bzImage is ready (#15)
Building modules, stage 2.
MODPOST 137 modules
WARNING: "csum_partial" [fs/reiserfs/reiserfs.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
on
* Larry Finger ([EMAIL PROTECTED]) wrote:
> The regression turns out to be a locking problem involving bcm43xx,
> wpa_supplicant, and NetworkManager. The exact cause is unknown; however,
> this patch is clearly not the problem. Please reinstate it for inclusion in
> -stable.
Thanks for the foll
diff --git a/Makefile b/Makefile
index 9e54c3a..9eda185 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 18
-EXTRAVERSION = .2
+EXTRAVERSION = .3
NAME=Avast! A bilge rat!
# *DOCUMENTATION*
diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
b/a
We (the -stable team) are announcing the release of the 2.6.18.3 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between
2.6.18.2 and 2.6.18.3, as it is small enough to do so.
Andrew Morton wrote:
On Fri, 17 Nov 2006 10:59:07 +0100
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
Andrew Morton writes:
> On Thu, 16 Nov 2006 11:55:46 +0100
> Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton writes:
> > > Surely the appropriate behaviour is to allow o
Hi!
> Move the loop from freeze_processes() to a separate function and call it
> independently for user space processes and kernel threads so that the order of
> freezing tasks is clearly visible.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> ---
> kernel/power/process.c | 88
> +
Hi!
> Move the loop from thaw_processes() to a separate function and call it
> independently for kernel threads and user space processes so that the order
> of thawing tasks is clearly visible.
>
> Drop thaw_kernel_threads() which is never used.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTE
On Sat 2006-11-18 23:48:35, Rafael J. Wysocki wrote:
> Fix coding style in suspend.c.
ACK.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/bl
On Sat 2006-11-18 23:51:01, Rafael J. Wysocki wrote:
> Move all labels in the swsusp code to the second column, so that they won't
> fool diff -p.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK.
Pavel
--
(english) htt
On Tuesday 14 November 2006 7:32 am, Alessandro Suardi wrote:
> On 11/13/06, Mark Lord <[EMAIL PROTECTED]> wrote:
> > Shawn Starr wrote:
> > > With WPA2? I have to confirm if things are still broken with ipw2200
> > > 1.1.4. I wish this was sorted out. Really, the developers seem to have
> > > vani
Christian wrote:
> During my I/O load test, after about half an hour of heavy I/O on three
> SATAII
> disks the system suddenly hung for about 3 seconds. After that I checked
> dmesg and found the following error output:
>
> [ 4574.193809] ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0
I just rediscovered a deadlock in drivers/ieee1394/nodemgr.c which I
thought didn't exist anymore. It's still there, it's just a matter of
timing to trigger this. Quoting myself from
http://bugzilla.kernel.org/show_bug.cgi?id=6706 :
-
On Sunday, 19 November 2006 00:06, Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2006-11-18 at 23:51 +0100, Rafael J. Wysocki wrote:
> > Move all labels in the swsusp code to the second column, so that they won't
> > fool diff -p.
>
> This sounds like working around brokenness in diff -p. Should/coul
On Nov 18 2006 21:51, Oleg Verych wrote:
>On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
>> >Then, who you think prints that "Killed" or "Segmentation fault"
>> >messages in *stderr*?
>> >[Hint: libc's default signal handler (man 2 signal).]
>>
>> Please enlighten us on how you p
Hi.
On Sat, 2006-11-18 at 23:51 +0100, Rafael J. Wysocki wrote:
> Move all labels in the swsusp code to the second column, so that they won't
> fool diff -p.
This sounds like working around brokenness in diff -p. Should/could a
patch be submitted to the diff maintainer instead?
Regards,
Nigel
Hi.
On Sat, 2006-11-18 at 23:47 +0100, Rafael J. Wysocki wrote:
> Move the loop from thaw_processes() to a separate function and call it
> independently for kernel threads and user space processes so that the order
> of thawing tasks is clearly visible.
>
> Drop thaw_kernel_threads() which is nev
Fix coding style in suspend.c.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/snapshot.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.19-rc5-mm2/kernel/power/snapshot.c
===
--- l
Move the loop from thaw_processes() to a separate function and call it
independently for kernel threads and user space processes so that the order
of thawing tasks is clearly visible.
Drop thaw_kernel_threads() which is never used.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
include
Hi,
The following series of patches cleans up some suspend-related code.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Move all labels in the swsusp code to the second column, so that they won't
fool diff -p.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/disk.c |6 +++---
kernel/power/snapshot.c |8
kernel/power/swap.c |4 ++--
kernel/power/swsusp.c |2 +-
Move the loop from freeze_processes() to a separate function and call it
independently for user space processes and kernel threads so that the order of
freezing tasks is clearly visible.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/process.c | 88 +++
On 11/18, Alan Stern wrote:
>
> On Sun, 19 Nov 2006, Oleg Nesterov wrote:
>
> > On 11/18, Alan Stern wrote:
> > >
> > > By the way, I think the fastpath for synchronize_srcu() should be safe,
> > > now that you have added the memory barriers into srcu_read_lock() and
> > > srcu_read_unlock(). Y
dev->devt_attr is allocated in device_add() but it is never freed in
device_del() in the drivers/base/core.c file (reported by kmemleak).
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
I sent this patch before for 2.6.18 but it probably got lost. Anyway,
I found the bug again while testin
Fixes the oops in cpufreq_stats with acpi_cpufreq driver.
The issue was that the frequency was reported as 0 in acpi-cpufreq.c.
The bug is due to different indicies for freq_table and ACPI perf table.
Also adds a check in cpufreq_stats to check for error return from
freq_table_get_index() and avo
On Saturday 18 November 2006 1:42 pm, Pierre Ossman wrote:
> David Brownell wrote:
> > I thought the MMC vendors expected to see the actual user-typed
> > password get SHA1-hashed into a value which would take up the whole
> > buffer? In general that's a good idea, since it promotes use of
> > lon
On Sun, 19 Nov 2006, Oleg Nesterov wrote:
> On 11/18, Alan Stern wrote:
> >
> > By the way, I think the fastpath for synchronize_srcu() should be safe,
> > now that you have added the memory barriers into srcu_read_lock() and
> > srcu_read_unlock(). You might as well try putting it in.
>
> I s
I wrote:
> It seems like one of the patches in -mm overwrites a device's list of
> children with junk.
And this happens only if eth1394 wasn't unloaded (therefore unbound
from FireWire "ud" devices beneath FireWire "ne" devices beneath the
FireWire host devices) before the host devices's children
On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
>
> On Nov 18 2006 02:38, Oleg Verych wrote:
> >On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
> >> > > > I found that sometimes processes disappear on some heavily used
> >> > > > system
> >> > > > of mine with
On Sat, Nov 18, 2006 at 01:09:57PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, Nov 18, 2006 at 09:40:13PM +0100, Tomasz Torcz wrote:
> > On Sat, Nov 18, 2006 at 09:07:03PM +0200, Dror Levin wrote:
> > > looking at the kernel source, after constant failures to boot linux on a
> > > core
> > > 2 imac
I added the following patch:
--- linux-2.6.19-rc5-mm2.orig/drivers/ieee1394/nodemgr.c2006-11-18
21:18:05.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/ieee1394/nodemgr.c 2006-11-18
21:33:44.0 +0100
@@ -798,8 +798,9 @@ static void nodemgr_remove_uds(struct no
static void
The MTD_PCMCIA driver has:
- already been marked as BROKEN in 2.6.0 three years ago and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is
David Brownell wrote:
> I thought the MMC vendors expected to see the actual user-typed
> password get SHA1-hashed into a value which would take up the whole
> buffer? In general that's a good idea, since it promotes use of
> longer passphrases (more information) over short ones (easy2crack).
>
On Friday 17 November 2006 4:58 am, Anderson Briglia wrote:
> - Password caching: when inserting a locked card, the driver should try
>to unlock it with the currently stored password (if any), and if it
>fails, revoke the key containing it and fallback to the normal "no
>password prese
On 11/18, Alan Stern wrote:
>
> By the way, I think the fastpath for synchronize_srcu() should be safe,
> now that you have added the memory barriers into srcu_read_lock() and
> srcu_read_unlock(). You might as well try putting it in.
I still think the fastpath should do mb() unconditionally to
On Sat, Nov 18, 2006 at 09:40:13PM +0100, Tomasz Torcz wrote:
> On Sat, Nov 18, 2006 at 09:07:03PM +0200, Dror Levin wrote:
> > looking at the kernel source, after constant failures to boot linux on a
> > core
> > 2 imac, has made me understand that only i386 and ia64 support efi booting,
> > bu
On Sat, 18 Nov 2006, Paul E. McKenney wrote:
> > > @@ -94,7 +112,8 @@ void cleanup_srcu_struct(struct srcu_str
> > > WARN_ON(sum); /* Leakage unless caller handles error. */
> > > if (sum != 0)
> > > return;
> > > - free_percpu(sp->per_cpu_ref);
> > > + if (sp->per_cpu_ref != NULL)
On Sat, Nov 18, 2006 at 09:07:03PM +0200, Dror Levin wrote:
> looking at the kernel source, after constant failures to boot linux on a core
> 2 imac, has made me understand that only i386 and ia64 support efi booting,
> but x86_64 does not.
> it makes sense, if you think about it... AFAIK, until
On Sat, Nov 18, 2006 at 11:34:41AM +0100, Michael Schmitz wrote:
> On Sat, 18 Nov 2006, Adrian Bunk wrote:
>
> > This patch removes video drivers that:
> > - had already been marked as BROKEN in 2.6.0 three years ago and
> > - are still marked as BROKEN.
> >
> > These are the following drivers:
>
On 11/18, Paul E. McKenney wrote:
>
> On Sat, Nov 18, 2006 at 11:15:27AM -0500, Alan Stern wrote:
> > > + smp_processor_id())->c[idx]++;
> > > + smp_mb();
> > > + preempt_enable();
> > > + return idx;
> > > + }
> > > + if (mutex_trylock(&sp->mutex)) {
> >
>> 4. If this is about detecting the loss of specific processes
>>(network services say), then the problem can be solved in
>>user-space by using a separate monitor process, or by
>>controlling the processes via ptrace.
>
>No not only for specific processes. It helps you detect problem
On Nov 18 2006 02:38, Oleg Verych wrote:
>On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
>> > > > I found that sometimes processes disappear on some heavily used system
>> > > > of mine without any logging. So I've written a patch against 2.6.18.2
>> > > > which emits logging
looking at the kernel source, after constant failures to boot linux on a core
2 imac, has made me understand that only i386 and ia64 support efi booting,
but x86_64 does not.
it makes sense, if you think about it... AFAIK, until the new core 2 imacs
were out there was no x86_64 efi pc, so why sh
Chris Wright wrote:
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch <[EMAIL PROTECTED]>
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run.
On 11/17, Paul E. McKenney wrote:
>
> int srcu_read_lock(struct srcu_struct *sp)
> {
> int idx;
> + struct srcu_struct_array *sap;
>
> preempt_disable();
> idx = sp->completed & 0x1;
> - barrier(); /* ensure compiler looks -once- at sp->completed. */
> - per_cpu_p
Ray Lee wrote:
Larry Finger wrote:
Johannes Berg wrote:
Hah, that's a lot more plausible than bcm43xx's drain patch actually
causing this. So maybe somehow interrupts for bcm43xx aren't routed
properly or something...
Ray, please check /proc/interrupts when this happens.
When it happens, I c
On 11/17, Paul E. McKenney wrote:
>
> Oleg, any thoughts about Jens's optimization? He would code something
> like:
>
> if (srcu_readers_active(&my_srcu))
> synchronize_srcu();
> else
> smp_mb();
Well, this is clearly racy, no? I am not sure, but may be we
On Sat, Nov 18, 2006 at 09:27:13AM -0800, Ray Lee wrote:
> Larry Finger wrote:
> > Johannes Berg wrote:
> >> Hah, that's a lot more plausible than bcm43xx's drain patch actually
> >> causing this. So maybe somehow interrupts for bcm43xx aren't routed
> >> properly or something...
> >>
> >> Ray, ple
From: Vladimir Ananiev <[EMAIL PROTECTED]>
Framebuffer support for Siemens SX1; this is second big patch. (Third
one will be mixer/sound support). Support is simple / pretty minimal,
but seems to work okay (and is somehow important for a cell phone :-).
Signed-off-by: Pavel Machek <[EMAIL PROTECT
> > Of course you can't do that. You're calling rtc_set_time(), which
> > requires a task/sleeping context, from an atomic can't-sleep context
> > (timer irq handler in this case).
> >
> > Whatever your rtc_class_hookup() is doing, it's clearly wrong.
>
> It isn't my rtc_class_hookup(), it is in
Hi!
> > > > > + * Copyright (c) 2006-2007 Vivek Goyal ([EMAIL PROTECTED])
> > > >
> > > > Normally it's not ok to take sole copyright on code that you mostly
> > > > copied ...
> > >
> > > Is this a case where the original had no copyright notice? If so,
> > > what do you suggest Vivek should
Toralf F??rster <[EMAIL PROTECTED]> :
[...]
> WARNING: "hdlc_close" [drivers/net/wan/dscc4.ko] undefined!
> WARNING: "hdlc_open" [drivers/net/wan/dscc4.ko] undefined!
> WARNING: "alloc_hdlcdev" [drivers/net/wan/dscc4.ko] undefined!
> WARNING: "unregister_hdlc_device" [drivers/net/wan/dscc4.ko] unde
On Nov 17 2006 12:23, Divy Le Ray <[EMAIL PROTECTED]> wrote:
>Subject: [PATCH 1/10] cxgb3 - main header files
(For all files)
Some suggestions:
* change the typedefs to struct, this includes:
adapter_t -> struct adapter
* function prototypes and function headers (e.g. t3_get_cong
Larry Finger wrote:
> Johannes Berg wrote:
>> Hah, that's a lot more plausible than bcm43xx's drain patch actually
>> causing this. So maybe somehow interrupts for bcm43xx aren't routed
>> properly or something...
>>
>> Ray, please check /proc/interrupts when this happens.
When it happens, I can't
On Sat, Nov 18, 2006 at 11:15:27AM -0500, Alan Stern wrote:
> There are a few things I don't like about this patch.
>
> On Fri, 17 Nov 2006, Paul E. McKenney wrote:
>
> > diff -urpNa -X dontdiff linux-2.6.19-rc5/kernel/srcu.c
> > linux-2.6.19-rc5-dsrcu/kernel/srcu.c
> > --- linux-2.6.19-rc5/kern
On Sat, 18 Nov 2006, David Rientjes wrote:
> The return value of free_pages_check() indicates if PG_reserved was set.
> If so, the calling functions return immediately and no pages are freed so
> there is no need to call bad_page().
>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Cc: Nick Piggin <[EMAIL
> Time for me to let -mm loose on my PC.
Small progress:
- I get the oops already in nodemgr_remove_ne, unlike the original
report where it happened a little later in driver core functions
called by nodemgr_remove_ne.
- I get it only if eth1394 is loaded when I unload ohci1394.
- Like
Johannes Berg wrote:
On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote:
This sounds like what my laptop was doing in -rc5, though mine
didn't take hours to start acting up.
I *think* it was the MSI troubles, causing interrupts to get
lost forever. Anyway, it went away in -rc6.
On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote:
> This sounds like what my laptop was doing in -rc5, though mine
> didn't take hours to start acting up.
>
> I *think* it was the MSI troubles, causing interrupts to get
> lost forever. Anyway, it went away in -rc6.
Hah, that's a l
i've released the 2.6.18-rc6-rt4 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
NOTE: the YUM repository has changed the -rt kernel's package name, it's
now kernel-rt, so it does not override the kernel package. If you have
rt.repo already then
Please take a look at 7466, they seem to fight same problem, so may be
removing same patch will work...
And Linus is about to drop it anyway...
Regards,
Alex.
David Brownell wrote:
On Thursday 16 November 2006 10:22 pm, David Brownell wrote:
On Thursday 16 November 2006 7:41 am, Alexey St
There are a few things I don't like about this patch.
On Fri, 17 Nov 2006, Paul E. McKenney wrote:
> diff -urpNa -X dontdiff linux-2.6.19-rc5/kernel/srcu.c
> linux-2.6.19-rc5-dsrcu/kernel/srcu.c
> --- linux-2.6.19-rc5/kernel/srcu.c2006-11-17 13:54:17.0 -0800
> +++ linux-2.6.19-rc5-ds
make xconfig says
"Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET"
Seems to be another example of how badly the "select" keyword is handled
by the .config make targets. Replace all occurences of "select" in dlm's
Kconfig by "depends on" and some additional help texts.
Sign
On Sat, 18 Nov 2006 13:55:04 +0100
Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> Could you try the following, as of yet untested patch?
> It's i386 twin makes an APIC error vanish here on a K8.
>
> Karsten
> ---
> From 54248a
>
> On Fri, 17 Nov 2006 18:38:10 +0100, Joakim Tjernlund wrote:
> > On Nov 17, 2006, at 10:38 AM, Joakim Tjernlund wrote:
> >
> > > I get this when I activathte NTP and ntp "sync" the time
> the I2C HW
> > > clock.
> >
> > You may be better off posting this to lkml and copy the i2c
> list (a
18 Kas 2006 Cts 16:26 tarihinde, Stephen Clark şunları yazmıştı:
> Ismail Donmez wrote:
> >18 Kas 2006 Cts 12:20 tarihinde, Martin Lorenz şunları yazmıştı:
> >>Dear James,
> >>
> >>I just had some issues when trying to compile ieee80211 1.2.15 together
> >>with ipw3945 1.1.2 on the latest ker
Am Samstag, 18. November 2006 14:25 schrieb Prakash Punnoor:
> Am Samstag 18 November 2006 14:12 schrieb Christian:
> > So I tried to nice the make and see what happens:
> >
> > nice 5 make -j4: Seems to make no difference. Heavy stuttering in
> > glxgears and et
> > nice 10 make -j4: Somewhat bett
On Sat, Nov 18, 2006 at 04:23:06AM +0100, Pavol Gono wrote:
> After resolving http://bugzilla.kernel.org/show_bug.cgi?id=7481
> I was thinking about possibilities how to prevent such bugs with
> testing. Usually just few insmods and rmmods show, whether the
> initialization and cleanup code of modu
Ismail Donmez wrote:
18 Kas 2006 Cts 12:20 tarihinde, Martin Lorenz şunları yazmıştı:
Dear James,
I just had some issues when trying to compile ieee80211 1.2.15 together
with ipw3945 1.1.2 on the latest kernel tree
attached are two patches I had to create to work around it
I guess the
On Fri, 17 Nov 2006 18:38:10 +0100, Joakim Tjernlund wrote:
> On Nov 17, 2006, at 10:38 AM, Joakim Tjernlund wrote:
>
> > I get this when I activathte NTP and ntp "sync" the time the I2C HW
> > clock.
>
> You may be better off posting this to lkml and copy the i2c list (and
> rtc if one exist
Nice to meet you, Miquel!
On 2006-11-18, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Oleg Verych <[EMAIL PROTECTED]> wrote:
>>On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
>>> > > > I found that sometimes processes disappear on some heavily used system
On Fri, 17 Nov 2006, Francis Moreau wrote:
> On Fri, 2006-11-17 at 14:12 +, moreau francis wrote:
> > Peter Zijlstra wrote:
> >
> > The new object is the one allocated using:
> > new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
>
> Of course but at this point the choice of the new VMA is a
* Michal Schmidt <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>
> >i've released the 2.6.18-rc6-rt3 tree
> Hi Ingo,
> lockdep doesn't compile on UP. per_cpu_offset only makes sense on SMP.
yeah - i'll remove the offset printing instead. (fixed the bug for which
it was helpful)
Ingo
During my I/O load test, after about half an hour of heavy I/O on three SATAII
disks the system suddenly hung for about 3 seconds. After that I checked
dmesg and found the following error output:
[ 4574.193809] ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x40
> 4. If this is about detecting the loss of specific processes
>(network services say), then the problem can be solved in
>user-space by using a separate monitor process, or by
>controlling the processes via ptrace.
No not only for specific processes. It helps you detect problems with
Am Samstag 18 November 2006 14:12 schrieb Christian:
> So I tried to nice the make and see what happens:
>
> nice 5 make -j4: Seems to make no difference. Heavy stuttering in glxgears
> and et
> nice 10 make -j4: Somewhat better but still unusable with et
>
> everything above nice 15 is usable. nic
On Sat, Nov 18, 2006 at 09:49:14AM +0100, Andi Kleen wrote:
> On Friday 17 November 2006 23:37, Vivek Goyal wrote:
> >
> > This patch makes pgtable.h and page.h safe to include
> > in assembly files like head.S. Allowing us to use
> > symbolic constants instead of hard coded numbers when
> > refer
On Sat, Nov 18, 2006 at 09:52:02AM +0100, Andi Kleen wrote:
>
> > - Fixed a bug during resume operation on machines which support NX bit.
> >
> > Your comments/suggestions are welcome.
>
> The patches mostly look good to me. Lots of valuable cleanups too.
>
> But they are clearly .21 material, n
Hello lkml!
Im currently testing 2.6.19-rc5-mm1. Everything works really fine except the
little wart with bad multimedia interactivity with a kernel compiling in the
background. So I tried to narrow it down as much
as possible.
I did several find's,dd's and cats in parrallel and watched four i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I experimented with SyncCE; after starting IrDA I got this:
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ip_tables: (C) 20
On Sat, Nov 18, 2006 at 11:58:14AM +0100, Andi Kleen wrote:
> On Saturday 18 November 2006 11:55, Paul Mackerras wrote:
> > Andi Kleen writes:
> >
> > > On Friday 17 November 2006 23:59, Vivek Goyal wrote:
> > >
> > > > + * Copyright (c) 2006-2007 Vivek Goyal ([EMAIL PROTECTED])
> > >
> > > No
Am Samstag, 18. November 2006 12:43 schrieb Paolo Ornati:
> On Fri, 17 Nov 2006 08:30:08 -0800
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> > > > > APIC error on CPU0: 00(00)
> > > > >
> > > > > Is it an ACPI problem?
> > > >
> > > > a 00 error code? Never seen that ... How frequently does
18 Kas 2006 Cts 12:20 tarihinde, Martin Lorenz şunları yazmıştı:
> Dear James,
>
> I just had some issues when trying to compile ieee80211 1.2.15 together
> with ipw3945 1.1.2 on the latest kernel tree
>
> attached are two patches I had to create to work around it
> I guess they are self-explanato
OpenVZ developers team has encountered the following problem in 2.6.19-rc6
kernel. After some seconds of running script
while [[ 1 ]]
do
find /proc -name mountstats | xargs cat
done
this Oops appears:
BUG: unable to handle kernel NULL pointer dereference at virtual address
0010
p
Ingo Molnar wrote:
i've released the 2.6.18-rc6-rt3 tree
Hi Ingo,
lockdep doesn't compile on UP. per_cpu_offset only makes sense on SMP.
Michal
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 8f6ba22..d46082d 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -1194,8 +1194,13 @@ r
On Saturday 18 November 2006 11:20, Martin Lorenz wrote:
> Dear James,
>
> I just had some issues when trying to compile ieee80211 1.2.15 together
> with ipw3945 1.1.2 on the latest kernel tree
>
> attached are two patches I had to create to work around it
> I guess they are self-explanatory :-)
I
On Sat, 18 Nov 2006 02:09:46 +0100, Folkert van Heusden wrote:
>I found that sometimes processes disappear on some heavily used system
>of mine without any logging. So I've written a patch against 2.6.18.2
>which emits logging when a process emits a fatal signal.
>
>Signed-off-by: Folkert van Heusd
On Fri, 17 Nov 2006 08:30:08 -0800
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > > > APIC error on CPU0: 00(00)
> > > >
> > > > Is it an ACPI problem?
> > >
> > > a 00 error code? Never seen that ... How frequently does it happen?
> >
> > On my x86-64 boxes the "APIC error on CPU0" message a
Greg KH wrote:
> On Fri, Nov 17, 2006 at 04:24:27PM +0100, Stefan Richter wrote:
>> I wrote:
>>> Either the FireWire host's device->klist_children was overwritten before
>>> the call to device_for_each_child
>> or *during* the run of device_for_each_child, which first successfully
>> called nodemgr
On Wed, Nov 15, 2006 at 11:01:00AM -0800, Ray Lee wrote:
> I've come back to my laptop being mostly dead after hours of it being off on
> its own (twice now). Mostly dead meaning the keyboard is nearly
> non-responsive, but the mouse works great (I'm in X, of course). I say 'nearly
> dead' as sysr
Hi to all,
I'm just sending this mail to advise that I get many warnings
during compilation of the kernel. If somebody wants to check
it here is the logs. Maybe can be of some help.
If you need additional info please cc me as I'm not on the list.
config file http://linux.redos.si/kernel/config
On Saturday 18 November 2006 11:55, Paul Mackerras wrote:
> Andi Kleen writes:
>
> > On Friday 17 November 2006 23:59, Vivek Goyal wrote:
> >
> > > + * Copyright (c) 2006-2007 Vivek Goyal ([EMAIL PROTECTED])
> >
> > Normally it's not ok to take sole copyright on code that you mostly copie
1 - 100 of 118 matches
Mail list logo
