RTLinux+Debian+VMWare

[email protected]
Newsgroups gmane.linux.real-time.rtlinux.general
Message-ID <OFDA8C677D.17449810-ONC3256F5D.002F8AF5-C3256F5D.00312302@computel.ru>
Please help!

I tried to use RTLinux in the following configuration:
1. VMWare Workstation 4.0.1 build 5289, host machine is Windows XP, Intel 
Celeron
2. Virtual machine is Debian GNU/Linux sarge, kernel 2.4.24(sources 
installed as debian package, not from kernel.org), rtlinux patch 
2.4.24 from ftp://ftp.rtlinux.at/pub/rtlinux/contrib/hofrat applied, no 
other patches
3. RTLinux 3.2 pre 3 from ftp://ftp.rtlinux.at/.../contrib

Configured, compiled linux kernel ok. (Config detailes: Celeron(not 
Coppermine), no SMP, no APIC, Buslogic SCSI, AMD PCNet network, kernel 
level DHCP, all other options - minimal features installed, no modules - 
all built in kernel)
Rebooted, accepted default rtlinux configuration
make xconfig, make dep, make, make install went ok with a few warnings(no 
errors)

BTW: rtsock compiled with errors - switched it off

There was a warning: make[1]: no rules to build target 'mutex_timed.o', 
stop
when both 'make' and 'make install'

Then trying to run 'make regression', got: rtl multiple loads test ok, 
then virtual 
machine hangs when trying multiple loads of rtl_time (on reboot fsck 
report file system errors). Host task manager shows 97% processor load 
that time. Looking at init_module() in rtl_time shown some calls to spin 
locks - maybe this is the cause?

Then I tried to load modules mainually in this sequence:
1. 'insmod mbuff' says module will taint the kernel (then i found that 
loading mbuff did not affect rtl.o)
2. 'insmod rtl' - loads ok
3. 'insmod rtl_time' hangs up virtual machine

Please tell me, what may be the cause of hang up when loading rtl_time and 

how can i fix it?
And how can i do some trace/debug in this situation?
_______________________________________________
Rtl mailing list
[email protected]
http://www2.fsmlabs.com/mailman/listinfo/rtl
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.