Hi!
> If we prove that Windows doesn't use the second either then it means
> they enumerate processors via the DSDT -- which means bringing up
> the ACPI interpreter before bringing up SMP -- and that would require
> a significant change to Linux boot sequence...
Well, as we can do cpu hotplug t
On Wed, 2007-01-31 at 12:52 -0500, Jeff Garzik wrote:
> Ingo Molnar wrote:
> > 19:2413090 0 IO-APIC-fasteoi uhci_hcd:usb2, libata
>
> Yep, that's a good candidate for such experiments :)
Happens to be the same thing, which causes a stale interrupt on the
second suspend/resume cy
Ingo Molnar wrote:
19:2413090 0 IO-APIC-fasteoi uhci_hcd:usb2, libata
Yep, that's a good candidate for such experiments :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >ok. Can you suggest any way for me to reproduce such a bug
> >artificially on a test system? [i have both old and new systems, so
> >if you can think of a way for me to trigger this i'd be happy to try]
>
> Should be pretty easy. With either the old
Ingo Molnar wrote:
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
Easy to name an example, as they are pretty generic. When sharing
irqs -- usually ATA is configured to PCI native (IO-APIC-fasteoi) --
any interrupt storm causes the other devices sharing that irq to crap
themselves (kernel turns of
Hi.
On Tue, 2007-01-30 at 17:01 +0100, Rafael J. Wysocki wrote:
> The freezer in 2.6.20-rc6 should be SMP-safe and the patches to change
> the suspend-resume code ordering are in -mm:
>
> pm-change-code-ordering-in-mainc.patch
> swsusp-change-code-ordering-in-diskc.patch
> swsusp-change-code-orde
Hi,
On Tuesday, 30 January 2007 09:57, Len Brown wrote:
> On Monday 29 January 2007 19:12, Linus Torvalds wrote:
> >
> > On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> > >
> > > Why do you insist on maintaining the wrong initialization order
> > > on resume? When I raised the issue, Len brought
On Monday 29 January 2007 19:12, Linus Torvalds wrote:
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > Why do you insist on maintaining the wrong initialization order
> > on resume? When I raised the issue, Len brought up that the resume
> > order did not match spec, but then there has
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> I /think/ my two patches should automatically avoid the 'cap themselves'
^--crap
> effect you outlined: the absolutely worst case should be that we'll
> have twice the IRQ rate of the optimal
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Easy to name an example, as they are pretty generic. When sharing
> irqs -- usually ATA is configured to PCI native (IO-APIC-fasteoi) --
> any interrupt storm causes the other devices sharing that irq to crap
> themselves (kernel turns off irq, sugge
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Sharing irqs /sucks/. [...]
btw., MSI is not really needed to avoid the sharing of irqs: x86 has 224
IRQ vectors which is abundant for all but the largest boxes. Even the
smallest laptop tends to have an IO-APIC with at least 24 pins - which
is enoug
Ingo Molnar wrote:
btw., it would be great if you could help us here: could you perhaps,
from a past example, outline a specific case of such an ATA/USB IRQ
storm and how it occured (precisely) - and what the fix was? I'd like to
analyze a specific case to make sure the genirq layer recovers fr
* Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i'm wondering, could we go with Thomas' temporary patch that disables
> >sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20.
> >It's not like MSI is a life and death feature. On IO-APIC systems
> >vectors are ab
Ingo Molnar wrote:
i'm wondering, could we go with Thomas' temporary patch that disables
sky2 MSI if CONFIG_PM is enabled - we could revert that after 2.6.20.
It's not like MSI is a life and death feature. On IO-APIC systems
vectors are abundant and in any case we share irqs just fine. The true
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > On one and only one platform. It works fine on others. Don't blame
> > the driver, stop it in PCI.
>
> How sure are you that it's only those Sony laptops?
i'm wondering, could we go with Thomas
On Mon, 29 Jan 2007 16:25:48 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > On one and only one platform. It works fine on others. Don't blame the
> > driver, stop it in PCI.
>
> How sure are you that it's only those Sony lapto
On Mon, 29 Jan 2007, Stephen Hemminger wrote:
>
> On one and only one platform. It works fine on others. Don't blame the
> driver, stop it in PCI.
How sure are you that it's only those Sony laptops?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Mon, 29 Jan 2007 16:12:27 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > Why do you insist on maintaining the wrong initialization order
> > on resume? When I raised the issue, Len brought up that the resume
> > order did not
On Mon, 29 Jan 2007, Stephen Hemminger wrote:
>
> Why do you insist on maintaining the wrong initialization order
> on resume? When I raised the issue, Len brought up that the resume
> order did not match spec, but then there has been slow progress
> in fixing it (it's buried in -mm tree).
It's
On Mon, 29 Jan 2007 15:04:06 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> >
> > MSI works fine for almost all systems (except AMD systems where
> > MSI is broken for ALL devices).
>
> Why do you ignore reality?
>
> MSI does *not*
On Tue, 2007-01-30 at 00:26 +0100, Frédéric Riss wrote:
> > Have you checked the syslog ?
> Yes of course. Nothing interesting.
Just got the same issue on one of my test boxen. Different network card
though. The interface comes up fine, but DNS is not working. ifdown/up
resolves it.
/me keeps an
Le lundi 29 janvier 2007 à 23:57 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 23:50 +0100, Frédéric Riss wrote:
> > > That's probably a userspace problem. Are you using DHCP ?
> >
> > Yep DHCP. Is that a known issue? I never had to reconfigure with older
> > kernels.
>
> Is dhclient r
On Mon, 29 Jan 2007, Stephen Hemminger wrote:
>
> MSI works fine for almost all systems (except AMD systems where
> MSI is broken for ALL devices).
Why do you ignore reality?
MSI does *not* work fine, exactly because the firmware screws it up.
The fact that on a "hardware level" it may work i
On Mon, 2007-01-29 at 23:50 +0100, Frédéric Riss wrote:
> > That's probably a userspace problem. Are you using DHCP ?
>
> Yep DHCP. Is that a known issue? I never had to reconfigure with older
> kernels.
Is dhclient running after resume ? What's the output of ifconfig (before
you do ifdown/up) ?
Le lundi 29 janvier 2007 à 23:45 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 23:38 +0100, Frédéric Riss wrote:
> > I see the same symptoms on my Intel Mac Mini, and reverting the commit
> > also allows the driver to seemingly resume correctly.
> >
> > However after coming out of slee
On Mon, 29 Jan 2007 14:37:23 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 29 Jan 2007, Thomas Gleixner wrote:
> >
> > Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added
> > this hackery in the first place, makes the device survive
> > suspend/resume.
>
On Mon, 2007-01-29 at 23:38 +0100, Frédéric Riss wrote:
> I see the same symptoms on my Intel Mac Mini, and reverting the commit
> also allows the driver to seemingly resume correctly.
>
> However after coming out of sleep I need to reconfigure the network
> interface. No need to rmmod/insmod, ju
Le lundi 29 janvier 2007 à 23:23 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> > Sorry it was against the last patch I sent to Jeff for netdev.
> > Here is against 2.6.20-rc6
>
> Still the same problem. The only difference of this patch to the
> p
On Mon, 29 Jan 2007, Thomas Gleixner wrote:
>
> Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, which added
> this hackery in the first place, makes the device survive
> suspend/resume.
I suspect some BIOSes do *not* screw up the MSI thing on resume, and
others do.
I would suggest
On Mon, 2007-01-29 at 14:23 -0800, Stephen Hemminger wrote:
> > Still the same problem. The only difference of this patch to the
> > previous version is, that the unhandled interrupt message is gone.
> >
> > As I said before:
> >
> > Reverting commit 44ade178249fe53d055fd92113eaa271e06acddd, whic
On Mon, 29 Jan 2007 23:23:21 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> > Sorry it was against the last patch I sent to Jeff for netdev.
> > Here is against 2.6.20-rc6
>
> Still the same problem. The only difference of this pat
On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> Sorry it was against the last patch I sent to Jeff for netdev.
> Here is against 2.6.20-rc6
Still the same problem. The only difference of this patch to the
previous version is, that the unhandled interrupt message is gone.
As I said b
On Mon, 29 Jan 2007 21:10:30 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-01-29 at 11:31 -0800, Stephen Hemminger wrote:
> > Does this fix it?
>
> Don't know.
Sorry it was against the last patch I sent to Jeff for netdev.
Here is against 2.6.20-rc6
---
drivers/net/sky2.c |
On Mon, 2007-01-29 at 11:31 -0800, Stephen Hemminger wrote:
> Does this fix it?
Don't know.
> --- sky2-2.6.orig/drivers/net/sky2.c 2007-01-29 10:05:12.0 -0800
> +++ sky2-2.6/drivers/net/sky2.c 2007-01-29 10:29:56.0 -0800
> @@ -3675,6 +3675,12 @@
> sky2_write32(hw, B0_
Does this fix it?
---
drivers/net/sky2.c | 43 ++-
1 file changed, 18 insertions(+), 25 deletions(-)
--- sky2-2.6.orig/drivers/net/sky2.c2007-01-29 10:05:12.0 -0800
+++ sky2-2.6/drivers/net/sky2.c 2007-01-29 10:29:56.0 -0800
@@ -3675,6
On Sat, 2007-01-27 at 23:44 +0100, Thomas Gleixner wrote:
> > If its a regression, what changeset caused the problem?
>
> Hey. I just discovered that crap. I'm going to bisect tomorrow. Bed time
> here in good old Europe. :)
It seems to be there in 2.6.18 already, although it takes more
suspend/r
On Sat, 2007-01-27 at 17:40 -0500, Jeff Garzik wrote:
> > During the second resume the ATA interrupt gets disabled due to an
> > unhandled interrupt.
> >
> > This is 100% reproducible. So I can provide as much info as needed.
>
> Is this a regression, or behavior that's always been present?
No,
Thomas Gleixner wrote:
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote:
It's been more than a week since -rc5, but I blame everybody (including
me) being away for Linux.conf.au and then me waiting for a few days
afterwards to let everybody sync up.
ata_piix survives exactly one suspen
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote:
> It's been more than a week since -rc5, but I blame everybody (including
> me) being away for Linux.conf.au and then me waiting for a few days
> afterwards to let everybody sync up.
ata_piix survives exactly one suspend resume cylce. Afte
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote:
> It's been more than a week since -rc5, but I blame everybody (including
> me) being away for Linux.conf.au and then me waiting for a few days
> afterwards to let everybody sync up.
Reverting commit 44ade178249fe53d055fd92113eaa271e06acdd
On Wed, 2007-01-24 at 18:58 -0800, Linus Torvalds wrote:
> It's been more than a week since -rc5, but I blame everybody (including
> me) being away for Linux.conf.au and then me waiting for a few days
> afterwards to let everybody sync up.
2.6.20-rc6-git (today) on a dual core laptop:
PM: Prepa
On Thu, Jan 25, 2007 at 10:10:00PM +1100, Eyal Lebedinsky wrote:
> WARNING: "__udivdi3" [fs/ocfs2/ocfs2.ko] undefined!
Doh! This one is almost definitely my fault. Does the attached patch get rid
of that warning for you?
From: Mark Fasheh <[EMAIL PROTECTED]>
ocfs2: fix thinko in ocfs2_backup_sup
> Venkat, I think we should fix this by embedding the flow_cache_genid
> bumps into selinux_netlbl_cache_invalidate() and
> selnl_notify_policyload(), or something like that.
>
Sure. Sending a patch under separate cover in a minute.
> That way we don't have to pepper CONFIG_XFRM ifdefs all over
I should have added that this is on Debian stable:
$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Eyal Lebedinsky wrote:
> i386
> Practically all modules selected.
>
> Building modules, stage 2.
> MODPOST 1931 modules
> WARNING: drivers/atm/fore_200e.o - Section mismatch:
On 1/25/07, Sunil Naidu <[EMAIL PROTECTED]> wrote:
It was a cool booting, have really enjoyed this.
Here is the clean boot for me after spending for good time. Here is
the box info:-
Linux Typhoon 2.6.20-rc6-Akula-II #1 SMP Fri Jan 26 05:33:18 IST 2007
i686 i686 i386 GNU/Linux
I shall test m
From: Michal Piotrowski <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2007 22:05:48 +0100
> It doesn't build for me.
>
> make O=/dir
> [..]
> security/built-in.o: In function `security_set_bools':
> (.text+0x12471): undefined reference to `flow_cache_genid'
> security/built-in.o: In function `security_lo
Hi,
Linus Torvalds napisał(a):
> It's been more than a week since -rc5, but I blame everybody (including
> me) being away for Linux.conf.au and then me waiting for a few days
> afterwards to let everybody sync up.
>
> So there it is, -rc6, hopefully the last -rc of the series.
>
> I'd like eve
On 1/25/07, Sunil Naidu <[EMAIL PROTECTED]> wrote:
It was a cool booting, have really enjoyed this.
I did find this in my dmesg. I have checked the dmesg of 2.6.19.x &
2.6.20-rc series. This is happening every time.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status 0
Linus Torvalds ([EMAIL PROTECTED]) wrote:
>
> It's been more than a week since -rc5, but I blame everybody (including
> me) being away for Linux.conf.au and then me waiting for a few days
> afterwards to let everybody sync up.
>
> So there it is, -rc6, hopefully the last -rc of the series.
Hi,
i386
Practically all modules selected.
Building modules, stage 2.
MODPOST 1931 modules
WARNING: drivers/atm/fore_200e.o - Section mismatch: reference to .init.text:
from .text between 'fore200e_initialize' (at offset 0x25af) and
'fore200e_monitor_putc'
WARNING: drivers/atm/lanai.o - Section
On 1/25/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
It's been more than a week since -rc5, but I blame everybody (including
me) being away for Linux.conf.au and then me waiting for a few days
afterwards to let everybody sync up.
So there it is, -rc6, hopefully the last -rc of the series.
I
Linus Torvalds (4):
Revert "[PATCH] Fix up mmap_kmem"
Clear spurious irq stat information when adding irq handler
Change Linus' email address too
Linux 2.6.20-rc6
Luca Pedrielli (1):
sata_via: add PCI ID 0x5337
Manuel Osdoba (1):
USB: unusual_devs.h e
52 matches
Mail list logo
