Unmounting/mounting SD card while running causes driver panic

[eproxus]

If the SD card is unmount and re-mounted while the system is running, and one tries to read a file, the following panic occurs:

*** BSD PANIC *** Error while reading from SD. sr: 04100004

[c-mauderer]

Do you mean any software unmount and re-mount or do you mean that the card is removed physically and re-inserted?

In the second case: There is a detect pin on the SD card socket but it is currently not used in the software. So the driver doesn't know anything about the unmount and remount. Theoretically it might would be possible to do an unmount if someone removes the SD and do a new mount if it is inserted again. I didn't expect that this would be a normal use case on an embedded system.

[eproxus]

It's a physical remove and reinsert. So if I understand it correctly, we would need an interrupt for the SD card pin and probably handle this in the Erlang VM?

@peerst Do we need a special driver for this?

[peerst]

That has nothing to do with Erlang. I totally get that after removing/reinserting the card a following read/write could error out.

The keyword here is could ... not should always.

As a error having the whole system crash with a BSD panic is certainly suboptimal behavior.

Ideal would be behavior like in e.g. a Mac: Removing the card causes a umount -f and a warning message when there are no disk accesses on the meantime it should cause a error return but not a panic. After reinserting the card it gets remounted new file accesses should work again (not old open file descriptors of course)

That would make it possible to take the card out replace some compiled Erlang files and reload them, that would be a nice to have feature

[eproxus]

I think this possibly works now? I haven't seen this problem lately... can anyone confirm?

[eproxus]

Ok, unmounting works without panics. Re-mounting breaks:

grisp0009)1> ls().
at91_mci0: IO error; status MCI_SR = 0x4100005<CMDRDY,TXRDY,RTOE> cm
=ERROR REPORT==== 1-Jan-1988::00:05:48 ===
File operation error: eio. Target: robot/lib/stdlib-3.3/ebin/erl_internal.beam. Function: at91_mci0: IO error; status MCI_SR = 0x4100005<CMDRDY,TXRDY,RTOE> cmdget_file. Process: code_server.
at91_mci0: IO error; status MCI_SR = 0x4100005<CMDRDY,TXRDY,RTOE> cmd
=ERROR REPORT==== 1-Jan-1988::00:05:48 ===
File operation error: eio. Targetat91_mci0: IO error; status MCI_SR = 0x4100005<CMDRDY,TXRDY,RTOE> cm: robot/lib/stdlib-3.3/ebin/lib.beam. Function: get_file. Process: code_server.
*** ERROR: Shell process terminated! ***

=ERROR REPORT==== 1-Jan-1988::00:05:49 ===
Error in process <0.106.0> on node robot@grisp0009 with exit value:
{undef,[{lib,format_exception,
             [4,error,undef,
              [{erl_internal,bif,[lls,0],[]},
               {erl_lint,expr,3,[{file,"erl_lint.erl"},{line,2233}]},
               {erl_lint,exprs,3,[{file,"erl_lint.erl"},{line,2100}]},
               {erl_lint,exprs_opt,3,[{file,"erl_lint.erl"},{line,448}]},
               {erl_eval,check_command,2,[{file,"erl_eval.erl"},{line,173}]},
               {shell,exprs,7,[{file,"shell.erl"},{line,683}]},
               {shell,eval_exprs,7,[{file,"shell.erl"},{line,641}]},
               {shell,eval_loop,3,[{file,"shell.erl"},{line,626}]}],
              #Fun<shell.3.104321512>,#Fun<shell.2.104321512>,latin1],
             []},
        {shell,report_exception,4,[{file,"shell.erl"},{line,591}]},
        {shell,shell_rep,4,[{file,"shell.erl"},{line,552}]},
        {shell,server_loop,7,[{file,"shell.erl"},{line,235}]}]}
Eshell V8.3.5  (abort with ^G)
(robot@grisp0009)1> 

[holzingk]

I don't think that this will be anytime supported soon. Can this be closed @eproxus ?

[peerst]

Why would you want to close a unfixed problem?

First we need a decision that we won't fix it.

Currently its unclear to me what needs to be done. Actually its unclear if there is still a problem.

Are the Erlang errors really a indication that the remount failed? Or is Erlang using a still open file-descriptor? If the remount failed, why?