Bug 207621

Summary: inserting SATA SSD into BananaPi causes problems reading from SD card
Product: Base System Reporter: fulda
Component: armAssignee: Emmanuel Vadot <manu>
Status: Closed Overcome By Events    
Severity: Affects Some People CC: jmcneill, manu, manu, pi
Priority: --- Keywords: patch
Version: CURRENT   
Hardware: arm   
OS: Any   
Attachments:
Description Flags
back trace - short
none
back trace - long version
none
dmesg from FreeBSD-11.0-CURRENT-arm-armv6-BANANAPI-20160408-r297692
none
output + backtrace / crash on version FreeBSD-11.0-CURRENT-arm-armv6-BANANAPI-20160408-r297692 none

Description fulda 2016-03-01 18:38:24 UTC
This bug affect boards with Allwinner A20 chips. Once they have attached SATA SSD disk (no necessary to mount, only plugged in), then you will have troubles with reading more files from SD card.
I did small experiment - download last image (same experience with previous one), boot, and without any modifications start reading files from SD. Attached sata ssd have no UFS/FAT partition and no any partition is mounted. (my hardware is Banana PI M1)

Here is three examples:
read disk using tar with transfer data to another process (wc) and without (to dev/null)

Outputs from my experiment follows.

(Other affected people: 
https://lists.freebsd.org/pipermail/freebsd-arm/2016-February/013229.html
https://lists.freebsd.org/pipermail/freebsd-arm/2016-February/013274.html )

Jindra

---------------------------------------------
SATA disk attached, but not used:
---------------------------------------------
root@a20:~ # uname -a

FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 05:22:46 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20  arm
root@a20:~ # tar cf - /usr | wc

tar: Removing leading '/' from member names
panic: vm_page_insert_after: page already inserted
cpuid = 0
KDB: enter: panic
[ thread pid 679 tid 100084 ]
Stopped at      $d.7:   ldrb    r15, [r15, r15, ror r15]!
db>

---------------------------------------------
root@a20:~ # tar cf /dev/null /usr

tar: Removing leading '/' from member names
panic: vm_page_insert_after: page already inserted
cpuid = 0
KDB: enter: panic
[ thread pid 644 tid 100067 ]
Stopped at      $d.7:   ldrb    r15, [r15, r15, ror r15]!
db>


---------------------------------------------
NO SATA disk attached:
---------------------------------------------

root@a20:~ # uname -a

FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 05:22:46 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20  arm
root@a20:~ # tar cf - /usr | wc

tar: Removing leading '/' from member names
 5994501 28169833 716206080
root@a20:~ #
root@a20:~ # halt

Feb 17 05:37:21 a20 halt: halted by root

Feb 17 05:37:21 a20 syslogd: exiting on signal 15

Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...2 1 0 0 done
All buffers synced.
lock order reversal:
 1st 0xc45b3db4 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222
 2nd 0xc432cc94 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2617
stack backtrace:
lock order reversal:
 1st 0xc45b3b74 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222
 2nd 0xc45b35d4 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:994
stack backtrace:
Uptime: 3m12s

The operating system has halted.
Please press any key to reboot.
Comment 1 fulda 2016-03-02 12:00:28 UTC
Regarding mail from Franco Ricci the problem occur only during reading from SD. Once system is installed on SATA SSD problem does not appear.

Ref.: https://lists.freebsd.org/pipermail/freebsd-arm/2016-March/013338.html
Comment 2 Emmanuel Vadot 2016-03-02 18:54:55 UTC
Hi,

Could you post a full backtrace after the panic (command is bt).
I haven't managed to make SATA works on my allwinner boards so for now I can't help you more.
Comment 3 fulda 2016-03-02 20:02:16 UTC
Created attachment 167653 [details]
back trace - short

Oops, sorry I forget.
I prepared two versions - version sata_bt1 is short --> back trace only
sata_bt2 --> full boot + login + fail + back trace.

Jindra
Comment 4 fulda 2016-03-02 20:04:36 UTC
Created attachment 167654 [details]
back trace - long version

long
Comment 5 Emmanuel Vadot 2016-03-07 19:41:09 UTC
I cannot reproduce your crash on my olimex a20-som-evb.
Could you test old snapshot to find if it's new or not ?

Thanks,
Comment 6 fulda 2016-03-07 19:57:36 UTC
Hello,

I was tested it with those two images:
FreeBSD-11.0-CURRENT-arm-armv6-BANANAPI-20160113-r293801.img
FreeBSD-11.0-CURRENT-arm-armv6-BANANAPI-20160217-r295683.img

I have no older image :(
Comment 7 Emmanuel Vadot 2016-04-05 04:05:10 UTC
I have now a BananaPi.

Using jmcneill@ clk branch all is good (didn't test the snapshots).

So we will wait that the clk bits are commited and come back to you to confirm that the bug is resolved.
Comment 8 Emmanuel Vadot 2016-04-09 08:24:44 UTC
Could you test the last snapshot (20160408) and report back to us the status ?

Thanks,
Comment 9 fulda 2016-04-10 13:59:24 UTC
Created attachment 169154 [details]
dmesg from FreeBSD-11.0-CURRENT-arm-armv6-BANANAPI-20160408-r297692
Comment 10 fulda 2016-04-10 14:00:38 UTC
Created attachment 169155 [details]
output + backtrace / crash on version FreeBSD-11.0-CURRENT-arm-armv6-BANANAPI-20160408-r297692
Comment 11 fulda 2016-04-10 14:03:11 UTC
Hello Emmanuel,

I have only bad news - the situation is still same, see attached files.

Jindra
Comment 12 Emmanuel Vadot freebsd_committer freebsd_triage 2016-06-27 13:45:57 UTC
Could you test ALPHA5 snapshot ?
I, and others, succesfully use SATA and SSD on different A20 boards.
Comment 13 fulda 2016-06-28 19:03:43 UTC
It is still same.
The trick is, that you must read from SD card with having connected SSD.
Once you are not using SD, you will never see this problem.
Comment 14 Jared McNeill freebsd_committer freebsd_triage 2016-07-13 23:25:04 UTC
I see the same behaviour on Cubieboard 2 and ALPHA6.
Comment 15 Emmanuel Vadot freebsd_committer freebsd_triage 2020-09-17 09:33:37 UTC
Closing this for now, if it's still happening with FreeBSD-CURRENT, please reopen the bug.