Opened 6 years ago

Last modified 5 years ago

#9900 reopened bug

"Double fault!", copying from BFS partition on USB external drive

Reported by: ttcoder Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no 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 6 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 6 years ago.
doublefault-redux_1.jpg (133.3 KB) - added by ttcoder 6 years ago.
doublefault-redux_2.jpg (79.3 KB) - added by ttcoder 6 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 years ago by anevilyak

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

Changed 6 years ago by ttcoder

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 Changed 6 years ago by bonefish

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.

Changed 6 years ago by ttcoder

Attachment: doublefault-redux_0.jpg added

Changed 6 years ago by ttcoder

Attachment: doublefault-redux_1.jpg added

Changed 6 years ago by ttcoder

Attachment: doublefault-redux_2.jpg added

comment:3 Changed 6 years ago by ttcoder

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 Changed 6 years ago by bonefish

Resolution: fixed
Status: newclosed

Should be fixed in hrev45906.

comment:5 Changed 6 years ago by bonefish

Resolution: fixed
Status: closedreopened

Doesn't work. Reverted in hrev45909.

comment:6 Changed 5 years ago by diver

Component: - GeneralSystem/Kernel
Note: See TracTickets for help on using tickets.