> > > Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> > > regular devices and seem to ignore the fact that for bridge PCI-X
> > > capability has a different structure.
> > >
> > > Is this intentional?
> >
> > Probably not a such. I don't think we have any drivers for bridge
> Quoting Eric W. Biederman <[EMAIL PROTECTED]>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
>
> "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>
> > OK I guess. I gather we assume writing read-only registers has no side
> > effec
"Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
> OK I guess. I gather we assume writing read-only registers has no side
> effects?
> Are there rumors circulating wrt to these?
I haven't heard anything about that, and if we are writing the same value back
it should be pretty safe.
I have heard
> Quoting Eric W. Biederman <[EMAIL PROTECTED]>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
>
> "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>
> >> Rumor has it that some pci devices can't tolerate < 32bit accesses.
> >&
"Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>> Rumor has it that some pci devices can't tolerate < 32bit accesses.
>> Although I have never met one.
>
> hopefully not bridge devices?
>
>> The two factors together suggest that
>> for generic code it probably makes sense to operate on 32bit
>>
> Rumor has it that some pci devices can't tolerate < 32bit accesses.
> Although I have never met one.
hopefully not bridge devices?
> The two factors together suggest that
> for generic code it probably makes sense to operate on 32bit
> quantities, and just to ignore the read-only portion.
The
"Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>> Quoting Eric W. Biederman <[EMAIL PROTECTED]>:
>> Subject: Re: SATA resume slowness, e1000 MSI warning
>>
>> "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>>
>> >
> Quoting Eric W. Biederman <[EMAIL PROTECTED]>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
>
> "Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>
> >> The only case I can see which might trigger this is if we saved
> >> pci-
"Michael S. Tsirkin" <[EMAIL PROTECTED]> writes:
>> The only case I can see which might trigger this is if we saved
>> pci-X state and then didn't restore it because we could not find
>> the capability on restore.
>
> Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> regular de
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>
> [CHOP]
>
>> Below is an additional set of warnings that should help debug this.
>> The old code just got lucky that it triggered a warning when this happens.
>
>
> I'm trying this patch together with the other 2 that you sent o
Eric W. Biederman wrote:
[CHOP]
Below is an additional set of warnings that should help debug this.
The old code just got lucky that it triggered a warning when this happens.
I'm trying this patch together with the other 2 that you sent out a few days
ago. I'm seeing some minor issues with
Jeff Garzik <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Until I get the best scenario I can come up with is a tg3 hardware bug
>> that doesn't renable the pci-X capability after a restore of power state.
>
>
> Speaking of tg3, make sure you are aware that the number of calls to
> sa
> The only case I can see which might trigger this is if we saved
> pci-X state and then didn't restore it because we could not find
> the capability on restore.
Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
regular devices and seem to ignore the fact that for bridge PCI-X
ca
Eric W. Biederman wrote:
Until I get the best scenario I can come up with is a tg3 hardware bug
that doesn't renable the pci-X capability after a restore of power state.
Speaking of tg3, make sure you are aware that the number of calls to
save-state functions may not match the number of calls
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> That's:
>
> pci_restore_pcix_state(dev);
> pci_restore_msi_state(dev);
> WARN_ON(!hlist_empty(&dev->saved_cap_space));
>
> return 0;
Hmm. Either I am confused of I just found an unanticipated leak.
pci_restore_msi_sta
On Wed, 07 Mar 2007 12:28:11 -0700 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Below is an additional set of warnings that should help debug this.
> The old code just got lucky that it triggered a warning when this happens.
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 01869b1
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> Kok, Auke wrote:
>> Eric W. Biederman wrote:
>>> This leaves with some basic questions.
>>> - Does it make sense for suspend/resume methods to request/free irqs?
>>> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
>>> - Do we wa
Kok, Auke wrote:
Eric W. Biederman wrote:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
Ingo Molnar wrote:
* Kok, Auke <[EMAIL PROTECTED]> wrote:
BUG: at drivers/pci/msi.c:611 pci_enable_msi()
I would poke Eric Biederman(sp?) about this one. Maybe its even solved by
the MSI-enable-related patch
Eric W. Biederman wrote:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
Ingo Molnar wrote:
* Kok, Auke <[EMAIL PROTECTED]> wrote:
BUG: at drivers/pci/msi.c:611 pci_enable_msi()
I would poke Eric Biederman(sp?) about this one. Maybe its even solved by
the MSI-enable-related patch he posted in the
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> Ingo Molnar wrote:
>> * Kok, Auke <[EMAIL PROTECTED]> wrote:
>>
> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>
I would poke Eric Biederman(sp?) about this one. Maybe its even solved by
the MSI-enable-related patch he posted in the past
Linus Torvalds wrote:
On Tue, 6 Mar 2007, Thomas Gleixner wrote:
SATA has another nice feature. Somehow there is an interrupt pending on
the SATA controller, which comes in somewhere in the middle of resume.
If it happens before the SATA code resumed, the SATA code ignores the
interrupt and the
On Tue, 6 Mar 2007, Thomas Gleixner wrote:
>
> SATA has another nice feature. Somehow there is an interrupt pending on
> the SATA controller, which comes in somewhere in the middle of resume.
> If it happens before the SATA code resumed, the SATA code ignores the
> interrupt and the interrupt is
On Mon, 2007-03-05 at 11:11 +0100, Ingo Molnar wrote:
> the spin-up takes a few seconds here under suspend/resume simulation:
>
> | ata1: waiting for device to spin up (7 secs)
> | Restarting tasks ... done.
>
> [5-10 seconds pass]
>
> | ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Ingo Molnar wrote:
* Kok, Auke <[EMAIL PROTECTED]> wrote:
BUG: at drivers/pci/msi.c:611 pci_enable_msi()
I would poke Eric Biederman(sp?) about this one. Maybe its even
solved by the MSI-enable-related patch he posted in the past 24-48
hours.
I tried the 3-patch series "[PATCH 0/3] Basic m
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> with real resume it takes even longer time - but i dont see where the
> delays come from in that case - i suspect it's SATA.
update: Thomas' PIT/HPET resume-fix patch fixed the delay for me.
Ingo
-
To unsubscribe from this list: send the line
* Kok, Auke <[EMAIL PROTECTED]> wrote:
> >>BUG: at drivers/pci/msi.c:611 pci_enable_msi()
> >I would poke Eric Biederman(sp?) about this one. Maybe its even
> >solved by the MSI-enable-related patch he posted in the past 24-48
> >hours.
>
> I tried the 3-patch series "[PATCH 0/3] Basic msi b
Jeff Garzik wrote:
Ingo Molnar wrote:
i'm also getting this WARN_ON() from e1000:
BUG: at drivers/pci/msi.c:611 pci_enable_msi()
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] dump_stack+0x14/0x16
[] pci_enable_msi+0x6d/0x203
[] e1000_request_irq+0x2e/0xe2
[] e1000_resume+0x7f
Ingo Molnar wrote:
i'm also getting this WARN_ON() from e1000:
BUG: at drivers/pci/msi.c:611 pci_enable_msi()
[] show_trace_log_lvl+0x19/0x2e
[] show_trace+0x12/0x14
[] dump_stack+0x14/0x16
[] pci_enable_msi+0x6d/0x203
[] e1000_request_irq+0x2e/0xe2
[] e1000_resume+0x7f/0xef
[] pci_device
* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > (Resume is very slow, because disks are not spinned up properly; and
> > there's something wrong with timers; console beeps take way too long).
> Pavel, I tried with your .config, and indeed the system came back to
> life after 2-3 minutes aft
29 matches
Mail list logo
