Robert Andre <[email protected]> writes: > just stepped over a kernel failure after stopping the > openafs-client. The first try stopping the daemon failed due to a still > used mount point (umount: /afs: device is busy). The next try caused > the following kernel failure error:
The summary is that AFS didn't clean up all the objects in the inode cache. I've seen this from time to time when shutting down AFS, although rarely and I don't know how to reproduce it. > I used a symbolic link on an afs directory of a used cell. Restarting > and stopping the service after the failure didn't result in another > error. Though I haven't restarted the system yet. Also, logging in and > accessing the afs directories after restarting the afs daemon causes no > problems. Oh, good, sounds like it's been relatively harmless. (To check, the important severity was just because it's disturbing to see a kernel oops? Or did this cause significant system problems?) At this point, 1.4 is in super-stable maintenance mode upstream since a new stable 1.6 release has been fixed, so my guess is that this probably won't be fixed in 1.4. I'm working on backporting 1.6.0 to stable. Would you be interested in trying that backport to see if this problem goes away? -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
