[haiku-gsoc] Re: [HCD]: Bfs bug #1

2008/6/22 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>
> On 2008-06-22 at 14:30:00 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
> wrote:
>> Another test. Different approach, different behavior.
>>
>> To try and support my thesis about "starvation", I ran the test on vmware
>> and left the computer, while usually I used to use it regurarly while
>> running
>> the test, so this time teorically all CPU would have been reserved to
>> Haiku, and thus the low memory thread should have been able to free the
>> vnode in 10 seconds.
>
> BTW, what is you machine's configuration? Host system physical memory,
> memory assigned to the virtual machine, size of the kernel tracing buffer.

Vmware runs with 256MB of RAM on my laptop with CPU speed at 1GHz.
The total amount of memory on my system is 1GB. Kernel tracing buffer
is set at 2MB.

>
>> The test this time in fact, last 3 hours before crashing (nice nap by
>> the way :-) ),
>> with the same error, but the output of tar was quite different. See
>> screenshot attached.
>> Any comments?
>
> Mmh, the stack trace looks like the one attached to the ticket. Not sure
> what to make of the kernel tracing output. Seems neither related nor wrong.

Yes the stack trace is the same, but if you look at the output in the
terminal before it crashed, the operation already failed with an unknown system
error. (Ups I just realized I attached the wrong screenshot in my
previous email,
sorry about that).

>
>> Anyway, I wanted to test with condition variable, but I'm not sure on
>> how to proceed, despite of that
>> though, I think we should hanle the error E_BUSY differently, because
>> 10 seconds with our current
>> scheduler, and with not I/O scheduler doesn't seem to be a good choice
>> on slow system like running
>> on vmware is.
>
> You would need to remove the vnode::busy flag and add a ConditionVariable*
> busy_condition instead. When NULL the vnode is not busy. Whereever a vnode
> is currently marked busy, a condition variable needs to be created and
> busy_condition set respectively. In get_vnode() where one waits for vnode
> to become unbusy, one needs to wait for the condition variable instead of
> snooze()ing (everything else remains the same). In most cases the condition
> variable can be allocated on the stack, since it is unset in the same
> function, but unfortunately new_vnode() also marks the vnode busy -- there
> it needs to be allocated on the heap and deleted in
> publish_vnode()/remove_vnode().

Ok, my only problem was that the field busy was declared as a bit fields
of 1, and if I remove that and add a conditionVariable the size of structure
would change drastically.

>
>> Anyway, is Marcus subscribed to this mailing list?
>
> I don't think he is.
>
>> What does he think
>> about the possibility of being
>> a scsi problem?
>
> He's probably not aware of the bug yet. Respective comments should be added
> to the ticket and he should be notified.

Ok, I will.

>
> CU, Ingo
>
>


Regards,
-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it

Attachment: vmware-crash-1.jpg
Description: JPEG image

Other related posts: