> >> If it benefits other architectures (say ARM) then adding in hooks > >> there (in osl for example) makes sense - but I am not sure if ARM > >> has a form of _PUR code/calls it needs to do. > >> > >> So with that in mind, neither of those options seems proper - as all > >> of them depend on changing something in drivers/acpi/*. > >> > >> I've one or two suggestions of what could be done to still make this > >> work, but I need you to first see what happens if the native acpi_pad > >> runs under Xen with the latest upstream code (along with three > >> patches that are in a BZ I pointed you too). > > > > Do you mean test the patch > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=arch/x86/xen/enlighten.c;h=b132ade26f778f2cfec7c2d5c7b6db48afe424d5;hp=4172af8ceeb363d06912af15bf89e8508752b794;hb=d4c6fa73fe984e504d52f3d6bba291fd76fe49f7;hpb=aab008db8063364dc3c8ccf4981c21124866b395 Right. > > ? > > Ah, you want to test https://bugzilla.redhat.com/show_bug.cgi?id=804347 No. That is a fix on that is required to boot v3.4-rc0 - if you are using that version. > Anyway, I didn't have proper h/w platform, but seems the bug (ioapic) is irrelated to pad thread we are talking? Correct (it is irrelevant). -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
