#13911 closed bug (fixed)
hrev51714-x86_gcc2_hybrid_anyboot kernel issue due to mild terminal usage and webpositive
| Reported by: | domcaf | Owned by: | bonefish |
|---|---|---|---|
| Priority: | normal | Milestone: | R1/beta2 |
| Component: | File Systems/packagefs | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
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.comfor which successful responses received.set -o vi.ping -c2 www.google.comfor 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!
Attachments (16)
Change History (32)
by , 6 years ago
| Attachment: | IMG_20171228_153212.jpg added |
|---|
by , 6 years ago
| Attachment: | IMG_20171228_153234.jpg added |
|---|
Initial debugger output after it started automatically, background is white, alternate photo in case more readable
by , 6 years ago
| Attachment: | bt-IMG_20171228_183315.jpg added |
|---|
kernel "bt" command output; alternate for readability alternative
by , 6 years ago
| Attachment: | TestBed-system-info_20171227.txt added |
|---|
Hardware info on which problem occurred using "sysinfo" utility when same system booted into Lubuntu Linux
comment:1 by , 6 years ago
| Keywords: | kernel debugger self start removed |
|---|---|
| Priority: | high → normal |
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?
comment:2 by , 6 years ago
memtest86+ ran thru 3 full cycles with no errors before I stopped testing. Please see attached screenshots. Will try to get you syslog soon.
by , 6 years ago
| Attachment: | memtest86plus-IMG_20171229_003013.jpg added |
|---|
memtest86+ results screenshot
comment:3 by , 6 years ago
| patch: | 0 → 1 |
|---|
by , 6 years ago
| Attachment: | memtest86plus-IMG_20171229_003025.jpg added |
|---|
memtest86+ results screenshot alternate for readability
comment:4 by , 6 years ago
| Component: | - General → File Systems/packagefs |
|---|---|
| Description: | modified (diff) |
| Owner: | changed from to |
| Platform: | x86 → All |
comment:5 by , 6 years ago
Looks like Haiku KDL's due to packagefs failing to read package content. Might be a problem with the thumb drive.
comment:7 by , 6 years ago
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.
comment:8 by , 6 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:9 by , 6 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
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.
comment:10 by , 6 years ago
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?
comment:11 by , 6 years ago
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.
comment:12 by , 6 years ago
| patch: | 1 → 0 |
|---|
comment:13 by , 6 years ago
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.
by , 6 years ago
| Attachment: | syslog_alt.jpg added |
|---|
syslog | tail from KDL alt for readability problems
comment:14 by , 6 years ago
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.
comment:15 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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.)
comment:16 by , 4 years ago
| Milestone: | Unscheduled → R1/beta2 |
|---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Initial debugger output after it started automatically, background is white.