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
42 matches
Mail list logo
