Re: hald in status D with 2.6.16-rc4

[Nigel Cunningham <ncunningham@cyclades.com>]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hi.

On Thursday 23 February 2006 08:36, Hesse, Christian wrote:
> On Wednesday 22 February 2006 12:09, Nigel Cunningham wrote:
> > On Wednesday 22 February 2006 20: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.
> >
> > Could you let me know how you go? I didn't make any changes between 2.2
> > and 2.2.0.1 that I think could cause this, but if you can't reproduce it
> > otherwise, I'll happily look again.
>
> You just missed my last mail. It happens with mainline suspend as well, so
> it is not your fault.

Ok. Thanks! :)

Nigel

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]