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
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
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
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
* 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
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
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 off
* 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-IDE
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
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 cycle.
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
>
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
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,
* 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
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
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
* 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 enough
* 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, suggests
* 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 one
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 been slow
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 up that the
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
* 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
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
* 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
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
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
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
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).
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
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
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
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,
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
>
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,
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
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
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,
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
@@
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
@@
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,
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 | 43
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
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 patch to
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, which added
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
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
previous
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.
I suspect
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, just
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 sleep I need
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) ? Have
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 is
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 running
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
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* work fine,
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 not
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 match spec,
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 in
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 laptops?
I do
* 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'
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
* 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 abundant and
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
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 44ade178249fe53d055fd92113eaa271e06acddd
72 matches
Mail list logo
