Robert Hancock wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s)
and may contain
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential information.
> >Does not apply cleanly against 2.6.20, is this one fixed up right?
> >
> > It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
> >
> > IOW, the forcedeth changes in question are not in 2.6.20, and you need
> > to apply the patch on top of t
fixed up right?
>
> It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
>
> IOW, the forcedeth changes in question are not in 2.6.20, and you need
> to apply the patch on top of the latest batch of forcedeth changes.
Well, it hasn't blown up on me despite bei
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
Seems to solve the problem for me (not heavily tested, but certainly
isn't totally dead as it was before).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROT
Tobias Diedrich wrote:
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
IOW
Tobias Diedrich wrote:
> Ayaz Abdulla wrote:
> > For all those who are having issues, please try out the attached patch.
>
> Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
+0100
+++ linux-
Ayaz Abdulla wrote:
> For all those who are having issues, please try out the attached patch.
Will try.
I reverted to 2.6.19 w/o suspend/resume patch last weekend to make
sure on 2.6.19 forcedeth is stable and noticed something odd:
Because I didn't include the suspend/resume patch I obviously ha
04 Feb 2007 23:13:09 -0600 Robert Hancock <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me
relative to
> >> 2.6.20-rc6. There's no errors in dmesg, but it seem
On Mon, 5 Feb 2007 16:52:24 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 05 Feb 2007 18:35:06 -0600
> Robert Hancock <[EMAIL PROTECTED]> wrote:
>
> > Daniel Barkalow wrote:
> > > On Sun, 4 Feb 2007, Robert Hancock wrote:
> > >
> >
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 07 Feb 2007 00:17:33 +0100
> Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-02-07 at 00:12 +0100, Tilman Schmidt wrote:
> > > > No, not this. Anyway the last patch Thomas forwarded does fix the
> > > > problem.
> > >
> > > Whic
On Tue, 2007-02-06 at 17:12 -0800, Daniel Walker wrote:
> On Wed, 2007-02-07 at 00:36 +0100, Thomas Gleixner wrote:
>
> > There are no other clock event devices in a PC system at the moment
> > and /proc/interrupt does not care, whether the interrupt was setup for a
> > clock event device or somet
I guess I will respond
On Wed, 2007-02-07 at 00:51 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > | If we change the current "timer" entry to be listed as
> > > | "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > > | and replace it with th
On Wed, 2007-02-07 at 00:36 +0100, Thomas Gleixner wrote:
> There are no other clock event devices in a PC system at the moment
> and /proc/interrupt does not care, whether the interrupt was setup for a
> clock event device or something else. It displays the name which is
> given in the irqaction
On Wed, 07 Feb 2007 00:17:33 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-07 at 00:12 +0100, Tilman Schmidt wrote:
> > > No, not this. Anyway the last patch Thomas forwarded does fix the
> > > problem.
> >
> > Which one would that be? I might try it for comparison.
>
> Find
On Tuesday 06 February 2007 6:28 pm, Daniel Walker wrote:
> On Tue, 2007-02-06 at 18:15 -0500, Rob Landley wrote:
> > On Tuesday 06 February 2007 3:40 pm, Daniel Walker wrote:
> > > In this case "different" goes into userspace .. So different could mean
> > > userspace regression, which is somethin
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > | If we change the current "timer" entry to be listed as
> > | "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > | and replace it with the count from LOC
> >
> > this is a pretty clear sentence, i dont think i misunderstood
> >
On Tue, 2007-02-06 at 15:35 -0800, Daniel Walker wrote:
> Last and final correction. I'm saying drop the timer entry, which means
> drop the call to request_irq() for irq0.
Right, that's a real good suggestion. Here's the patch especially for
you. Apply it and figure out yourself, why your compute
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > > > the kernel simply displays reality: IRQ#0 isnt increasing
> > > > because it's not used, and LOC (local apic timers) is
> > > > increasing.
> > >
> > > What about the statistics for the other interrupts in the system ?
> > > It clearly doesn'
On Wed, 2007-02-07 at 00:28 +0100, Ingo Molnar wrote:
> actually, i quoted what you said:
>
> | If we change the current "timer" entry to be listed as "lapic-timer"
> | and not "IO-APIC-edge" (or one of the other names) and replace it with
> | the count from LOC
>
> this is a pretty clear sent
On Tue, 2007-02-06 at 15:22 -0800, Daniel Walker wrote:
> > > What about the statistics for the other interrupts in the system ? It
> > > clearly doesn't list all interrupts in the system .
> >
> > what is your point?
>
> Isn't the listing inconsistent ? /proc/interrupts only showing some
> spe
On Tue, 2007-02-06 at 18:15 -0500, Rob Landley wrote:
> On Tuesday 06 February 2007 3:40 pm, Daniel Walker wrote:
> > In this case "different" goes into userspace .. So different could mean
> > userspace regression, which is something that we don't want. I have no
> > idea if any apps use /proc/int
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-07 at 00:14 +0100, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> > >
> > > > changing the current 'timer' entry (which is line 2 of
> > > > /proc/i
On Wed, 2007-02-07 at 00:14 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> >
> > > changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> > > to be 'listed as lapic-timer' and to 'replace it
On Wed, 2007-02-07 at 00:12 +0100, Tilman Schmidt wrote:
> > No, not this. Anyway the last patch Thomas forwarded does fix the
> > problem.
>
> Which one would that be? I might try it for comparison.
Find the combined patch of all fixlets on top of -mm3 below.
tglx
Index: linux-2.6.20/k
On Tuesday 06 February 2007 3:40 pm, Daniel Walker wrote:
> In this case "different" goes into userspace .. So different could mean
> userspace regression, which is something that we don't want. I have no
> idea if any apps use /proc/interrupts , but it's possible since it's
> been around for a lon
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
>
> > changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> > to be 'listed as lapic-timer' and to 'replace it with the count from
> > LOC' is faking a count in a line where
ick - which until now was a hidden wart but became
>> an explicit bug under dynticks. Maybe this is what is slowing down your
>> box.
I have the same problem (huge delay when loading iptables) with
2.6.20-rc6-mm3, and for me this patch did fix it.
> No, not this. Anyway the last
On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> to be 'listed as lapic-timer' and to 'replace it with the count from
> LOC' is faking a count in a line where nothing like that should be.
This point is getting irr
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-02-06 at 23:08 +0100, Ingo Molnar wrote:
>
> > sorry but that's precisely what your suggestion above results in:
>
> I'm not trying to suggest we "fake" anything. Your just
> misunderstanding me.. [...]
as i pointed it out in the previ
On Tue, 2007-02-06 at 23:08 +0100, Ingo Molnar wrote:
> sorry but that's precisely what your suggestion above results in:
I'm not trying to suggest we "fake" anything. Your just misunderstanding
me.. I'm am suggesting we change LOC to something readable. If you think
we're "faking" something by d
On Tue, 2007-02-06 at 13:54 -0800, Daniel Walker wrote:
> > The same happens when say a network driver implements NAPI: the IRQ
> > count goes way, way down. Or if a driver starts supporing MSI - the IRQ
> > line even moves to another one. Do we try to fix those counts up to
> > match the 'previ
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > > If we change the current "timer" entry to be listed as
> > > "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > > and replace it with the count from LOC
[...]
> > But, as per the previous mails, the new behavior is just fine,
>
On Tue, 2007-02-06 at 22:43 +0100, Thomas Gleixner wrote:
> > I think the regression (if you can call it that) is not scripts
> > crashing, but more people not know what's going on with there system ..
>
> I did not hear a complaint of anyone except you. I doubt that there will
> be a big confus
On Tue, 2007-02-06 at 22:41 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > we could make this clearer by renaming 'LOC' (which stands for
> > > 'LOCal timer interupts' and was added [and misnamed] by yours truly
> > > many moons ago) to 'apic-timer' and 'timer' to
On Tue, 2007-02-06 at 13:23 -0800, Daniel Walker wrote:
> > we could make this clearer by renaming 'LOC' (which stands for 'LOCal
> > timer interupts' and was added [and misnamed] by yours truly many moons
> > ago) to 'apic-timer' and 'timer' to 'PIT-timer' but /that/ would be more
> > of a user
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > we could make this clearer by renaming 'LOC' (which stands for
> > 'LOCal timer interupts' and was added [and misnamed] by yours truly
> > many moons ago) to 'apic-timer' and 'timer' to 'PIT-timer' but
> > /that/ would be more of a userspace visib
On Tue, 2007-02-06 at 22:17 +0100, Thomas Gleixner wrote:
> > The reason that I'm bringing it up at all is because people have ask me
> > "Why isn't my timer ticking??"
>
> So it's a problem of user perception and not of a user space regression.
> Please stop confusing things.
At least we agree
On Tue, 2007-02-06 at 22:09 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > it's quite easy to explain: because of the new dynticks feature.
> > > Both 'timer' and 'LOC' counts go way down.
> >
> > I don't have that enabled tho .. This is with HRT/dynamic tick both
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > I don't have that enabled tho .. This is with HRT/dynamic tick both
> > off..
>
> your kernel utilizes the kernel in a more optimal way: the new
^hardware
> clockevents code now utilizes the loc
On Tue, 2007-02-06 at 12:40 -0800, Daniel Walker wrote:
> > Yes, it is different. Why are you insisting, that something is a problem
> > just because it is different ?
>
> In this case "different" goes into userspace .. So different could mean
> userspace regression, which is something that we don
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > it's quite easy to explain: because of the new dynticks feature.
> > Both 'timer' and 'LOC' counts go way down.
>
> I don't have that enabled tho .. This is with HRT/dynamic tick both
> off..
your kernel utilizes the kernelin a more optimal way:
On Tue, 2007-02-06 at 21:52 +0100, Ingo Molnar wrote:
> Well, if you enable dynticks you should expect the number of timer irqs
> to go down. There's no problem here.
Ok .
> > The reason that I'm bringing it up at all is because people have ask
> > me "Why isn't my timer ticking??"
>
> it's q
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-02-06 at 21:20 +0100, Thomas Gleixner wrote:
> > On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > > > What kind of artificial problem are you creating here ?
> > >
> > > I'm not trying to create anything .. However, as I said be
On Tue, 2007-02-06 at 21:20 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > > What kind of artificial problem are you creating here ?
> >
> > I'm not trying to create anything .. However, as I said before
> > the /proc/interrupts "timer" entry doesn't wor
On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > What kind of artificial problem are you creating here ?
>
> I'm not trying to create anything .. However, as I said before
> the /proc/interrupts "timer" entry doesn't work the same as it has in
> other kernels.
Yes, it is different. Why
On Tue, 2007-02-06 at 20:07 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 10:45 -0800, Daniel Walker wrote:
> > > > -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> > > > related ..
> > >
> > > And why should it increment ? Is there a rule that it has to ?
> >
> >
On Tue, Feb 06, 2007 at 05:48:26PM +0100, Ingo Molnar wrote:
>
> Mattia,
>
> * Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > > I have it halfways reproducible now and I'm working to find the root
> > > cause. Thanks for providing the info.
> >
> > Great, I'm obviously available to test any p
On Tue, 2007-02-06 at 10:45 -0800, Daniel Walker wrote:
> > > -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> > > related ..
> >
> > And why should it increment ? Is there a rule that it has to ?
>
> I don't know .. I would imagine some users might look at it and wonder
On Tue, 2007-02-06 at 19:36 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 08:03 -0800, Daniel Walker wrote:
> > It appears there a problem with the /proc/interrupts entry for
> > "timer" .. It doesn't increment anymore .. This problem exists in the
> > -rt tree also .. I haven't done a bise
On Tue, 2007-02-06 at 08:03 -0800, Daniel Walker wrote:
> It appears there a problem with the /proc/interrupts entry for
> "timer" .. It doesn't increment anymore .. This problem exists in the
> -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> related ..
And why should it
Mattia,
* Mattia Dongili <[EMAIL PROTECTED]> wrote:
> > I have it halfways reproducible now and I'm working to find the root
> > cause. Thanks for providing the info.
>
> Great, I'm obviously available to test any patch :)
Could you try the patch below? The RCU serialization code (a rare call
It appears there a problem with the /proc/interrupts entry for
"timer" .. It doesn't increment anymore .. This problem exists in the
-rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
related ..
Also my NMI watchdog isn't functioning , which also exists in the -rt
tree, and -
On Mon, 05 Feb 2007 20:55:35 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Seeing these BUGs on 2.6.20-rc6-mm3 when mounting an NTFS partition. I
> saw some reports of something like this on -mm1, was this supposed to be
> patched already?
>
> BUG: at arch/i386/mm/hig
Seeing these BUGs on 2.6.20-rc6-mm3 when mounting an NTFS partition. I
saw some reports of something like this on -mm1, was this supposed to be
patched already?
BUG: at arch/i386/mm/highmem.c:52 kmap_atomic()
[] kmap_atomic+0xb4/0x1cd
[] ntfs_end_buffer_async_read+0x276/0x2db [ntfs
On Mon, 05 Feb 2007 18:35:06 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Daniel Barkalow wrote:
> > On Sun, 4 Feb 2007, Robert Hancock wrote:
> >
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
> >> 2.6.20-rc6. There&#
Daniel Barkalow wrote:
On Sun, 4 Feb 2007, Robert Hancock wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address. I tried revert
On Mon, Feb 05 2007, Christoph Lameter wrote:
> On Mon, 5 Feb 2007, Jens Axboe wrote:
>
> > But for now this is just a debug test, can you see if xfs with barriers
> > for that kernel now works as expected?
>
> The kernel that failed before boots fine with this patch.
Wonderful, I'll leave the p
On Mon, 5 Feb 2007, Jens Axboe wrote:
> But for now this is just a debug test, can you see if xfs with barriers
> for that kernel now works as expected?
The kernel that failed before boots fine with this patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Dave Jones wrote:
On Mon, Feb 05, 2007 at 01:56:22PM +0100, Thomas Hellström wrote:
> Dave Jones wrote:
> > On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> > > On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > > > Eric,
> > > > Sorry for the breakage
On Mon, Feb 05, 2007 at 01:56:22PM +0100, Thomas Hellström wrote:
> Dave Jones wrote:
> > On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> > > On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > > > Eric,
> > > > Sorry for the breakage. Can you try the at
Dave Jones wrote:
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > Eric,
> > Sorry for the breakage. Can you try the attached patch and see if it
> > fixes the problem.
> >
> > /Thomas
>
> Thomas,
On Mon, Feb 05 2007, Jens Axboe wrote:
> On Mon, Feb 05 2007, Jens Axboe wrote:
> > On Thu, Feb 01 2007, Christoph Lameter wrote:
> > > On Thu, 1 Feb 2007, Jens Axboe wrote:
> > >
> > > > That looks like barriers, could you try with those disabled? Sorry for
> > > > making you go through this, I c
On Mon, Feb 05 2007, Jens Axboe wrote:
> On Thu, Feb 01 2007, Christoph Lameter wrote:
> > On Thu, 1 Feb 2007, Jens Axboe wrote:
> >
> > > That looks like barriers, could you try with those disabled? Sorry for
> > > making you go through this, I can't debug and fix it myself before
> > > monday.
>
On Thu, Feb 01 2007, Christoph Lameter wrote:
> On Thu, 1 Feb 2007, Jens Axboe wrote:
>
> > That looks like barriers, could you try with those disabled? Sorry for
> > making you go through this, I can't debug and fix it myself before
> > monday.
>
> Disabling barriers + your patch works. Modified
On Sun, 4 Feb 2007, Robert Hancock wrote:
> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
> received and so the machine can't get an IP address. I tried reverting all the
On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> >
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relati
Andrew Morton wrote:
On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can
On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
> received and so the machine can
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address. I tried reverting
all the -mm changes to drivers/net/forcedeth.c, which didn'
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > Eric,
> > Sorry for the breakage. Can you try the attached patch and see if it
> > fixes the problem.
> >
> > /Thomas
>
> Thomas,
>
> Thanks! That s
On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> Eric,
> Sorry for the breakage. Can you try the attached patch and see if it
> fixes the problem.
>
> /Thomas
Thomas,
Thanks! That seems to fix it:
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt :01:00.0[A] -> GS
Eric Buddington wrote:
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
What AGP chipset do you have? it looks like it might be caused by the
AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI bridg
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
> What AGP chipset do you have? it looks like it might be caused by the
> AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI bridge: Silicon Integrated Systems [S
hwmon i2c_isa i2c_core sis_agp agpgart ide_scsi
CPU:0
EIP:0060:[<>]Not tainted VLI
EFLAGS: 00013246 (2.6.20-rc6-mm3 #1)
EIP is at 0x0
eax: f5e6f2e0 ebx: ecx: f928eda0 edx:
esi: f5e6f2e0 edi: f3604be0 ebp: 4000 esp: f2c2feb0
ds: 007b es
On Sat, Feb 03, 2007 at 04:22:17PM -0500, Lee Revell wrote:
> On 2/3/07, Eric Buddington <[EMAIL PROTECTED]> wrote:
> >EIP:0060:[<>]Tainted: G M VLI
> >EFLAGS: 00013246 (2.6.20-rc6-mm3 #1)
>
> The "M" taint flag indicates that a ma
On 2/3/07, Eric Buddington <[EMAIL PROTECTED]> wrote:
EIP:0060:[<>]Tainted: G M VLI
EFLAGS: 00013246 (2.6.20-rc6-mm3 #1)
The "M" taint flag indicates that a machine check exception has
occured. Check your logs for the MCE and make sure the har
While repeatedly recompiling and restarting xorg-server-1.1.1, I
managed to generate the following BUG. Kernel is 2.6.20-rc6-mm3, video card is
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 Pro Ultra TF
(prog-if 00 [VGA])
-Eric
--
BUG: unable
Hi!
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > Serial port console is off here and the jiffies update fix doesn't
> > make a noticeable difference.
>
> ok, this eliminates my serial port theory.
>
> and this means i'm having trouble reproducing this problem locally.
> Maybe i tried it
ric Le Goater [mailto:[EMAIL PROTECTED]
>Sent: Saturday, February 03, 2007 10:30 AM
>To: Cedric Le Goater
>Cc: Starikovskiy, Alexey Y; Andrew Morton;
linux-kernel@vger.kernel.org;
>Moore, Robert; keith mannthey
>Subject: Re: 2.6.20-rc6-mm3
>
>Cedric Le Goater wrote:
>> Star
manager ...
dmesg looks fine. However, there is a :
ACPI Warning (tbfadt-0415): Optional field "Gpe1Block" has zero address or
length: /4 [20070126]
but I don't know how to interpret this ? Any Idea ?
thanks,
C.
Linux version 2.6.20-rc6-mm3-lxc2-autokern
On Fri, Feb 02, 2007 at 09:27:14PM +0100, Thomas Gleixner wrote:
> On Fri, 2007-02-02 at 20:18 +0100, Mattia Dongili wrote:
> > > May I ask you for another test ? Please turn on high resolution timers
> > > and check, if the same strange behaviour is happening.
> >
> > Yep, here we go again. Still
On Fri, 2007-02-02 at 20:18 +0100, Mattia Dongili wrote:
> > May I ask you for another test ? Please turn on high resolution timers
> > and check, if the same strange behaviour is happening.
>
> Yep, here we go again. Still seeing long stalls but no negative expires
> offset.
> Actually one more t
#x27;t
generate all that strangeness/slowness...
Dmesg with iptables script enabled:
[0.00] Linux version 2.6.20-rc6-mm3-1 ([EMAIL PROTECTED]) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #8 SMP Fri Feb 2 10:26:07 CET
2007
[0.00] BIOS-provided physical RAM map:
[
On Mon, 2007-01-29 at 20:45 -0800, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/
>
I w
Starikovskiy, Alexey Y wrote:
>> so it probably means that drivers/acpi/tables/tbxfroot.c is
>> obsolete ?
> Yes.
>>> Could you please try it?
>> sure, I'll cancel the current boot test in which I was using
>> acpi_find_root_pointer() in tbxfroot.c and restart one with your
>> new patch. I should h
>so it probably means that drivers/acpi/tables/tbxfroot.c is
>obsolete ?
Yes.
>
>> Could you please try it?
>
>sure, I'll cancel the current boot test in which I was using
>acpi_find_root_pointer() in tbxfroot.c and restart one with your
>new patch. I should have the result today.
How long does it
Hello !
Starikovskiy, Alexey Y wrote:
> Hi,
> I updated patch to use acpi_find_rsdp(), as all other code does.
so it probably means that drivers/acpi/tables/tbxfroot.c is
obsolete ?
> Could you please try it?
sure, I'll cancel the current boot test in which I was using
acpi_find_root_pointer(
lexey Y; Andrew Morton;
linux-kernel@vger.kernel.org;
>Moore, Robert; keith mannthey
>Subject: Re: 2.6.20-rc6-mm3
>
>Cedric Le Goater wrote:
>> Starikovskiy, Alexey Y wrote:
>>> Sorry, here is the patch... ACPI has switched to acpi_find_rsdp(),
so
>>> srat.c mi
On Fri, Feb 02 2007, David Chinner wrote:
> On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> > That down() probably wants a replug to precede it. Probably something
> > like:
> >
> > if (atomic_read(&bp->b_io_remaining))
> > blk_replug_current_nested();
> >
>
On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> That down() probably wants a replug to precede it. Probably something
> like:
>
> if (atomic_read(&bp->b_io_remaining))
> blk_replug_current_nested();
>
> for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this f
I just noticed this in my logs, from the lock checker:
[ 142.299455]
[ 142.299458] ===
[ 142.299473] [ INFO: possible circular locking dependency detected ]
[ 142.299478] 2.6.20-rc6-mm3 #2
[ 142.299482
On Thu, 1 Feb 2007, Jens Axboe wrote:
> That looks like barriers, could you try with those disabled? Sorry for
> making you go through this, I can't debug and fix it myself before
> monday.
Disabling barriers + your patch works. Modified /etc/fstab and added a
nobarrier option to the root filesy
Mattia,
On Thu, 2007-02-01 at 22:11 +0100, Mattia Dongili wrote:
> > It might be helpful if you could try with your original config again.
> > Please enable printk timestamps and SysRq. Once the slowness kicks in
> > please issue a SysRq-Q, so we can look at the internal state of the tick
> > code
helpful if you could try with your original config again.
> Please enable printk timestamps and SysRq. Once the slowness kicks in
> please issue a SysRq-Q, so we can look at the internal state of the tick
> code.
BTW: booting with clocksource=pmtmr make it proceed a little better but
I still
1 21:57:11 CET 2007
Thu Feb 1 21:57:15 CET 2007
Thu Feb 1 21:57:21 CET 2007
Thu Feb 1 21:57:25 CET 2007
dmesg:
[0.00] Linux version 2.6.20-rc6-mm3-1 ([EMAIL PROTECTED]) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 SMP Thu Feb 1 21:44:52 CET
2007
[0.000
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `get_memcfg_from_srat':
/home/legoater/linux/2.6.20-rc6-mm3/arch/i386/kernel/srat.c:279: undefined
reference to `a
Starikovskiy, Alexey Y wrote:
> Sorry, here is the patch... ACPI has switched to acpi_find_rsdp(), so
> srat.c might want to do that too, please check.
got it. running a compile and boot test.
I should have the results in 'my' morning (UTC+1).
Thanks !
C.
-
To unsubscribe from this list: send
On Thu, Feb 01 2007, Christoph Lameter wrote:
> On Thu, 1 Feb 2007, Jens Axboe wrote:
>
> > for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this fix it?
>
> No it still hangs consistently. This time at an earlier spot.
That looks like barriers, could you try with those disabled? Sorry for
maki
On Thu, Feb 01, 2007 at 08:36:12PM +0100, Thomas Gleixner wrote:
> On Thu, 2007-02-01 at 00:21 +0100, Mattia Dongili wrote:
> > yes, slowness is gone. Any useful information I can provide?
>
> Can you please try with CONFIG_ACPI_PROCESSOR=y instead of =m ? This
> should make the slowness go away
1 - 100 of 147 matches
Mail list logo
