Opened 7 years ago

Closed 6 years ago

Last modified 5 years 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

Description

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 6 years ago.
ticket-13555-KDL-hrev52357-x86_64.txt (4.1 KB ) - added by fbrosson 6 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 by waddlesplash, 7 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, 6 years 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 6 years ago by fbrosson (previous) (diff)

comment:3 by pulkomandy, 6 years 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).

by fbrosson, 6 years ago

comment:4 by fbrosson, 6 years 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, 6 years ago

Resolution: fixed
Status: newclosed

Ha, another one that was fixed in hrev52646.

comment:6 by nielx, 5 years 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.