Prev: [patch 1/2] x86_64 page fault NMI-safe
Next: [PATCH] enable readback to get HPET working on ATI SB4x00, kernel 2.6.35_rc5
From: Linus Torvalds on 14 Jul 2010 12:20 On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf <stephan(a)letzte-bankreihe.de> wrote: > > �After commit 30a564be9d9554c168a654eddc2165869cc0d7bf "x86, hpet: Restrict > read back to affected ATI chipsets" hpet did not work anymore on HP nx6325. > The machine hangs on booting until a keystroke was taken. After a short time > machine hangs again until next keystroke. Applying the following patch > solves the issue for me. Ok, this makes sense. Bugs in the ATI chipset is why 'hpet_readback_cmp' exists in the first place. HOWEVER, clearly that commit changed it to be about too few ATI chipsets. So right now, for - PCI_DEVICE_ID_ATI_SBX00_SMBUS: force disable HPET MSI force HPET readback - PCI_DEVICE_ID_ATI_IXP400_SMBU force-enable HPET ...and than your patch makes it force HPET readback but that doesn't actually make much sense in the bigger picture, because there are other ATI chipsets that are related and presumably also affected. What about IXP[23]00_SMBUS? And what about the IXP7 series (SBX00 is IXP6, afaik)? So I get the feeling that this is incomplete, or at least needs thinking about those other ATI chipsets too. Thomas? And I added Andreas to the cc, maybe he knows what's up. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephan Wolf on 14 Jul 2010 12:50 Am 14.07.2010 18:13, schrieb Linus Torvalds: > On Wed, Jul 14, 2010 at 8:55 AM, Stephan Wolf > <stephan(a)letzte-bankreihe.de> wrote: >> After commit 30a564be9d9554c168a654eddc2165869cc0d7bf "x86, hpet: Restrict >> read back to affected ATI chipsets" hpet did not work anymore on HP nx6325. >> The machine hangs on booting until a keystroke was taken. After a short time >> machine hangs again until next keystroke. Applying the following patch >> solves the issue for me. > Ok, this makes sense. Bugs in the ATI chipset is why > 'hpet_readback_cmp' exists in the first place. HOWEVER, clearly that > commit changed it to be about too few ATI chipsets. > > So right now, for > > - PCI_DEVICE_ID_ATI_SBX00_SMBUS: > force disable HPET MSI > force HPET readback > > - PCI_DEVICE_ID_ATI_IXP400_SMBU > force-enable HPET > ...and than your patch makes it force HPET readback > > but that doesn't actually make much sense in the bigger picture, > because there are other ATI chipsets that are related and presumably > also affected. What about IXP[23]00_SMBUS? And what about the IXP7 > series (SBX00 is IXP6, afaik)? > > So I get the feeling that this is incomplete, or at least needs > thinking about those other ATI chipsets too. > > Thomas? And I added Andreas to the cc, maybe he knows what's up. > > Linus > Ok, I did not consider that msi is disabled at all on IXP400. Isn't it? Maybe that the reason why it is works for me. Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 14 Jul 2010 14:20
On Wed, Jul 14, 2010 at 11:11 AM, Borislav Petkov <borislav.petkov(a)amd.com> wrote: > > I'll try to find out which chipsets are actually affected but in the > meantime we might want to do a temporary fix by enabling the readback > back(!) on all ATI chipsets so that we don't uncover anymore bugs like > the one above, hmmm? That sounds like the right solution for now, yes. Rather than make the readback quirk depend on one particular SMBUS revision, make it happen unconditionally for an AMD northbridge (or is the HPET in the SB? I forget - somebody who knows the details and can test it on a machine or two should do the actual patch). Thomas? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |