On Tue, 2005-08-02 at 12:56 +0200, Pavel Machek wrote:
> Hi!
>
> > > Also, as I said earlier, the better we support OSPM initiated power
> > > management, the more likely APM will break. This may be technically
> > > unavoidable on some isolated boxes without quirks. I agree with
> > > Pavel tha
Hi!
> > But that believe would be total fantasy -- supsend/resume is not
> > working on a large number of machines, and no distro is currently
> > able to support it. (I'm talking about S3 suspend to RAM primarily,
> > suspend to disk is less interesting -- though Red Hat doesn't
> > even su
Hi!
> > Also, as I said earlier, the better we support OSPM initiated power
> > management, the more likely APM will break. This may be technically
> > unavoidable on some isolated boxes without quirks. I agree with
> > Pavel that "do nothing" may make sense, but it seems some devices
> > may st
On Monday, 1 of August 2005 22:34, Hugh Dickins wrote:
> On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> > On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote:
> > >
> > > Linus has apparently dropped that patch for yenta, but in case it is
> > > reintroduced in the future you will probably
Hi,
On Monday, 1 of August 2005 04:06, Andrew Morton wrote:
> Shaohua Li <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > > In general, I think that calling free_irq is the right behavior.
> > > Although irqs changing after suspend is rare, there are also some
> > > more serious issues. This has been d
On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote:
> >
> > Linus has apparently dropped that patch for yenta, but in case it is
> > reintroduced in the future you will probably need a patch to make the
> > network
> > driver cooperate. I'll
On Sat, 2005-07-30 at 14:10 -0700, Linus Torvalds wrote:
>
> On Sat, 30 Jul 2005, Russell King wrote:
> >
> > I don't think so - I believe one of the problem cases is where you
> > have a screaming interrupt caused by an improperly setup device.
>
> Not a problem.
>
> The thing is, this is triv
On Sun, 2005-07-31 at 23:20 +0200, Pavel Machek wrote:
> Hi!
>
> > Also I'd like to point out that this patch broke APM suspend-to-ram,
> > not ACPI S3. IMO, it may not be possible to support both APM and ACPI
> > on every system, as their specs are not intended to be compatible.
> > Progress tow
On Sun, 2005-07-31 at 23:03 -0400, [EMAIL PROTECTED] wrote:
> Also, as I said earlier, the better we support OSPM initiated power
> management, the more likely APM will break. This may be technically
> unavoidable on some isolated boxes without quirks. I agree with
> Pavel that "do nothing" may
Brown, Len <[EMAIL PROTECTED]> wrote:
> But that believe would be total fantasy -- supsend/resume is not
> working on a large number of machines, and no distro is currently
> able to support it. (I'm talking about S3 suspend to RAM primarily,
> suspend to disk is less interesting -- though Red Ha
Hi!
> > > Why do it _ever_? There is _zero_ upside to doing it, I don't see why you
> > > want to.
> >
> > Being able to turn off your soundcard at runtime when you are not
> > using it was one of examples...
>
> I meant the "ACPI restores irq controller state" thing.
>
> Just leave it in. The
Hi!
> > > In general, I think that calling free_irq is the right behavior.
> > > Although irqs changing after suspend is rare, there are also some
> > > more serious issues. This has been discussed in the past, and a
> > > summary is as follows:
> >
> > irqs actually isn't changed after suspend c
Hi!
> > You said earlier we only should fix drivers that need fixing, but they
> > all need fixing
>
> I think you're still talking from a theoretical standpoing, while all my
> arguments are practical.
>
> In _practice_, I hope that
>
> (a) we don't see that very much (ie the people for whom
> slow and steady progress
The oscillations are indeed discouraging. For S3 sleep/wake on my TP
600X:
2.6.11.4: works well (the console was hosed with jittering text, but
X restores fine), which hugely improved using my laptop.
2.6.12.3: ditto
But:
2.6.13-rc3
On Sun, 31 Jul 2005 [EMAIL PROTECTED] wrote:
>
> We either need to change every driver to free irqs or "harden" each
> of them.
No. No "either".
Drivers need to be safe from the hw going away, whether it be physically
or because it got shut down.
> Freeing irqs obviously seems easier.
No
- Original Message -
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sunday, July 31, 2005 9:07 pm
Subject: Re: revert yenta free_irq on suspend
>
>
> On Mon, 1 Aug 2005, Dave Airlie wrote:
> >
> > You said earlier we only should fix drivers that need fi
On Sun, 2005-07-31 at 19:06 -0700, Andrew Morton wrote:
> Shaohua Li <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > > In general, I think that calling free_irq is the right behavior.
> > > Although irqs changing after suspend is rare, there are also some
> > > more serious issues. This has been discus
Shaohua Li <[EMAIL PROTECTED]> wrote:
>
> Hi,
> > In general, I think that calling free_irq is the right behavior.
> > Although irqs changing after suspend is rare, there are also some
> > more serious issues. This has been discussed in the past, and a
> > summary is as follows:
>
> irqs actually
Hi,
> In general, I think that calling free_irq is the right behavior.
> Although irqs changing after suspend is rare, there are also some
> more serious issues. This has been discussed in the past, and a
> summary is as follows:
irqs actually isn't changed after suspend currently, it's a consider
On Mon, 1 Aug 2005, Dave Airlie wrote:
>
> You said earlier we only should fix drivers that need fixing, but they
> all need fixing
I think you're still talking from a theoretical standpoing, while all my
arguments are practical.
In _practice_, I hope that
(a) we don't see that very much (i
> On Mon, 1 Aug 2005, Dave Airlie wrote:
> >
> > That still doesn't handle the case where a device has an interrupt
> > handler on a shared IRQ and another device on the chain interrupts it
> > after it has suspended its device,
>
> I don't know why people bother arguing about this. Face the facts
On Mon, 1 Aug 2005, Dave Airlie wrote:
>
> That still doesn't handle the case where a device has an interrupt
> handler on a shared IRQ and another device on the chain interrupts it
> after it has suspended its device,
I don't know why people bother arguing about this. Face the facts: we have
Dave Jones wrote:
> On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote:
>
> > gringo:~ # fdisk -l /dev/hda
> >
> > Disk /dev/hda: 80.0 GB, 80026361856 bytes
> > 255 heads, 63 sectors/track, 9729 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> >
> >Devic
On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote:
> gringo:~ # fdisk -l /dev/hda
>
> Disk /dev/hda: 80.0 GB, 80026361856 bytes
> 255 heads, 63 sectors/track, 9729 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
>Device Boot Start End Blocks
Dave Jones wrote:
> On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote:
>
> > But that believe would be total fantasy -- supsend/resume is not
> > working on a large number of machines, and no distro is currently
> > able to support it. (I'm talking about S3 suspend to RAM primarily,
>
>
> If an interrupt is screaming due to lack of initialization and gets turned
> off, just make sure it gets re-enabled when it is being initialized.
>
That still doesn't handle the case where a device has an interrupt
handler on a shared IRQ and another device on the chain interrupts it
after i
On Mon, 1 Aug 2005, Pavel Machek wrote:
> >
> > Why do it _ever_? There is _zero_ upside to doing it, I don't see why you
> > want to.
>
> Being able to turn off your soundcard at runtime when you are not
> using it was one of examples...
I meant the "ACPI restores irq controller state" thing
Hi!
> > Ok, so we'll keep adding those free_irq/request_irq pairs
>
> I would suggest doing so only if you have a case where it can matter.
>
> > and re-introduce that ACPI change when we are ready?
>
> Why do it _ever_? There is _zero_ upside to doing it, I don't see why you
> want to.
Being
On Mon, 1 Aug 2005, Pavel Machek wrote:
>
> Ok, so we'll keep adding those free_irq/request_irq pairs
I would suggest doing so only if you have a case where it can matter.
> and re-introduce that ACPI change when we are ready?
Why do it _ever_? There is _zero_ upside to doing it, I don't see
> >
> > In general, I think that calling free_irq is the right behavior.
>
> I DO NOT CARE!
>
> It breaks hundreds of drivers. End of discussion.
>
> You can do the free_irq() and request_irq() changes _without_ breaking
> hundreds of drivers by just doing one driver at a time.
>
So are driver
Hi!
> > In general, I think that calling free_irq is the right behavior.
>
> I DO NOT CARE!
>
> It breaks hundreds of drivers. End of discussion.
>
> You can do the free_irq() and request_irq() changes _without_ breaking
> hundreds of drivers by just doing one driver at a time.
>
> And if AC
On Sun, 31 Jul 2005 [EMAIL PROTECTED] wrote:
>
> In general, I think that calling free_irq is the right behavior.
I DO NOT CARE!
It breaks hundreds of drivers. End of discussion.
You can do the free_irq() and request_irq() changes _without_ breaking
hundreds of drivers by just doing one driv
On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote:
> But that believe would be total fantasy -- supsend/resume is not
> working on a large number of machines, and no distro is currently
> able to support it. (I'm talking about S3 suspend to RAM primarily,
> suspend to disk is less in
Hi!
> Also I'd like to point out that this patch broke APM suspend-to-ram,
> not ACPI S3. IMO, it may not be possible to support both APM and ACPI
> on every system, as their specs are not intended to be compatible.
> Progress toward proper suspend-to-ram support will, in many cases, be
> a small
- Original Message -
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sunday, July 31, 2005 11:53 am
Subject: Re: revert yenta free_irq on suspend
>
>
> On Sun, 31 Jul 2005, Pavel Machek wrote:
> >
> > Well, on some machines interrupts can change during s
On Sunday, 31 of July 2005 01:09, Rafael J. Wysocki wrote:
> On Sunday, 31 of July 2005 00:24, Hugh Dickins wrote:
> > On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> > > On Saturday, 30 of July 2005 23:32, Hugh Dickins wrote:
> > > > On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
> > > > >
> > > >
On Sun, 31 Jul 2005, Linus Torvalds wrote:
>
> We'll revert to the behaviour that it has traditionally had, and start
> working forwards in a more careful manner. Where we don't break working
> setups.
Here's a suggested revert (a pure "patch -R" won't work, since there's
been other differen
On Sun, 31 Jul 2005, Pavel Machek wrote:
>
> Well, on some machines interrupts can change during suspend (or so I
> was told). I did not like the ACPI change at one point, but it is very
> wrong to revert PCMCIA fix without also fixing ACPI interpretter.
We _are_ going to fix the ACPI interpret
Hi!
> > Please revert the yenta free_irq on suspend patch (below)
> > which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
>
> Ok. Will do.
> And the ACPI people had better stop doing this crazy thing in the first
> place. There's really no point at all to freeing and re-requesting the
> interrup
On Sunday, 31 of July 2005 07:03, Brown, Len wrote:
> >So I guess I'll just have to revert the ACPI change that
> >caused drivers to do request_irq/free_irq. I'd prefer it
> >if the ACPI people did that revert themselves, though.
>
> If that is what you want, I'll be happy to do it.
>
> If one b
On Sun, 31 Jul 2005, Brown, Len wrote:
>
> If one believes that suspend/resume is working on a large number of
> systems -- working to a level that a distro can acutally support it,
> then restoring our temporary resume IRQ router hack to make many systems
> work is clearly the right thing to do
>So I guess I'll just have to revert the ACPI change that
>caused drivers to do request_irq/free_irq. I'd prefer it
>if the ACPI people did that revert themselves, though.
If that is what you want, I'll be happy to do it.
If one believes that suspend/resume is working on a large number of
system
On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
>
> Well, they have _already_ been screwed by the following patch that went
> to your tree with the ACPI update. If you drop it, all problems related to
> freeing/requesting IRQs on suspend/resume will be gone.
Yes. I really think we need to revert
On Sunday, 31 of July 2005 00:24, Hugh Dickins wrote:
> On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> > On Saturday, 30 of July 2005 23:32, Hugh Dickins wrote:
> > > On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
> > > >
> > > > Could you please send the /proc/interrupts from your box?
> > >
> >
On Saturday, 30 of July 2005 23:10, Linus Torvalds wrote:
>
> On Sat, 30 Jul 2005, Russell King wrote:
> >
> > I don't think so - I believe one of the problem cases is where you
> > have a screaming interrupt caused by an improperly setup device.
>
> Not a problem.
>
> The thing is, this is tri
On Sun, 31 Jul 2005, Rafael J. Wysocki wrote:
> On Saturday, 30 of July 2005 23:32, Hugh Dickins wrote:
> > On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
> > >
> > > Could you please send the /proc/interrupts from your box?
> >
> > 11: 57443 XT-PIC yenta, yenta, eth0
>
> Thanks.
On Saturday, 30 of July 2005 23:32, Hugh Dickins wrote:
> On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
> >
> > Well, the patch is needed on other boxes too (eg. mine :-)) due to the
> > recent
> > changes in ACPI.
> >
> > Could you please send the /proc/interrupts from your box?
>
>
On Sat, Jul 30, 2005 at 02:10:41PM -0700, Linus Torvalds wrote:
> On Sat, 30 Jul 2005, Russell King wrote:
> > I don't think so - I believe one of the problem cases is where you
> > have a screaming interrupt caused by an improperly setup device.
>
> Not a problem.
>
> The thing is, this is trivi
On Sat, 30 Jul 2005, Rafael J. Wysocki wrote:
>
> Well, the patch is needed on other boxes too (eg. mine :-)) due to the recent
> changes in ACPI.
>
> Could you please send the /proc/interrupts from your box?
CPU0
0:2818513 XT-PIC timer
1: 56790
On Saturday, 30 of July 2005 22:54, Russell King wrote:
> On Sat, Jul 30, 2005 at 01:36:24PM -0700, Linus Torvalds wrote:
> > On Sat, 30 Jul 2005, Russell King wrote:
> > >
> > > What this probably means is that we need some way to turn off interrupts
> > > from devices on suspend, and on resume,
On Sat, 30 Jul 2005, Russell King wrote:
>
> I don't think so - I believe one of the problem cases is where you
> have a screaming interrupt caused by an improperly setup device.
Not a problem.
The thing is, this is trivially solved by
- disable irq controller last on shutdown
- re-enable ir
On Saturday 30 July 2005 22.49, Rafael J. Wysocki wrote:
> On Saturday, 30 of July 2005 21:10, Hugh Dickins wrote:
> > Please revert the yenta free_irq on suspend patch (below)
> > which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
> >
> > Sorry Daniel, you may have a box on which resume doesn't wo
On Sat, Jul 30, 2005 at 01:36:24PM -0700, Linus Torvalds wrote:
> On Sat, 30 Jul 2005, Russell King wrote:
> >
> > What this probably means is that we need some way to turn off interrupts
> > from devices on suspend, and on resume, keep them off until drivers
> > have had a chance to quiesce all d
On Saturday, 30 of July 2005 21:10, Hugh Dickins wrote:
> Please revert the yenta free_irq on suspend patch (below)
> which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
>
> Sorry Daniel, you may have a box on which resume doesn't work without
> it, but on my laptop APM resume from RAM now fails to
On Sat, 30 Jul 2005, Russell King wrote:
>
> What this probably means is that we need some way to turn off interrupts
> from devices on suspend, and on resume, keep them off until drivers
> have had a chance to quiesce all devices, turn them back on, and then
> do full resume.
No, we just need
On Sat, 30 Jul 2005, Hugh Dickins wrote:
>
> Please revert the yenta free_irq on suspend patch (below)
> which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
Ok. Will do.
And the ACPI people had better stop doing this crazy thing in the first
place. There's really no point at all to freeing and r
On Sat, Jul 30, 2005 at 08:10:33PM +0100, Hugh Dickins wrote:
> Please revert the yenta free_irq on suspend patch (below)
> which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
>
> Sorry Daniel, you may have a box on which resume doesn't work without
> it, but on my laptop APM resume from RAM now fai
Please revert the yenta free_irq on suspend patch (below)
which went into 2.6.13-rc4 after 2.6.13-rc3-git9.
Sorry Daniel, you may have a box on which resume doesn't work without
it, but on my laptop APM resume from RAM now fails to work because of
it - locks up solid. The patch sounded rather fis
58 matches
Mail list logo
