Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Mar 2006 13:49:09 +0100
From:      "Daan Vreeken [PA4DAN]" <Danovitsch@vitsch.net>
To:        mi+mxe@aldan.algebra.com
Cc:        re@freebsd.org, Ariff Abdullah <ariff@freebsd.org>, multimedia@freebsd.org
Subject:   Re: today's 6.1 would not boot here
Message-ID:  <200603011349.09891.Danovitsch@vitsch.net>
In-Reply-To: <1141149726.20664.2.camel@mteterin.us.murex.com>
References:  <200602281628.k1SGSHwY032423@corbulon.video-collage.com> <44047AA0.6070104@samsco.org> <1141149726.20664.2.camel@mteterin.us.murex.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 February 2006 19:02, Mikhail Teterin wrote:
> =F5 =D7=D4, 2006-02-28 =D5 09:30 -0700, Scott Long =D0=C9=DB=C5:
> > Mikhail Teterin wrote:
> > >>http://people.freebsd.org/~ariff/test/ich.c
> > >
> > > This one still hangs on boot on my system :-(
> >
> > And the only thing that you have to do to make the problem go away is
> > disable the sound hardware?
>
> Correct. Although I can not rule out some other possible workaround...
>
> 	-mi

I have noticed that the ich driver keeps spinning in ich_intr() on some=20
hardware. Could this be happening here too?
I have made the problem go away with the following patch :
http://vitsch.net/bsd/patches/ich.c.patch

I'm not an ICH expert, so I have no idea what the ICH_GLOB_CTL_PRES bit doe=
s,=20
but I do know that on some hardware the interrupt condition it triggers isn=
't=20
reset in the interrupt handler. With this patch my laptop runs fine without=
=20
loss of functionality (that I could see). But my laptop also boots without=
=20
the patch, so this could be a completely different bug.

Hope this helps,
Daan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603011349.09891.Danovitsch>