Opened 9 years ago

Last modified 2 years 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: #13205 Blocking: #12518
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 9 years ago.
panic: invalid concurrent access to page ..etc

Download all attachments as: .zip

Change History (9)

by ttcoder, 9 years ago

Attachment: FullSizeRender.jpg added

panic: invalid concurrent access to page ..etc

comment:1 by diver, 9 years ago

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

comment:2 by ttcoder, 9 years ago

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 by bonefish, 9 years ago

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 by korli, 7 years ago

Platform: Allx86

comment:5 by korli, 7 years ago

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 by waddlesplash, 5 years ago

Blocking: 12518 added

comment:7 by waddlesplash, 5 years ago

Blocking: 13205 added

comment:8 by waddlesplash, 2 years ago

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