Re: panic: System call lstat returning with 1 locks held

Attilio Rao wrote:
> 2008/1/29, Doug Barton <dougb_at_freebsd.org>:
>> Attilio Rao wrote:
>>> 2008/1/27, Doug Barton <dougb_at_freebsd.org>:
>>>> Attilio Rao wrote:
>>>>
>>>>> As my really first commit about VFS happened on 28 december (and it
>>>>> should also be a nop), and you reported a 23 december kernel, it seems
>>>>> like the problem was alredy there by time.
>>>> Ok, so you're off the hook. :) Interested in helping track down why
>>>> it's panic'ing?
>>> Sure, I'm testing a patch which instruments lockmgr with ktr and
>>> witness support.
>>> I will post later in the day in order to make consumer-available.
>> ok. FYI I tried torture-testing it today, and thing are looking a
>> little better. It only paniced once, with the same message as in the
>> subject but it was stat, not lstat. Unfortunately it didn't actually
>> do the dump, so I don't have a backtrace. If I can get it to
>> panic&dump I'll let you know.
> 
> Which fs? always NTFS?

Yes, sorry I wasn't clear. I'm using UFS2, NFS, MSDOSFS (occasionally)
CD9660 (occasionally) and NTFS (when it doesn't explode). No ZFS.

> I'm committing my WITNESS patch now to perforce so that other people
> can hopefully stress-test it before to be committed.

Ok, let me know when it's ready for a mere mortal like me to test. :)

BTW, I had something very odd happen just now. I had some time where I
didn't need to be at the keyboard, so I exited X, and at the console I
ran the following:

for file in /mnt/ad0s1/<blah>/*; do
cp $file /tmp/
cmp $file /tmp/${file##*/}
rm /tmp/${file##*/}
done

where the <blah> directory has thousands of jpegs, and /tmp is a
memory disk, in case it matters. I repeated this 4-6 times (not sure
exactly) and it never crashed. But when I tried to restart X I got all
sorts of odd errors, all related in some way to files (e.g.,
/var/log/Xorg.0.log rename, hsetroot not being able to find my desktop
background jpeg and dumping core, xauth not being able to lock and/or
rename ~/.Xauthority, etc.).

I finally gave up and rebooted, now everything is back to normal.
Unfortunately it just occurred to me that I should have tried
unmounting the NTFS volume first, d'oh. But there is definitely
something wrong with the NTFS code if it can scramble things that
badly even when it's not being accessed.

Doug

-- 

    This .signature sanitized for your protection