Opened 3 years ago

Closed 20 months ago

Last modified 4 months ago

#13555 closed bug (fixed)

Destroying ramdisk without unmounting first causes KDL

Reported by: waddlesplash Owned by: nobody
Priority: normal Milestone: R1/beta2
Component: System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


Not sure what component to file this under.

If one creates a RAMdisk and initializes with BFS...

ramdisk create -s 1gb
mkfs -q -t bfs /dev/disk/virtual/ram/0/raw RAMses
mountvolume RAMses

and then attempts to delete it without unmounting first

ramdisk delete 0

there is an instant KDL (inside the BFS driver, of course.)

It looks like the BFS driver does not have the chance to fully deinitialize before the disk is destroyed. Manually unmounting and then deleting the ramdisk works just fine.

Attachments (2)

ticket-13555-KDL-hrev52357-x86_gcc2.txt (3.9 KB ) - added by fbrosson 23 months ago.
ticket-13555-KDL-hrev52357-x86_64.txt (4.1 KB ) - added by fbrosson 23 months ago.

Download all attachments as: .zip

Change History (8)

comment:1 by waddlesplash, 3 years ago

(I'm experimenting with using a ramdisk for building ports on the slave machines to speed up stuff, but I'm a bit wary of doing so when an improperly executed reboot could cause a KDL...)

If someone could take a look at this, or possibly point me in the right direction so that I could attempt a fix (I've no idea where to begin), I'd very much appreciate it.

comment:2 by fbrosson, 23 months ago

IMHO this bug should be fixed before R1/beta1.
Forgetting to unmount a volume before calling ramdisk delete <n>can happen to anyone.
Users hitting this bug in a beta release will be very upset.
We don't want users to go away for this reason.
This bug should not be too hard to fix for a kernel developer who already knows where to look.

Last edited 23 months ago by fbrosson (previous) (diff)

comment:3 by pulkomandy, 23 months ago

ramdisk are not a common thing for users to do. And, it's a beta, there will be bugs, many of them more embarassing than this one.

This bug should not be too hard to fix for a kernel developer who already knows where to look.

What do you know? Patches welcome if it's easy for you ;)

where to look: src/add-ons/kernel/drivers/disk/virual/ram_disk, probably?

There isn't even a log of the KDL in the ticket, that would make it easier to investigate (I don't feel like crashing my own system to grab it).

comment:4 by fbrosson, 23 months ago

The 2 logs were obtained with these commands:

~> ramdisk create -s 32mb
RAM disk device created as "/dev/disk/virtual/ram/0/raw"
~> mkfs -q -t bfs /dev/disk/virtual/ram/0/raw ramwork
DiskDeviceJobQueue::Execute(): executing job: Q28BPrivate13InitializeJob
~> mountvolume ramwork
Volume `ramwork' mounted successfully at '/ramwork'.
~> ramdisk delete 0

comment:5 by waddlesplash, 20 months ago

Resolution: fixed
Status: newclosed

Ha, another one that was fixed in hrev52646.

comment:6 by nielx, 4 months ago

Milestone: UnscheduledR1/beta2

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

Note: See TracTickets for help on using tickets.