Messages in this thread | | | From | Nigel Cunningham <> | Subject | Re: hald in status D with 2.6.16-rc4 | Date | Tue, 28 Feb 2006 10:40:38 +1000 |
| |
Hi.
On Tuesday 28 February 2006 08:48, Hesse, Christian wrote: > On Wednesday 22 February 2006 21:12, Hesse, Christian wrote: > > On Wednesday 22 February 2006 11:10, Hesse, Christian wrote: > > > On Tuesday 21 February 2006 23:49, Andrew Morton wrote: > > > > "Hesse, Christian" <mail@earthworm.de> wrote: > > > > > On Tuesday 21 February 2006 06:19, Andrew Morton wrote: > > > > > > "Hesse, Christian" <mail@earthworm.de> wrote: > > > > > > > Hello everybody, > > > > > > > > > > > > > > since using kernel version 2.6.16-rc4 the hal daemon is in > > > > > > > status D after resume. I use suspend2 2.2.0.1 for 2.6.16-rc3. > > > > > > > Any hints what could be the problem? It worked perfectly with > > > > > > > 2.6.15.x and suspend2 2.2. > > > > > > > > > > > > a) Look in the logs for any oopses, other nasties > > > > > > > > > > Nothing. > > > > > > > > > > > b) Do `echo t > /proc/sysrq-trigger', `dmesg -s 1000000 > foo' > > > > > > then find the trace for `hald' in `foo', send it to this list. > > > > > > > > > > Ok, here it is: > > > > > > > > > > [ trace snipped ] > > > > > > > > > > This is with 2.6.16-rc4-git1 + suspend2 2.2.0.1. > > > > > > > > Hopefully suspend2 isn't involved. People would feel more > > > > comfortable if you could test a vanilla mainline tree.. > > > > > > > > Could the ACPI team please take a look at fixing this regression? > > > > > > I did two cycles with mainline suspend now and did not hit the > > > problem... I will keep an eye on it. > > > > It is independent from suspend version, hald hangs with mainline suspend > > as well. > > I think this is a big regression since 2.5.15. Is anybody working on it? I > did not get a reply for nearly a week now... > If anybody needs more information let me know.
I would suggest bugging the acpi guys :)
Regards,
Nigel [unhandled content-type:application/pgp-signature] | |