Date: Fri, 20 Aug 2004 10:53:23 +0200 From: "Simon L. Nielsen" <simon@FreeBSD.org> To: Kent Hauser <kent.hauser@verizon.net> Cc: =?iso-8859-1?Q?S=F8ren?= Schmidt <sos@DeepCore.dk> Subject: Re: RELENG_5: ata interrupt problems Message-ID: <20040820085322.GC16420@eddie.nitro.dk> In-Reply-To: <200408191632.25637.kent.hauser@verizon.net> References: <200408191632.25637.kent.hauser@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--DSayHWYpDlRfCAAQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[CC'ing Mr. ATA]
On 2004.08.19 16:32:25 -1000, Kent Hauser wrote:
> I updated my IBM T41 from a May -CURRENT to -RELENG_5 & am now getting
> "READ_DMA interrupt but timeout fired" (also WRITE_DMA). After a minute o=
r so
> it drops into the debugger. Kernel is unmodified GENERIC.
I have seen something similar the last couple of days when I boot with
my DVD/CDRW drive attached in my Thinkpad R40. I can't get to the
dmesg of the errors that occour before the panic, but I can get that
tonight.
Trace:
panic: Duplicate free of item 0xc1c3f18c from zone 0xc198e160(g_bio)
panic messages:
---
panic: Duplicate free of item 0xc1c3f18c from zone 0xc198e160(g_bio)
cpuid =3D 0;=20
KDB: enter: panic
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 =
336 352 368 384 400 416 432 448 464 480 496
---
Reading symbols from /boot/kernel/mac_portacl.ko...done.
Loaded symbols for /boot/kernel/mac_portacl.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
#0 doadump () at pcpu.h:159
159 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc0455929 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D1999, dummy4=
=3D0xd41dc9c4 "`\016}@")
at /usr/src/sys/ddb/db_command.c:531
#2 0xc04556d8 in db_command (last_cmdp=3D0xc07d0564, cmd_table=3D0x0, aux_=
cmd_tablep=3D0xc0791d44,=20
aux_cmd_tablep_end=3D0xc0791d48) at /usr/src/sys/ddb/db_command.c:349
#3 0xc04557c9 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#4 0xc0457631 in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.=
c:221
#5 0xc056e846 in kdb_trap (type=3D0, code=3D0, tf=3D0x1) at /usr/src/sys/k=
ern/subr_kdb.c:417
#6 0xc071bb53 in trap (frame=3D
{tf_fs =3D 24, tf_es =3D 16, tf_ds =3D -736296944, tf_edi =3D 256, tf=
_esi =3D 1, tf_ebp =3D -736244900, tf_isp =3D -736244928, tf_ebx =3D -73624=
4848, tf_edx =3D 1, tf_ecx =3D -1056882688, tf_eax =3D 18, tf_trapno =3D 3,=
tf_err =3D 0, tf_eip =3D -1068046953, tf_cs =3D 8, tf_eflags =3D 646, tf_e=
sp =3D -1065960684, tf_ss =3D -1065968875})
at /usr/src/sys/i386/i386/trap.c:576
#7 0xc0707ffa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#8 0xc0554cb5 in panic (fmt=3D0xc0787482 "Duplicate free of item %p from z=
one %p(%s)\n")
at /usr/src/sys/kern/kern_shutdown.c:542
#9 0xc06de677 in uma_dbg_free (zone=3D0xc198e160, slab=3D0xc1c3ff70, item=
=3D0xc1c3f18c)
at /usr/src/sys/vm/uma_dbg.c:276
#10 0xc06dd0ac in uma_zfree_arg (zone=3D0xc196d640, item=3D0xc1c3f18c, udat=
a=3D0x0)
at /usr/src/sys/vm/uma_core.c:2228
#11 0xc0519147 in g_destroy_bio (bp=3D0x0) at uma.h:302
#12 0xc0516fe0 in g_dev_done (bp2=3D0xc1c3f18c) at /usr/src/sys/geom/geom_d=
ev.c:328
#13 0xc05a4244 in biodone (bp=3D0xc1c3f18c) at /usr/src/sys/kern/vfs_bio.c:=
3002
#14 0xc0472f16 in ad_done (request=3D0xc1c3b438) at /usr/src/sys/dev/ata/at=
a-disk.c:322
#15 0xc0462ac0 in ata_completed (context=3D0xc1c3b438, dummy=3D0) at /usr/s=
rc/sys/dev/ata/ata-queue.c:404
#16 0xc0462c0e in ata_timeout (request=3D0xc1c3b438) at /usr/src/sys/dev/at=
a/ata-queue.c:442
#17 0xc0562417 in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout=
=2Ec:259
#18 0xc053c5b4 in ithread_loop (arg=3D0xc19b2580) at /usr/src/sys/kern/kern=
_intr.c:546
#19 0xc053b6d1 in fork_exit (callout=3D0xc053c455 <ithread_loop>, arg=3D0x0=
, frame=3D0x0)
at /usr/src/sys/kern/kern_fork.c:820
> From the archives, I've seen some chatter about this for the last month, =
but I=20
> can't find the solution posted.
It (or a similar problem) was fixed about a month ago, but it seems
the problem came back just before/after the 6.0 branching.
> Any thoughts? (Or research I need to do?).
You could get a traceback as described in the developers handbook and
see if it is similiar to the one I posted above.
--=20
Simon L. Nielsen
FreeBSD Documentation Team
--DSayHWYpDlRfCAAQ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (FreeBSD)
iD8DBQFBJbwCh9pcDSc1mlERApBIAJ0ZfgG0HOghzFWYEuCcMnJXUYApXgCdGu7E
JqVSd2T5c7S/09t+3AJYFDU=
=sMi9
-----END PGP SIGNATURE-----
--DSayHWYpDlRfCAAQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040820085322.GC16420>