Reproducible kernel panic while backing up to NFS

[dstromberg]

Hi.

I have a reproducible kernel panic, using Haiku R1 Alpha 3 -r 41650 - IOW, a very recent nightly build. I'm running it in VirtualBox 3.2.8 OSE hrev64453 with an emulated, bridged Intel Pro/1000 MT Desktop 82540EM network adapter.

When it happens, I'm testing a backup engine written in CPython, using an unmodified /boot/common/bin/python. This code is at ​http://stromberg.dnsalias.org/~dstromberg/backshift/

The engine reads and writes an NFS filesystem. Some of the directories are quite large.

Running the engine's automated tests against a local filesystem (created by the installer) works well, despite a plethora of such tests.

The script tracebacks on an os.fsync(), and then crashes. If I skip the fsync with the equivalent of "if os.uname()[0] != 'Haiku'", it still crashes, but without a (Python) traceback (or rather, no Python traceback until I type "co" in the kernel debugger).

Haiku enters KDL of its own volition.

I'm very inexperienced with BeOS/Haiku, and only slightly experienced with VirtualBox - what's the best way to get information to you, the kernel developers, for such a crash?

I'll be attaching a screenshot with the kernel traceback.

Thanks!

[dstromberg]

This happens with an Ubuntu 10.10 NFS server. The relevant exportfs line looks like: /mnt/backshift 10.10.10.11(rw,sync,no_root_squash,insecure)

I mount the filesystem on Haiku with: mount_nfs 10.10.10.10:/mnt/backshift /mnt/backshift 0 0

(I've doctored the IP's and paths, but the gist is there)

[dstromberg]

The command I'm running the backup engine with, at the time of a crash, is (for example):

find / /boot -xdev -printf '%s %p\0' | ~/src/home-svn/backshift/trunk/backshift --save-directory /mnt/backshift/save-directory --backup --subset everything --progress-report full

[dstromberg]

Also, the NFS filesystem in question is on the large side:

$ df -h /mnt/backshift
Filesystem Size Used Avail Use% Mounted on
/dev/sdd5 917G 631G 287G 69% /mnt/backshift

However, no single file in the filesystem should be larger than about 3 megabytes; the backup engine chops large files up into manageable pieces.

[mmadia]

R1 Alpha 3 has not yet been released. This was with an R1 Alpha 3 Release Candidate image.

[waddlesplash]

Probably the same vnode/fd ref count issues that were fixed over the past few years; please reopen if the issue persists.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone