Opened 11 years ago

Closed 2 years ago

Last modified 2 years ago

#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)

DoubleFault_USB.jpg (151.0 KB ) - added by ttcoder 11 years ago.
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)
doublefault-redux_0.jpg (106.3 KB ) - added by ttcoder 11 years ago.
doublefault-redux_1.jpg (133.3 KB ) - added by ttcoder 11 years ago.
doublefault-redux_2.jpg (79.3 KB ) - added by ttcoder 11 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by anevilyak, 11 years ago

Without seeing at least some of the backtrace, there isn't really much to say about this problem.

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

Attachment: doublefault-redux_0.jpg added

by ttcoder, 11 years ago

Attachment: doublefault-redux_1.jpg added

by ttcoder, 11 years ago

Attachment: doublefault-redux_2.jpg added

comment:3 by ttcoder, 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:4 by bonefish, 11 years ago

Resolution: fixed
Status: newclosed

Should be fixed in hrev45906.

comment:5 by bonefish, 11 years ago

Resolution: fixed
Status: closedreopened

Doesn't work. Reverted in hrev45909.

comment:6 by diver, 10 years ago

Component: - GeneralSystem/Kernel

comment:7 by waddlesplash, 2 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 ttcoder, 2 years ago

Resolution: fixed
Status: reopenedclosed

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 ttcoder, 2 years ago

Milestone: R1R1/beta4
Note: See TracTickets for help on using tickets.