On Tue, Dec 26, 2006 at 06:52:06PM -0800, Jurij Smakov wrote: > > > backports are risky, again as you see for the net-r8169-1.patch, > > that is a "localized" driver enhancement with big slow down consequences > > #400524 and #403782. yes upstream has a fix for that and it should > > land soon, but still no one else bothered yet. > > That's because slower networking will not break your hardware.
why was that fact never rc for sarge? #259481, #262383 > > the acpi patches may solve the troubles with those stupid HP laptops, > > but they have _certainly_ side effects. > > if you look at the acpi commits of this day you see that they broke > > a toshiba laptop. > > Do you have a reference to that? And we do have a possibility to test > the changes pretty extensively by uploading to unstable plus > specifically asking people to test. the dsdt of those hp notebooks is quite strange, if you follow mjg59 posts you have read a funny story: http://mjg59.livejournal.com/67443.html the reference is easily readable in the git-commits-mail, if you interested in a 2006 tarball, i can send it. check b976fe19acc565e5137e6f12af7b6633a23e6b7c it reverts your proposed patch. > > and push a newer linux in a point release. > > Do you have a patch which does that? If that would exist, I might > reconsider my position. no that is a release manager position. ;) but i assume you mean a patch for drivers/acpi/blacklist.c that should be fairly easy to create once we get dmidecode output of the bug reporter. fully untested: diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c index f9c972b..669d81d 100644 --- a/drivers/acpi/blacklist.c +++ b/drivers/acpi/blacklist.c @@ -69,6 +69,9 @@ static struct acpi_blacklist_item acpi_blacklist[] __initdata = { "Incorrect _ADR", 1}, {"ASUS\0\0", "P2B-S ", 0, ACPI_DSDT, all_versions, "Bogus PCI routing", 1}, + /* HP nx6125 */ + {"Hewlett-Packard ", "68DTT Ver. F.0", 0xE0000, ACPI_DSDT, all_versions, + "Bogus fan support", 1}, {""} }; > > playing with acpi fire is not appropriate for a stable release. > > It's all about cost/benefit analysis. In my eyes the benefits of > introducing these patches significantly outweighs the possible > problems, given the proper testing. fully agreed. the cost analysis of acpi patches seems quite high, that's why we currently have the policy not to add any. i hate to do name dropping, but that goes back to hch. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
