[OpenAFS] Problems with afs driver on a Solaris 8 SF15K
rogbazan
rogbazan <rogbazan@gmail.com>
Thu, 10 Mar 2005 16:12:07 -0600
Let me see if i understood what you say:
My client=B4s version (ibm transarc v3.6 rel 2.48), is very old.
It does not occurs with OpenAFS?
The " if " code that you are adding to your answer is part of IBM
Transarc version=B4s or, it appears in Open AFS too?.
Th conclusion could be the insufficient number of inodes?
P.D.Sorry, but i speak spanish and sometimes don=B4t understand the
whole idea in english.
thanx a lot Derrick.
On Thu, 10 Mar 2005 16:55:05 -0500 (EST), Derrick J Brashear
<shadow@dementia.org> wrote:
> On Thu, 10 Mar 2005, rogbazan wrote:
>=20
> > Hi, we had a client on a SunFire 15K, and it died, a few days ago.
> > Sun Microsystems review the dump generated by the host at the panic
> > time; and this what they told us about the problem:
>=20
> It called osi_Panic in afs_GetDCache, but this isn't even OpenAFS,
> perhaps you could put something modern on the machine?
>=20
> /* If we can't get space for 5 mins we give up and p=
anic */
> if (++downDCount > 300)
> osi_Panic("getdcache");
>=20
> so you had no free disk cache entries, if that version is like openafs
>=20
>=20
> > Lines in the dump file:
> >
> > Mar 2 20:07:03 2005 panic[cpu482]/thread=3D3009a3306c0: getdcache <--
> > Panic: it points to "afs" according to the lines below.
> > Mar 2 20:07:03 2005
> > Mar 2 20:07:03 2005 000002a10d587230 afs:osi_Panic+54 (78a1bad8, 0, 0,
> > 2a10d5875d8, 0,
> > 3009a3c7900)
> > Mar 2 20:07:03 2005 %l0-3: 0000000078a1bad8 0000000000000000 0000000000=
002710
> > 000000004226711d
> > Mar 2 20:07:03 2005 %l4-7: 00000000040a0000 000003003dc71aa0 0000000000=
000000
> > 000002a10d587260
> > Mar 2 20:07:03 2005 000002a10d587300 afs:afs_GetDCache+e44
> > (3003dc71aa0, 40b0000,
> > 2a10d5877c4, 2a10d587
> > 6a0, 2a10d58769c, 2)
> > Mar 2 20:07:03 2005 %l0-3: 000000000000012d 0000000000204421 000003003d=
c71c28
> > 0000000000005f74
> > Mar 2 20:07:03 2005 %l4-7: 0000000000000001 000002a7c9a06000 0000000000=
000000
> > 0000000000000000
> > Mar 2 20:07:03 2005 000002a10d5875c0 afs:afs_PrefetchChunk+d8
> > (3003dc71aa0, 3007272bc80,
> > 3009a3c7900, 2
> > a10d5877c4, 3003dc71aa0, 2a7c9a04000)
> > Mar 2 20:07:03 2005 %l0-3: 0000000000000003 000003007272bc80 0000000000=
010000
> > 00000000040b0000
> > Mar 2 20:07:03 2005 %l4-7: 0000000000000003 000002a7c9a04000 0000030001=
1e7ef8
> > 0000000000000000
> > Mar 2 20:07:03 2005 000002a10d5876d0 afs:afs_nfsrdwr+1920
> > (3003dc71aa0, 2a10d587a00, 1, 0,
> > 3009a3c7900,
> > 0)
> > Mar 2 20:07:03 2005 %l0-3: 0000000000000000 0000000004090000 0000000004=
0a0000
> > 0000000000000000
> > Mar 2 20:07:03 2005 %l4-7: 0000000000000000 0000000010423c18 0000000000=
000000
> > 0000000000000000
> > Mar 2 20:07:03 2005 000002a10d587860 afs:afs_vmwrite+7c (3003dc71aa0,
> > 2a10d587a00, 0,
> > 3009a3c7900, 300b
> > dea00a0, 300bdea0000)
> > Mar 2 20:07:03 2005 %l0-3: 0000000078476e50 000003006489ba38 0000000000=
040000
> > 0000000000000001
> > Mar 2 20:07:03 2005 %l4-7: 000002a109577d20 0000030020b83240 0000000000=
010bed
> > 000002a100dbf968
> > Mar 2 20:07:03 2005 000002a10d587940 genunix:write+204 (4080000,
> > 40000, 2002, 30069bcd5b0,
> > 4, 40000)
> > Mar 2 20:07:03 2005 %l0-3: 00000000789f2e70 0000000000040000 000003003d=
c71aa0
> > 0000000000000000
> > Mar 2 20:07:03 2005 %l4-7: 0000000000000004 0000000010423790 0000030065=
4e05c0
> > 0000030067ebcc78
> > Mar 2 20:07:04 2005 000002a10d587a40 genunix:write32+30 (4, ff230000,
> > 40000, 2, 21940,
> > 125d0)
> > Mar 2 20:07:04 2005 000002a10d587a40 genunix:write32+30 (4, ff230000,
> > 40000, 2, 21940,
> > 125d0)
> > Mar 2 20:07:04 2005 %l0-3: 0000000000000004 0000030049c5d520 0000030066=
b7a028
> > 0000000000000000
> > Mar 2 20:07:04 2005 %l4-7: 0000000000000001 0000030049c5d520 0000000000=
000000
> > 0000000000000000
> > Mar 2 20:07:04 2005
> > Mar 2 20:07:34 2005 syncing file systems... <-- it tries to close the
> > file systemscorrectly.
> > panic[cpu482]/thread=3D3009a3306c0: panic sync timeout <-- It does not
> > sync, time expired.
> > It generates a second panic.
> > Mar 2 20:07:34 2005 dumping to /dev/md/dsk/d70, offset 7283474432 <--
> > The dump file of the second panic is saved.
> >
> >
> > After that, a Sun engineer says:
> >
> >
> > "I inform to you that the panic occurred in the "afs" driver. SUN does =
not
> > support the "afs" driver, so we do not have the source code for it and =
we cannot
> > provide the customer with a solution. This customer needs to contact th=
e company
> > that supports the "afs" driver.
> > That was Transarc initially, but I believe Transarc was taken over by I=
BM.
> > Best Regards,
> > Paul McKernan, PTS-KERNEL AMER"
> >
> >
> > Does any body knows about a similar problem or a patch that prevents th=
at.
> >
> > The client is a Transarc v.3.6 Rel.2.48.
> > Regards
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> >
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>