rand_bytes() crashes tcpip about resea HOT 8 CLOSED

Could you show me QEMU command-line options and the crash log? I suppose you haven't specify the CPU generation (i.e. -cpu IvyBridge,rdtscp).

from resea.

I just added rtl8139 to test something but I had a crash before modifying libs/common/arch/x64/arch.mk

QEMUFLAGS += -m 512 -cpu IvyBridge,rdtscp -rtc base=utc -serial mon:stdio
QEMUFLAGS += -no-reboot -boot d -device isa-debug-exit
QEMUFLAGS += -netdev user,id=net0,hostfwd=tcp:127.0.0.1:1234-:80
QEMUFLAGS += -netdev user,id=net1,hostfwd=tcp:127.0.0.1:1235-:80
QEMUFLAGS += -device e1000,netdev=net0,mac=52:54:00:12:34:56
QEMUFLAGS += -device rtl8139,netdev=net1,mac=10:00:10:22:33:44
QEMUFLAGS += -object filter-dump,id=fiter0,netdev=net0,file=network.pcap
QEMUFLAGS += $(if $(SMP), -smp $(SMP))
QEMUFLAGS += $(if $(GUI),,-nographic)

from resea.

[ps2kbd] ready
[display] ready
[appmgr] ready
[fatfs] servers/fatfs/main.c:39 PANIC: failed to locate a FAT file system
[fatfs] WARN: Backtrace:
[fatfs] WARN: #0: 000000000100076e main()+0x58e
[e1000] initialized the device
[e1000] MAC address = 52:54:00:12:34:56
[fatfs] WARN: #1: 000000000100942a start()+0x2e
[kernel] WARN: Exception #13

[kernel] WARN: RIP = 000000000100942f CS = 000000000000002b RFL = 0000000000000206
[kernel] WARN: SS = 0000000000000023 RSP = 0000000003004048 RBP = 0000000003004120
[kernel] WARN: RAX = 000000000100942f RBX = 00000000fffffff5 RCX = 00000000010034e8
[kernel] WARN: RDX = 0000000000000000 RSI = 0000000000000000 RDI = 0000000000000000
[kernel] WARN: R8 = 0000000000000000 R9 = 0000000000000000 R10 = 0000000000000000
[kernel] WARN: R11 = 0000000000000246 R12 = 0000000000000000 R13 = 0000000000000000
[kernel] WARN: R14 = 000000000100be60 R15 = 0000000001004270 ERR = 0000000000000032
[init] WARN: fatfs: exception occurred, killing the task...
[kernel] destroying fatfs...
[display] WARN: unknown message (type=1)
[appmgr] WARN: unknown message type (type=1)
[ramdisk] unknown message 1
[init] WARN: unknown message type (type=1)
[tcpip] starting...
[tcpip] ready
[kernel] WARN: Exception #6

[kernel] WARN: RIP = 0000000001014730 CS = 000000000000002b RFL = 0000000000000246
[kernel] WARN: SS = 0000000000000023 RSP = 0000000003029310 RBP = 0000000003029350
[kernel] WARN: RAX = 00000000010146e0 RBX = 0000000000000000 RCX = 0000000003029370
[kernel] WARN: RDX = 0000000001017050 RSI = 0000000000000010 RDI = 0000000001023f10
[kernel] WARN: R8 = 00000000010173f0 R9 = 00000000010173f0 R10 = 0000000000000000
[kernel] WARN: R11 = 0000000000000246 R12 = 0000000001017490 R13 = 000000000100ede0
[kernel] WARN: R14 = 000000000000000f R15 = 0000000000000000 ERR = 0000000000000000
[init] WARN: tcpip: exception occurred, killing the task...
[kernel] destroying tcpip...
[display] WARN: unknown message (type=1)
[appmgr] WARN: unknown message type (type=1)
[init] WARN: unknown message type (type=1)

from resea.

Hmm... It looks weird to me. Do you modified other parts in the codebase? fatfs never fail to locate the file system as it embedded into the kernel image (in ramdisk server).

from resea.

Maybe it's because I have a problem with mformat in servers/ramdisk/build.mk.
If I build with your version I get

LD build/user/libs/std.o
CC libs/common/cstring.c
CC libs/common/vprintf.c
CC libs/common/ubsan.c
CC libs/common/arch/x64/memcpy.S
LD build/user/hello.debug.elf
SYMBOLS build/user/hello.debug.elf
STRIP build/user/hello.elf
CC servers/benchmark/main.c
LD build/user/benchmark.debug.elf
SYMBOLS build/user/benchmark.debug.elf
STRIP build/user/benchmark.elf
GEN build/ramdisk.img
4098+0 records in
4098+0 records out
4196352 bytes (4,2 MB, 4,0 MiB) copied, 0,0129553 s, 324 MB/s
mformat: Unknown geometry (You must tell the complete geometry of the disk,
either in /etc/mtools.conf or on the command line)
servers/ramdisk/build.mk:10: recipe for target 'build/ramdisk.img' failed
make: *** [build/ramdisk.img] Error 1

but if I added -f 1200 like this mformat -f 1200 -i [email protected]
it works. Can you tell me exactly what your system sends to mformat arguments ?

My mtools: Mtools version 4.0.18
apt: mtools is already the newest version (4.0.18-2ubuntu1).

from resea.

I compiled mtools 4.0.24 from ftp.gnu.org and I don't have the fatfs crash at boot.
I can compile without -f 1200.
But when I try to run hello fatfs crashes:

[kernel] enabled IRQ: task=e1000, vector=11
[kernel] enabled IRQ: task=ps2kbd, vector=1
[ps2kbd] ready
[appmgr] ready
[display] ready
[fatfs] Files ---------------------------------------------
[e1000] initialized the device
[e1000] MAC address = 52:54:00:12:34:56
[tcpip] starting...
[fatfs] /APPS
[tcpip] ready
[fatfs] /APPS/.
[fatfs] /APPS/..
[fatfs] /APPS/HELLO
[fatfs] /APPS/Ab
[fatfs] /APPS/BENCHM~1
[fatfs] ---------------------------------------------------
[fatfs] ready
[webapi] ready
[e1000] ready
[tcpip] registered new net device 'net1'
[e1000] sent 302 bytes
[e1000] received 590 bytes
[e1000] sent 306 bytes
[e1000] received 590 bytes
[tcpip] dhcp: leased ip=10.0.2.15, netmask=255.255.255.0, gateway=10.0.2.2
[shell] AT 202
[shell] AT 209
[kernel] WARN: Exception #6

[kernel] WARN: RIP = 0000000001009110 CS = 000000000000002b RFL = 0000000000000246
[kernel] WARN: SS = 0000000000000023 RSP = 0000000003004000 RBP = 0000000003004040
[kernel] WARN: RAX = 00000000010090c0 RBX = 0000000003004098 RCX = 0000000003004098
[kernel] WARN: RDX = 000000000100ba30 RSI = 0000000000000010 RDI = 00000000010110b0
[kernel] WARN: R8 = 000000000100bdd0 R9 = 00000000010113d0 R10 = 000000000100bdd0
[kernel] WARN: R11 = 00000000010113e0 R12 = 00000000030040a8 R13 = 0000000004ff5470
[kernel] WARN: R14 = 000000000000000f R15 = 0000000000000000 ERR = 0000000000000000
[init] WARN: fatfs: exception occurred, killing the task...
[kernel] destroying fatfs...
[display] WARN: unknown message (type=1)
[ramdisk] unknown message 1
[appmgr] WARN: unknown message type (type=1)
[init] WARN: unknown message type (type=1)

from resea.

Hmm, could you share your development environment (OS name and its version, etc.) and the changes to the source code? git diff master prints the diff.

from resea.

Closing this issue since the implementation has been updated. Feel free to reopen if this problem still reproduces.

from resea.