#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)
Change History (8)
comment:1 by , 7 years ago
comment:2 by , 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 everyone.
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.
comment:3 by , 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 , 6 years ago
| Attachment: | ticket-13555-KDL-hrev52357-x86_gcc2.txt added |
|---|
by , 6 years ago
| Attachment: | ticket-13555-KDL-hrev52357-x86_64.txt added |
|---|
comment:4 by , 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 , 6 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Ha, another one that was fixed in hrev52646.
comment:6 by , 5 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
(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.