| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] x86 HPET MSI IRQs vs resume from S3
Jan Beulich wrote on 2011-02-14:
>>>> On 14.02.11 at 02:00, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2011-01-28:
>>> Going through hpet_broadcast_init(), I see that
>>> hpet_setup_msi_irq() gets called during resume, thus causing
>>> setup_irq() to be called. I'm failing to spot the corresponding
>>> release_irq(), and hence I can't see how this whole code path is
>>> supposed to work during resume (other than always falling back to
>>> using legacy_hpet_event). Instead I'm wondering whether in the
>>> resume case only msi_compose_msg()/
>>> hpet_msi_write() should be called for each IRQ used rather than the
>>> whole hpet_broadcast_init().
>>
>> I do think below patch could resolve this issue well. Didn't create
>> a new path for hpet broadcast init while resume because there exists
>> many condition checks in existing path.
>
> Yes, for 4.1 this seems a reasonable fix. Post-4.1 I'd prefer to split
> the code paths so that failure during resume (which shouldn't happen
> anyway) would lead to e.g. calling destroy_irq(), and also to get more
> stuff __init-annotated (with your change here,
> hpet_assign_irq() in the resume path wouldn't call create_irq() and
> request_irq() [and shouldn't call destroy_irq() as said above], and
> the full
> hpet_fsb_cap_lookup() doesn't look to be necessary in the resume path either).
I agree. I will send a 4.1 fix patch first and a little bit later a Post-4.1
clean up patch just as you suggested above. Thanks for finding and raising this
issue.
Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home