On Sat, 18 Nov 2006, Starikovskiy, Alexey Y wrote: > > May because it does not have a single common line with the previous > patch? Yeah, I do agree that it _looks_ very different as a patch, but it ends up having all the same execution profiles.. It's been too long since I debugged the previous problem, so I don't remember the exact details any more (back then I enabled ACPI debugging and watched the messages scroll by etc - this time I initially thought it was interrupt-related due to the other irq problems we've had, so I started bisecting immediately _without_ doing any ACPI debugging stuff, and by the time I actually bisected down enough, I recognized the problem, so I didn't do all the same "enable ACPI messages and look deeply into what is going on" thing). But if I remember correctly, what happens is _roughly_ something like this: - thermal event happens - the CPU is getting warm, and the fan needs to start up. Quite often, this happened early during boot (which is quite busy - some init scripts are disgustingly CPU-intensive mainly due to using inefficient scripting languages), but if it didn't happen there, it's easy enough to force to happen other ways. - part of the handling is "acpi_os_execute()" for something (don't ask me what), but the interestign thing is how that "acpi_os_execue()" then ends up causing a _recursive_ event. - we handle the original event in kacpid, and hand over the new one as a notification event. But the event keeps on happening, and kacpid keeps on running, and the other thread doesn't actually ever _run_ because kacpid holds he ACPI lock and is constantly busy. - we not only are constantly running in kernel space, we also end up eventually running out of memory for allocating all the work queue entries. So the reason the old code works is because everything is done in a single thread, and yes, we end up getting multiple events, but because the queue is all done onto the same queue that is _handling_ the events in the first place, and because it's a FIFO queue, the notification events get handled _before_ the later events. So with the single-threaded situation, you basically end up always doing the events in the same order they came in. In the "two separate threads" case, you don't, and one thread will end up generating events forever, waiting for them to happen, but they never _do_ happen, so you have a lockup _and_ eventually an infinite event queue for the other thread. > Or may be because it fixes all the current AMD-HP notebooks? > Or may be because it did not fail while being in -mm? I'm afraid that -mm doesn't get as much testing as it used to get. Also, I do realize that the patch fixes other problems, but we have long had a very strict policy that we do NOT accept regressions. Immediately when you start accepting regressions, you will never know whether you're going forward of backwards. It's better to have a known _old_ bug than to introduce a new one. So the "no regressions!" rule ends up trumping pretty much every single other issue. It's unacceptable to have machines that used to work, suddenly stop working. Even if it fixes another machine. ACPI didn't use to have that rule, and it was wild and crazy. Maybe more bugs got fixed, but the problem with accepting regressions is that nobody can _ever_ trust that system. You do not want to have people _afraid_ of upgrading - they should feel confident that upgrading never introduces any new problems. (Of course, that can never be reached 100%, but it's very much part of the goal. It kind of falls into the same "backwards compatibility on interfaces" absolute goal: it's ok to do new things, but you can never allow them to break old programs) > I will not "sneak it in" again, I promise. Feel free to send me test patches when working on these things, because I have no trouble at all to test my particular machine. I think you'll find the ACPI dumps etc for that machine in your archives, because I've sent them to Len and the acpi lists several times, but if you want to get AML disassemblies etc, just tell me how. I've done them before, but I work on this seldom enough that I always forget what the magic incantations are, and where to get the tools etc. Linus - 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
