#9900 closed bug (fixed)
"Double fault!", copying from BFS partition on USB external drive
Reported by: | ttcoder | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta4 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
"Luckily" this is reproducible so far: I've isolated the one mp3 file that triggers the KDL, 2 or 3 times in a row.
The backtrace is two or three screens long. If I try to "continue" out of it I get dropped right back to KDL.
Attachments (4)
Change History (13)
comment:1 by , 11 years ago
by , 11 years ago
Attachment: | DoubleFault_USB.jpg added |
---|
With another two pages similar to this one.. Note: it seems the stack trace varies slightly each time I try to copy the file (though the "Double fault!" message does not)
comment:2 by , 11 years ago
Actually the last part of the stack trace would be quite interesting as one would see how the problem started. What can be seen now is that there's an IO request which is processed synchronously (as the underlying driver doesn't seem to support handling I/O requests asynchronously) but it still uses the finished-callback mechanism that is normally used for asynchronous processing. So it ends up performing the iteration through the request recursively, running out of stack.
I have the suspicion the problem is caused by the VFS providing an io()
hook, which lets the VFS assume asynchronous request handling is supported, while the hook itself just calls the synchronous handler. But it would be nice to verify that with the stack trace.
by , 11 years ago
Attachment: | doublefault-redux_0.jpg added |
---|
by , 11 years ago
Attachment: | doublefault-redux_1.jpg added |
---|
by , 11 years ago
Attachment: | doublefault-redux_2.jpg added |
---|
comment:3 by , 11 years ago
Here's the result of today's attempt. Tell me if you need something else (listusb, listdev ..etc).
In case that's useful, I'll mention that actually I had to try twice, today: at first attempt, the file copied cleanly, from both 'cp' and from Tracker. I had booted 10 mins before, used W+ a bit, then plugged and unplugged another USB device on another port, to transfer files for another ticket. Then I plugged the external hard-drive and tried, but I was unable to trigger the crash in that session.
So I rebooted, then went straight to the right Tracker window on the external hard-drive, and this time the double-fault occured right away.
comment:5 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Doesn't work. Reverted in hrev45909.
comment:6 by , 10 years ago
Component: | - General → System/Kernel |
---|
comment:7 by , 3 years ago
This should be fixed by hrev56161. I know a decade is a long time, but any chance you have to reproduce this, please at least make the attempt :)
comment:8 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Yea that's quite the archeology deep-dive, even by Haiku standards 8-)
Closing as fixed, seeing as I have absolutely no recollection of the HW/SW/gear that was involved at the time (even my Long-Term-Computer-Like(tm) memory can fail me *g*)
comment:9 by , 3 years ago
Milestone: | R1 → R1/beta4 |
---|
Without seeing at least some of the backtrace, there isn't really much to say about this problem.