>Number:         14793
>Category:       kern
>Synopsis:       panic in UFS
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 30 08:16:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Steve Byan
>Release:        1.5.2
>Organization:
Byan-Roper Household
>Environment:
oops - don't have this handy
>Description:
environment: macintosh Quadra 950 (mac68k) with 1.5.2 GENERIC kernel and 1.5.0 user-space plus recent compile and install of netatalk-asun-<mumble> using the pkg system. The Quadra 950 was connected to a serial console, since the Mac68K port doesn't support the video on this machine. 

I transferred a large amount of data (~1 GB) to the NetBSD system via a Mac Finder copy to a mounted appletalk volume, using MacOS9.1 on a G3 Powerbook (therefor the transfer should have used a TCP/IP appletalk file protocol connection). The MacOS source machine was on 100baseT ethernet, the NetBSD destination on 10baseT ethernet, using the built-in ethernet port.

The NetBSD appletalk system exports three AFP volumes; they are all under the /Users filesystem, which is a mount of a 36 GB local UFS filesystem which resides on its own disk (sd1). The three volumes are /Users/Shared, /Users/Mac, and /Users/Steve on the Unix side, exported as voumes named "Shared", "Mac", and "Steve". When I first mounted these volumes in MacOS, I noticed that /Users/Shared and /Users/Mac both showed an empty Users folder, which I did not recall placing there. I assumed that some didling around I had done with the MacOS 9 Multiple Users feature had created these folders.

The NetBSD system had been rebooted only a few minutes before I mounted these volumes, and my home LAN had very little traffic at that point other than the Appletalk NBP and service discovery stuff.

I deleted the Users folder in the Shared volume using the MacOS finder. The Finder window for the Mac volume still showed a Users folder, but that may have been due to a delay in the Finder synchronizing the contents - I later determined that these Users folders were phantoms, not really extant in the local UFS file system on the NetBSD system.

I proceeded to transfer a large amount of data, first using the Mac application "Synchronize!" (which does a directory treewalk on both a local subdirectory tree and a corresponding remote subdirectory tree, compares the files and modification times, creates a diff list, and then copies files as appropriate to synchronize the directories), then using a straight Finder copy on a large directory tree.

During these file transfers, a number of "sn0: receive FIFO overrun" messages came up on the NetBSD console.

Shortly after disconnecting the Appletalk volumes, the NetBSD system paniced:

sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
sn0: receive FIFO overrun
/home: bad dir ino 470215 at offset 0: mangled entry
panic: bad dir
Stopped in find at      _cpu_Debugger+0x6:      unlk    a6
db> trace
_cpu_Debugger(0,0,9,56ba00,3691d04) + 6
_panic(14c4a1,2440000,3691dc0,14bd78,88ad98) + 60
_ufs_dirbad(88ad98,0,14ba5d,88d34c,0) + 3c
_ufs_lookup(3691e00) + 2f8
_lookup(3691ea0) + 224
_namei(3691ea0) + 2dc
_sys___lstat13(8b9964,3691f88,3691f80) + 2a
_syscall(118) + 144
_trap0() + e
db> reboot
syncing disks... sn0: receive descriptors exhausted
panic: lockmgr: locking against myself
Stopped in find at      _cpu_Debugger+0x6:      unlk    a6
db> reboot
rebooting...


At the time I was logged into the NetBSD serial console using a vanilla user account which had it's home directory on the UFS file system mounted on /home. This file system is on the root disk, not on the disk containing the netatalk AFP exported volumes.

After rebooting and fscking, there were no "Users" subdirectories in /Users/Shared, /Users/Mac, nor /Users/Steve.

Speculation:

The /Users/Shared/Users and /Users/Mac/Users directories seem to have been phantoms, perhaps generated by netatalk. Don't see how they are directly connected with a bogus directory entry in an entirely different, non-AFP-exported file system. I'll try to check the syslog to see if netatalk complained when I deleted the /Users/Shared/Users directory via the MacOS Finder. I don't recall seeing anything on the console.

Perhaps the sn ethernet driver is buggy, and scribbled on the directory entry cache as a result of the fifo overruns?
>How-To-Repeat:
unknown
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: