Opened 4 years ago

Last modified 3 days ago

#12408 assigned bug

PANIC: Invalid concurrent access to page ... (start), currently accessed by 65534

Reported by: ttcoder Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #12518, #13205
Has a Patch: no Platform: x86

Description

This just in from Dane trying out hrev49662 ; apparently there were a string of userland Debugger triggers, followed by a kernel-land (KDL) panic.

The stack crawl mentions X86PagingMethodPAE::Allocate32BitPage() called from _user_load_image(). The bottom of screen gives some unusual extra information, and ends with "READ FAULT". See attached.

Attachments (1)

FullSizeRender.jpg (939.6 KB) - added by ttcoder 4 years ago.
panic: invalid concurrent access to page ..etc

Download all attachments as: .zip

Change History (8)

Changed 4 years ago by ttcoder

Attachment: FullSizeRender.jpg added

panic: invalid concurrent access to page ..etc

comment:1 Changed 4 years ago by diver

Component: - GeneralSystem/Kernel
Owner: changed from nobody to bonefish
Status: newassigned

comment:2 Changed 4 years ago by ttcoder

More details:

That's a never seen before(?) KDL message, this should be interesting! @bonefish This might be reproducible (occured after just 3 CDs) so if you want Dane to collect more information when/if this occurs again, say the word :-)

Anyway, the details: We're attempting to put 49662 in production (versus 49137 we're currently using) to benefit from the put_fd() fix ..etc. Things looked good, until Dane attempted to rip audio CDs with TunePrepper:

My first attempt under the new Haiku didn't go super well,
after about three rips of CDs, I got a crash. When trying
to save debug information, the window kept prompting me to
save debugs for one thread after another, And eventually when
I clicked the button enough times, I went to the white screen
of death. Attached is the KDL. Confirming, this is under 49662
of haiku and the latest tune prepper that does auto Ripp.

We were 100% stable at CD ripping in 49137 (after mmlr's fixes), so it's possible that another problem in kernel-land was lurking, and decided to un-lurk now. That's all we have for now. When my back-log diminishes in a week or two I'll take a look at CD ripping myself too (that hrev has been 100% stable for me otherwise).

I'll ask Dane if he has the userland debugger reports on his Desktop too.

comment:3 Changed 4 years ago by bonefish

Apparently the vm_page structure has been overwritten with bogus data. Unfortunately little more can be said from the data available. It would be interesting to see which areas adjoin the are with the vm_page structures. Maybe that would suggest who might be to blame.

comment:4 Changed 2 years ago by korli

Platform: Allx86

comment:5 Changed 2 years ago by korli

As with #11744, maybe it would be worth trying to switch to X86PagingMethod32Bit? The kernel drivers setting is "4gb_memory_limit". Uncomment to enable.

comment:6 Changed 3 days ago by waddlesplash

Blocking: 12518 added

comment:7 Changed 3 days ago by waddlesplash

Blocking: 13205 added
Note: See TracTickets for help on using tickets.