[vfs]: vnode is not becoming unbusy

[emitrax]

I packed the whole haiku source code and put it on a usbstick. Trying to unpacking with haiku on vmware causes KDL after a while. Screenshots attached.

Assigning this to myself since it's part of my HCD.

[emitrax]

This seems to be more a vfs bug. This time it was the page writer who causes the crash.

[atomozero]

I have reproduce the bug whit a centrino laptop (1,40 GHz) and 512 MB ram (Haiku see only 503 MB in about windows)

[emitrax]

Although the situation has improved since the introduction of the I/O scheduler, this still happens under heavy I/O operations.

The problem may be related to the ide/scsi module as Ingo(or Axel, don't really remember) suggested.

Quoting Axel from the haiku-gsoc mailing list, since this happens on low memory situation: "Codepaths necessary to recover from extreme memory shortage should have some preallocated buffers around they can use then". (Marcus?)

[bonefish]

I believe I have already mentioned that on the mailing list, this doesn't need to be any kind of deadlock due to memory problems. The "low memory handler" stack trace even suggests that it is still running (but was preempted). I still think it's possible that syncing the file in question simply took longer than the 10 seconds get_vnode() waits. IIRC you've already tried to increase the timeout without success, which could mean that the low memory handler was starved for some reason. Enabling scheduler tracing would help to verify this.

If you have a test case that allows to reproduce the problem more or less reliably, I could have a look.

[emitrax]

Replying to bonefish:

If you have a test case that allows to reproduce the problem more or less reliably, I could have a look.

I used to trigger this by unpacking the haiku source tree from a usb stick, but I don't know if that's still the case.

[emitrax]

I thought I've added the scheduler tracing support, but seems like I needed to run jam -a to include it. Obviously I realized that only when I triggered the bug. A bit too late.

Anyway, while I rebuild the image in order to re-run the test, if you feel you wanna look into it, try the following to trigger it

#!/bin/sh
for a in `seq 1 1000`
do
  for b in `seq 1 1000`
  do
    for c in `seq 1 1000`
    do
       dd if=/dev/zero of=file bs=1 count=`expr $a \* $b \* $c`;
       rm file;
    done
  done
done

[luroh]

emitrax: how's the build coming along? :-)
Seriously though, would you say this ticket is still valid?
Running your above script for hours on real hw results not in a KDL but in a freeze. Pic of "<F12> + bt" attached. Should I open a new ticket?

[luroh]

36733, gcc2, trunk.

Tried to repeat the original problem, unpacking the Haiku source code from a USB stick in VMware, but no KDL. After many hours, it had successfully extracted the 800 MB zip file. Also tried running the above script for 10 hours without any problem. Time to close this one?

[bonefish]

Yep, closing. Please reopen, if the problem still persists.