hrev51714-x86_gcc2_hybrid_anyboot kernel issue due to mild terminal usage and webpositive

[domcaf]

hrev51714-x86_gcc2_hybrid_anyboot kernel issue due to mild terminal usage and webpositive

REPRODUCTION STEPS:

• Run from USB thumbdrive on physical hardware.
• Make it to desktop.
• Enter WiFi/WPA credentials.
• Open terminal and issue following commands:
• ping -c2 www.yahoo.com for which successful responses received.
• set -o vi.
• ping -c2 www.google.com for which successful responses received.
• {{{perl -v" which produces expected output.
• Closed terminal by typing using ctrl-d key sequence.
• Opened webpositive with no success.
• Open terminal again with no success.

• Kernal debugger starts up by itself. See attached photos of white background debugger output and "bt" command output. Multiple photos of each provided in case one photo is easier to view than another.

• Was able to get same behavior multiple times using above steps. Additional hardware info also attached in case this is processor/hardware specific.

• Thanks for reviewing!

[domcaf]

Initial debugger output after it started automatically, background is white.

[domcaf]

Initial debugger output after it started automatically, background is white, alternate photo in case more readable

[domcaf]

kernel "bt" command output

[domcaf]

kernel "bt" command output; alternate for readability alternative

[domcaf]

Hardware info on which problem occurred using "sysinfo" utility when same system booted into Lubuntu Linux

[domcaf]

Bios info # 1

[domcaf]

Bios info # 2

[domcaf]

Bios info # 3

[domcaf]

Bios info # 4

[domcaf]

Bios info # 5

[waddlesplash]

Can you please get the file /var/log/syslog from the booted Haiku system (before you reproduce the crash, of course) and upload it here? (Or is that somehow not possible?)

Secondly, have you run a memtest86+ on this system recently?

[domcaf]

memtest86+ ran thru 3 full cycles with no errors before I stopped testing. Please see attached screenshots. Will try to get you syslog soon.

[domcaf]

memtest86+ results screenshot

[domcaf]

memtest86+ results screenshot alternate for readability

[diver]

Looks like Haiku KDL's due to packagefs failing to read package content. Might be a problem with the thumb drive.

[domcaf]

I'll try a different thumbdrive and post back what happens.

[domcaf]

I was NOT able to reproduce this bug when I used a different thumb drive. Sorry for the "red herring". I will try multiple thumb drives BEFORE reporting other issues that I might experience. Thank you all for your patience. I consider this issue resolved.

[mmlr]

It should still not crash in this way. The page fault indicates that some error condition isn't checked/handled. Probably a buffer that failed to allocate/transfer but was then still used. The error should bubble up and eventually be shown to the user somehow, not KDL.

Since it seems that you are able to readily reproduce the issue, can you keep that stick around for a while so that any investigation may get more info if needed? Could you try to reproduce the issue and print the last part of the syslog in KDL with 'syslog | tail' and post the output here? Maybe the issue triggering this leaves some traces which may make it easier to find the problem.

[domcaf]

I've set aside the thumb drive for additional research on this issue. Do you want additional reproduction attempts with same build as initially reported or a more recent one?

[mmlr]

It is well possible that the problem only occurs when hitting certain blocks of the stick or only with a certain access pattern. Since modifying the FS layout by updating packages may make the nicely reproducible test case go away, I'd stick to the current setup for now. Once the problem is better understood updating may make sense.

[domcaf]

Got to point where I couldn't get system to boot off of thumb drive so I re-imaged it with same build as reported and tried again. With re-imaged thumb drive, I'd get to the blue background of desktop then after about 30 seconds or so ended up in kernel debugger, KDL. Attached is "bt" and "syslog | tail" output photos.

[domcaf]

bt output

[domcaf]

bt_alt for readability problems

[domcaf]

syslog | tail from KDL

[domcaf]

syslog | tail from KDL alt for readability problems

[mmlr]

Thanks for the update.

The syslog shows that it's a timeout on the USB device as the reason why the read fails. Since the block number seems to have changed, it doesn't look like a specific region of the device being faulty. So there probably is a compatibility issue that leads to the device timeouts. This is an issue that should be investigated separately though.

What should be solved here is that the read error apparently isn't handled and therefore leads to the KDL instead of bubbling up.

[waddlesplash]

The actual read timeouts were likely solved by the XHCI changes, and the KDL is yet another one that was solved by hrev52646. (I think we are somewhere in excess of 15-20 tickets closed by that now.)

[nielx]

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