devb-eide Crash with Segmentation fault and SEGV_MAPERR

devb-eide driver is crashing very frequently. Almost once in a hour.

I think this may be happening because of my application software.

Can anyone suggest me, what problems can cause MAPERR and make devb-eide crash?

MAPERR? where do you see that.

Unless you are using the CAM interface, i doubt you can make devb-eide crash ( but everything is possible ). Maybe it’s a hardware problem?

What CPU architecture are you using?

Architecture: x86

I dont suspect any hardware problems as the driver ran successfully for months.

We changed the eide driver options to create te ramdisk using blk option. And tested apps for 2 months, no problems were found.

We then added couple of user applications and then started to notice the eide crash very frequently.

driver startup options:
devb-eide blk noatime,cache=10m,ramdisk=20m cam quiet eide nobios,nobmstr,slave=smart

Can user application crash eide driver? Is creating the ram disk from eide driver creating the problem?

Also, only eide driver is crashing and other user applications are not crashing.

The core file indicates the crash is in thread 5 or thread 6 or the thread 10, which listsen on channel 7, i suspect these are the threads which listen to client requests.

i see MAPERR fltno=11 in the core file

and signal = 11 or segmentation fault

Your best bet is probably to get in touch with QNX and send them a core file.

Guess what, I updated my runtime image to 6.3.2 and devb-eide is crashing on me. What is the address of the fault?

Yes, even i upgraded to 6.3.2 2 months back.

And below is the info from coreinfo of the core file.

e# coreinfo devb-eide.core
devb-eide.core:
processor=X86 num_cpus=1
cpu 1 cpu=586 name=Intel 586 F5M8S1 speed=266
flags=0xc00000bf FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX PSE
cyc/sec=266690900 tod_adj=1201192804976400000 nsec=3214910043494 inc=999847
boot=1201192805 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
MACHINE=“x86pc” HOSTNAME=“localhost”
pid=20484 parent=1 child=0 pgrp=20484 sid=1
flags=0x403210 umask=0 base_addr=0x8048000 init_stack=0x8047edc
ruid=0 euid=0 suid=0 rgid=0 egid=0 sgid=0
ign=0000000006800000 queue=ff00000000000000 pending=0000000000000000
fds=5 threads=9 timers=4 chans=30
thread 1
ip=0xb03304fa sp=0x8047dd4 stkbase=0x7fc7000 stksize=528384
state=SIGWAITINFO flags=80000000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
thread 2
ip=0xb032f70e sp=0x7fc6f30 stkbase=0x7fc4000 stksize=12288
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=21 realpri=21 policy=RR
blocked_chid=1
thread 3
ip=0xb032f70e sp=0x7fc3f30 stkbase=0x7fc1000 stksize=12288
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=21 realpri=21 policy=RR
blocked_chid=4
thread 4
ip=0xb032f64e sp=0x7fc0f80 stkbase=0x7fbc000 stksize=20480
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
blocked_chid=10
thread 6
ip=0xb032f64e sp=0x7f93ea0 stkbase=0x7f8f000 stksize=20480
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
blocked_chid=7
thread 7
ip=0xb032f64e sp=0x7f8eea0 stkbase=0x7f8a000 stksize=20480
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
blocked_chid=7
thread 8
ip=0xb032f64e sp=0x7fb6ea0 stkbase=0x7fb2000 stksize=20480
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
blocked_chid=7
thread 9
ip=0xb032f64e sp=0x7fa2ea0 stkbase=0x7f9e000 stksize=20480
state=RECEIVE flags=84020000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
blocked_chid=7
thread 10 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=0 fltno=11
ip=0xb8215a54 sp=0x7f98ab4 stkbase=0x7f94000 stksize=20480
state=STOPPED flags=84020000 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR

File a bug report on Foundry27…

We seems to be having the exact same problem. So most likely not a hardware issue…

community.qnx.com/sf/discussion/ … e.topc1922

We believe that we have located the problem. It appears to lie within the io-blk.so code.

When the blk ramdisk=xxx option is used, a path has been found where a ramdisk’s buffer can be cleaned when invalidated.
When using the ramdisk (not to be confused with devb-ram), the buffers should not be cleaned when invalidated. In the
case of this forum’s thread, this eventually leads to crashing the devb-eide driver.

Until fixed, the suggested workaround is to use devb-ram instead of using the blk ramdisk=xxx option with devb-eide or
the other devb-xxx drivers.

Peter Mitsis

Thanks for the update.