Bjorn Helgaas <[EMAIL PROTECTED]> writes:
>
> The main reason we wait until pci_enable_device() to allocate an
> IRQ number is that ia64 currently only has about 180 device vectors,
> and there are machines with more PCI slots than that.
If we don't reserve irqs that the hardware doesn't support
On Monday 02 April 2007 09:38, Bjorn Helgaas wrote:
> The main reason we wait until pci_enable_device() to allocate an
> IRQ number is that ia64 currently only has about 180 device vectors,
> and there are machines with more PCI slots than that.
Sigh, that didn't make much sense, did it? At the t
On Monday 26 March 2007 21:29, Eric W. Biederman wrote:
> "Luck, Tony" <[EMAIL PROTECTED]> writes:
>
> >> What I'm proposing we do is move the irq allocation code out of
> >> pci_enable_device and the irq freeing code out of pci_disable_device
> >> in the future.
> >
> > Sounds rational ... in a w
Adrian Bunk wrote:
> > > Does setting CONFIG_PCI_MSI=n make any difference?
> >
> > Yes, it does. The hanging resume problem went away.
>
> Thanks for testing.
>
> If you enable it again, does the patch from [1] also fix it?
Yes, it appears to fix it.
Marcus
pgpnnyS0pETwQ.pgp
Description: PGP s
"Luck, Tony" <[EMAIL PROTECTED]> writes:
>> What I'm proposing we do is move the irq allocation code out of
>> pci_enable_device and the irq freeing code out of pci_disable_device
>> in the future.
>
> Sounds rational ... in a world that wasn't dominated by PCI it would
> seem to be the logical ap
On Sunday, 25 March 2007 22:37, Eric W. Biederman wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > On Sunday, 25 March 2007 14:56, Eric W. Biederman wrote:
> >> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> >>
> >> > Yes, in kernel/power/disk.c:power_down() .
> >> >
> >> > Pleas
> What I'm proposing we do is move the irq allocation code out of
> pci_enable_device and the irq freeing code out of pci_disable_device
> in the future.
Sounds rational ... in a world that wasn't dominated by PCI it would
seem to be the logical approach (since the irq code would have much
more ut
On Mon, Mar 26, 2007 at 09:39:29PM +0200, Frederic Riss wrote:
> 2007/3/26, Adrian Bunk <[EMAIL PROTECTED]>:
> >On Mon, Mar 26, 2007 at 08:53:20PM +0200, Frédéric Riss wrote:
> >
> >>... (In fact it hangs at the second suspend, but that's another ATA
> >> problem that I think has already been repor
2007/3/26, Adrian Bunk <[EMAIL PROTECTED]>:
On Mon, Mar 26, 2007 at 08:53:20PM +0200, Frédéric Riss wrote:
>... (In fact it hangs at the second suspend, but that's another ATA
> problem that I think has already been reported).
This sounds like the MSI problem.
Do you have CONFIG_PCI_MSI enable
On Mon, Mar 26, 2007 at 08:53:20PM +0200, Frédéric Riss wrote:
>... (In fact it hangs at the second suspend, but that's another ATA
> problem that I think has already been reported).
This sounds like the MSI problem.
Do you have CONFIG_PCI_MSI enabled?
If yes, does disabling it fix it?
If yes, d
Le lundi 26 mars 2007 à 11:14 +0200, Thomas Gleixner a écrit :
> On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> > Additional data point: I just tried with -rc5 and the issue is still
> > present. The config I used for this test defines neither NO_HZ nor
> > HIGH_RES_TIMERS.
>
> Do you h
On Mon, Mar 26, 2007 at 07:42:51PM +0200, Marcus Better wrote:
> Adrian Bunk wrote:
> > > > Subject: ThinkPad R60: suspend to disk broken
>
> > Does setting CONFIG_PCI_MSI=n make any difference?
>
> Yes, it does. The hanging resume problem went away.
Thanks for testing.
If you enable it ag
Adrian Bunk wrote:
> > > Subject: ThinkPad R60: suspend to disk broken
> Does setting CONFIG_PCI_MSI=n make any difference?
Yes, it does. The hanging resume problem went away.
(The display corruption and the instant resume were not affected.)
Marcus
-
To unsubscribe from this list: send t
On Mon, Mar 26, 2007 at 12:00:22PM +0200, Marcus Better wrote:
> Adrian Bunk wrote:
> > Subject: ThinkPad R60: suspend to disk broken
> > References : http://lkml.org/lkml/2007/3/23/74
> > Submitter : Marcus Better <[EMAIL PROTECTED]>
> > Status : submitter tries to bisect
>
> I just trie
Pavel Machek wrote:
>> > Subject: ThinkPad R60: suspend to disk broken
>> > References : http://lkml.org/lkml/2007/3/23/74
>> input, so I suspended to RAM again. This time the resume failed, it hung
>> after printing "Linux!" in yellow at the top of the screen.
> Yellow Linux! is my debuggin
Hi!
> > Subject: ThinkPad R60: suspend to disk broken
> > References : http://lkml.org/lkml/2007/3/23/74
> > Submitter : Marcus Better <[EMAIL PROTECTED]>
> > Status : submitter tries to bisect
>
> I just tried -rc5. Now suspend to disk seems to work. I think the XFS
> workqueue patch f
2007/3/26, Thomas Gleixner <[EMAIL PROTECTED]>:
On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> Additional data point: I just tried with -rc5 and the issue is still
> present. The config I used for this test defines neither NO_HZ nor
> HIGH_RES_TIMERS.
Do you have CONFIG_HPET_TIMER ena
Adrian Bunk wrote:
> Subject: ThinkPad R60: suspend to disk broken
> References : http://lkml.org/lkml/2007/3/23/74
> Submitter : Marcus Better <[EMAIL PROTECTED]>
> Status : submitter tries to bisect
I just tried -rc5. Now suspend to disk seems to work. I think the XFS
workqueue patch f
On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> Additional data point: I just tried with -rc5 and the issue is still
> present. The config I used for this test defines neither NO_HZ nor
> HIGH_RES_TIMERS.
Do you have CONFIG_HPET_TIMER enabled and does the box have one ?
If yes, can you p
Le dimanche 25 mars 2007 à 23:34 +0200, Frédéric Riss a écrit :
> However, as I pointed out in the initial report, the MacMini doesn't
> come out of suspend to ram because a commit in another merged patchset
> broke it. I tracked it down to:
>
> commit e9e2cdb412412326c4827fc78ba27f410d837e6e
> pa
Le vendredi 23 mars 2007 à 19:50 +0100, Adrian Bunk a écrit :
> Subject: MacMini: doesn't come out of suspend to ram
> References : http://lkml.org/lkml/2007/3/21/374
> Submitter : Frédéric RISS <[EMAIL PROTECTED]>
> Tino Keitel <[EMAIL PROTECTED]>
> Caused-By : Bob Moore <[EMAIL
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> On Sunday, 25 March 2007 14:56, Eric W. Biederman wrote:
>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>>
>> > Yes, in kernel/power/disk.c:power_down() .
>> >
>> > Please comment out the disable_nonboot_cpus() in there and retest (but
> pleas
On Sunday, 25 March 2007 21:06, Rafael J. Wysocki wrote:
> On Sunday, 25 March 2007 19:25, Thomas Meyer wrote:
> > Adrian Bunk schrieb:
> > > On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
> > >
> > >> ...
> > >> The first suspend to disk is ok. The second suspend to disk has a
>
On Sunday, 25 March 2007 19:25, Thomas Meyer wrote:
> Adrian Bunk schrieb:
> > On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
> >
> >> ...
> >> The first suspend to disk is ok. The second suspend to disk has a
> >> strange behaviour:
> >> 1.) write pm image
> >> 2.) the system dis
On Sunday, 25 March 2007 14:56, Eric W. Biederman wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > Yes, in kernel/power/disk.c:power_down() .
> >
> > Please comment out the disable_nonboot_cpus() in there and retest (but
> > please
> > test the latest Linus' tree).
>
>
>
> Why do
On Sunday, 25 March 2007 16:17, Thomas Meyer wrote:
> Rafael J. Wysocki schrieb:
> > On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
> >
> >> Thomas Meyer <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> Eric W. Biederman schrieb:
> >>>
> Thomas could you verify the patch be
Adrian Bunk schrieb:
> On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
>
>> ...
>> The first suspend to disk is ok. The second suspend to disk has a
>> strange behaviour:
>> 1.) write pm image
>> 2.) the system disable the non-boot cpus again (i guess this happens in
>> power_down(
On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
>...
> The first suspend to disk is ok. The second suspend to disk has a
> strange behaviour:
> 1.) write pm image
> 2.) the system disable the non-boot cpus again (i guess this happens in
> power_down())
> 3.) the system doesn't power d
Rafael J. Wysocki schrieb:
> On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
>
>> Thomas Meyer <[EMAIL PROTECTED]> writes:
>>
>>
>>> Eric W. Biederman schrieb:
>>>
Thomas could you verify the patch below makes the problem go away
for you.
>>>
Eric W. Biederman schrieb:
> Sounds possible. You could probably verify it isn't my patch but running
> an unpatched kernel without msi support. As I think the crash you saw should
> only be reproducible when using devices that support msi.
>
Without your patch and with pci=nomsi option the sa
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> Yes, in kernel/power/disk.c:power_down() .
>
> Please comment out the disable_nonboot_cpus() in there and retest (but please
> test the latest Linus' tree).
Why do we even need a disable_nonboot_cpus in that path? machine_shutdown
on i386 and x
On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
> Thomas Meyer <[EMAIL PROTECTED]> writes:
>
> > Eric W. Biederman schrieb:
> >>
> >> Thomas could you verify the patch below makes the problem go away
> >> for you.
> >>
> >
> > The patch solves the problem. I'm writing this after the th
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Eric W. Biederman schrieb:
>>
>> Thomas could you verify the patch below makes the problem go away
>> for you.
>>
>
> The patch solves the problem. I'm writing this after the third suspend
> and resume cycle.
> msi irq stays enabled for libata device:
Eric W. Biederman schrieb:
>
> Thomas could you verify the patch below makes the problem go away
> for you.
>
The patch solves the problem. I'm writing this after the third suspend
and resume cycle.
msi irq stays enabled for libata device:
cat /sys/devices/pci\:00/\:00\:1f.2/irq
218
ca
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Eric W. Biederman schrieb:
>>
>> Odd. I would have thought the oops happened in the first resume, not
>> the second.
>>
>> Hmm. It may have something to do with the ``managed'' driver
>> aspect of this as well..
>>
> No. I don't think so. The proble
Eric W. Biederman schrieb:
>
> Odd. I would have thought the oops happened in the first resume, not
> the second.
>
> Hmm. It may have something to do with the ``managed'' driver
> aspect of this as well..
>
No. I don't think so. The problem is caused by this sequence: (the info
is always bef
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Eric W. Biederman schrieb:
>> Thomas Meyer <[EMAIL PROTECTED]> writes:
>>
>>
>>> Adrian Bunk schrieb:
>>>
Subject: second suspend to disk in a row results in an oops (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Subm
Eric W. Biederman schrieb:
> Thomas Meyer <[EMAIL PROTECTED]> writes:
>
>
>> Adrian Bunk schrieb:
>>
>>> Subject: second suspend to disk in a row results in an oops (libata?)
>>> References : http://lkml.org/lkml/2007/3/17/43
>>> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
>>> Status
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Adrian Bunk schrieb:
>> Subject: second suspend to disk in a row results in an oops (libata?)
>> References : http://lkml.org/lkml/2007/3/17/43
>> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
>> Status : unknown
>>
>
> The problem is identifi
Adrian Bunk schrieb:
> Subject: second suspend to disk in a row results in an oops (libata?)
> References : http://lkml.org/lkml/2007/3/17/43
> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
> Status : unknown
>
The problem is identified: http://lkml.org/lkml/2007/3/22/150
-
To unsub
On Friday, 23 March 2007 19:50, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a bre
On Friday 23 March 2007 20:50:22 Adrian Bunk wrote:
> Subject: suspend to disk hangs
> References : http://lkml.org/lkml/2007/3/16/126
> Submitter : Maxim Levitsky <[EMAIL PROTECTED]>
> Caused-By : Rafael J. Wysocki <[EMAIL PROTECTED]>
> commit e3c7db621bed4afb8e231cb005057f2feb
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involv
43 matches
Mail list logo
