[9fans] 9PI kernel stability

[9fans] 9PI kernel stability

[Dante]

Dear 9ers,

I have noticed 2 interesting symptoms while running my Raspberry PI
(Model B, 512MB) for quite some time.
They look to me as some sort of race conditions. If anyone has seen
these before or has an idea what's wrong, please help:

1. Text windows sometimes get black "garbage" on the background that
refuses to go, even if text is scrolled over it.
     The size of the "garbage" is about 1 character, and looks like an
"island". That is, neither meaningful symbol, nor random pattern.

2. When writing large files to an USB memory stick FAT file system (say,
a large TAR archive), the mount is lost, leading to a truncated file.

Any idea how I could start debugging this?
/dev/kmesg is not verbose enough to get anything out of it.

Thanks!
Dante

Re: [9fans] 9PI kernel stability

[Richard Miller]

> 1. Text windows sometimes get black "garbage" on the background that
> refuses to go, even if text is scrolled over it.
>      The size of the "garbage" is about 1 character, and looks like an
> "island". That is, neither meaningful symbol, nor random pattern.

There are known race conditions in the soft cursor code (not just on
the pi).  Could the black island be a "mouse dropping"?

> 2. When writing large files to an USB memory stick FAT file system (say,
> a large TAR archive), the mount is lost, leading to a truncated file.

Try putting the memory stick on a powered usb hub and see if that works
better.

Re: [9fans] 9PI kernel stability

[Dante]

On 09.02.2015 10:48, Richard Miller wrote:
>> 1. Text windows sometimes get black "garbage" on the background that
>> refuses to go, even if text is scrolled over it.
>>      The size of the "garbage" is about 1 character, and looks like an
>> "island". That is, neither meaningful symbol, nor random pattern.
>
> There are known race conditions in the soft cursor code (not just on
> the pi).  Could the black island be a "mouse dropping"?

Yes, that's  "mouse droppings" :-).

>
>> 2. When writing large files to an USB memory stick FAT file system
>> (say,
>> a large TAR archive), the mount is lost, leading to a truncated file.
>
> Try putting the memory stick on a powered usb hub and see if that works
> better.

I did, and for this reason I suspect the USB driver and not the power
supply.

Re: [9fans] 9PI kernel stability

[Richard Miller]

>>> 2. When writing large files to an USB memory stick FAT file system
>>> (say,
>>> a large TAR archive), the mount is lost, leading to a truncated file.
>>
>> Try putting the memory stick on a powered usb hub and see if that works
>> better.
>
> I did, and for this reason I suspect the USB driver and not the power
> supply.

Where is the large file coming from?  I've just copied some 100MB files
from /dev/zero and from a 9p server to /n/sdU0.0, with no problem.

Maybe something about your particular memory stick is less compatible
with Plan 9?

Re: [9fans] 9PI kernel stability

[Dante]

It's a tar of dante's home directory.
Alternatively, it's a tar of the whole fossil partition.
Again alternatively, I piclone the system to a new SD disk.

Of course, it might be my Pi or my powered USB hub (I use one) or my SD
cards (I have more than one).
The problem is that I can't isolate the origin of the error...

Thanks!
Dante

On 09.02.2015 16:52, Richard Miller wrote:
>>>> 2. When writing large files to an USB memory stick FAT file system
>>>> (say,
>>>> a large TAR archive), the mount is lost, leading to a truncated
>>>> file.
>>>
>>> Try putting the memory stick on a powered usb hub and see if that
>>> works
>>> better.
>>
>> I did, and for this reason I suspect the USB driver and not the power
>> supply.
>
> Where is the large file coming from?  I've just copied some 100MB files
> from /dev/zero and from a 9p server to /n/sdU0.0, with no problem.
>
> Maybe something about your particular memory stick is less compatible
> with Plan 9?

Re: [9fans] 9PI kernel stability

[Lyndon Nerenberg]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]


On Feb 9, 2015, at 1:48 AM, Richard Miller <9fans@hamnavoe.com> wrote:

>> 1. Text windows sometimes get black "garbage" on the background that 
>> refuses to go, even if text is scrolled over it.
>>     The size of the "garbage" is about 1 character, and looks like an 
>> "island". That is, neither meaningful symbol, nor random pattern.
> 
> There are known race conditions in the soft cursor code (not just on
> the pi).  Could the black island be a "mouse dropping"?

This sounds like a bug exposed by drawterm, worked around by having draw page flip between re-writes.  This cropped up around 2010 I think.  Might it be related?


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 817 bytes --]

Re: [9fans] 9PI kernel stability

[Dante]

Wrong, there's  no drawterm on the monitor connected over HDMI :-).


On 09.02.2015 23:41, Lyndon Nerenberg wrote:
> On Feb 9, 2015, at 1:48 AM, Richard Miller <9fans@hamnavoe.com> wrote:
>
>>> 1. Text windows sometimes get black "garbage" on the background that
>>> refuses to go, even if text is scrolled over it.
>>>     The size of the "garbage" is about 1 character, and looks like an
>>> "island". That is, neither meaningful symbol, nor random pattern.
>>
>> There are known race conditions in the soft cursor code (not just on
>> the pi).  Could the black island be a "mouse dropping"?
>
> This sounds like a bug exposed by drawterm, worked around by having
> draw page flip between re-writes.  This cropped up around 2010 I
> think.  Might it be related?

Re: [9fans] 9PI kernel stability

[erik quanstrom]

On Tue Feb 10 00:22:32 PST 2015, subscriptions@posteo.eu wrote:
> Wrong, there's  no drawterm on the monitor connected over HDMI :-).
>

perhaps the missing bit here is that drawterm shares almost all its code with the plan 9
kernel and draw libraries.  so it makes sense to suspect that the same code might
have the same bug.

- erik

Re: [9fans] 9PI kernel stability

[Dante]

thanks, i understand

On 10.02.2015 15:00, erik quanstrom wrote:
> On Tue Feb 10 00:22:32 PST 2015, subscriptions@posteo.eu wrote:
>> Wrong, there's  no drawterm on the monitor connected over HDMI :-).
>>
>
> perhaps the missing bit here is that drawterm shares almost all its
> code with the plan 9
> kernel and draw libraries.  so it makes sense to suspect that the same
> code might
> have the same bug.
>
> - erik