[Qemu-devel] fpu problems with qemu-system-sparc

[Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Hi!

I've some problems with qemu-system-sparc and programs using floating point 
instructions. Each time at least two floating point programs are started in 
qemu simultaneously, one or both are killed by the linux kernel with a SIGSEV 
signal (sometimes because of a corrupted stack or invalid register values). 
If I start only one program no error occurs. It looks like it has something 
to do with the disabled-floating-point-unit-trap, which is executed each time 
a process tries to access the fpu while another process has used it before. 
This interrupt calls the linux function do_fpd_trap which then saves the old 
FPU-state and restores the new one. When only one program uses the FPU this 
trap is never executed.

I've checked a lot of the executed instructions in qemu and cannot find any 
problems up to now. Does somebody else has an idea what to check? The test 
program simply adds two float variables (fadds-instruction) in a loop and 
this crashes the program reproducible.

regards,
Jörg

RE: [Qemu-devel] fpu problems with qemu-system-sparc

[Blue Swirl]

>I've checked a lot of the executed instructions in qemu and cannot find any
>problems up to now. Does somebody else has an idea what to check? The test
>program simply adds two float variables (fadds-instruction) in a loop and
>this crashes the program reproducible.

Some instructions trap when FPU is disabled, and they shouldn't, like stfsr?

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Am Donnerstag, 18. Mai 2006 19:53 schrieb Blue Swirl:
> >I've checked a lot of the executed instructions in qemu and cannot find
> > any problems up to now. Does somebody else has an idea what to check? The
> > test program simply adds two float variables (fadds-instruction) in a
> > loop and this crashes the program reproducible.
>
> Some instructions trap when FPU is disabled, and they shouldn't, like
> stfsr?

I don't think so. I analyzed the core-file after the crash. Sometimes the user 
stack was corrupt or a register value invalid and the crashing instruction 
was not a FPU instruction. Hence, I think one simulated instruction somehow 
overwrites parts of the userstack or maybe the kernel itself does it because 
of a wrong behavior of the simulated hardware. 

I'm not sure where to add more debugging output, because in qemu a segfault is 
hard to detect and in the kernel I have no idea, if all executed instructions 
are correctly translated... And unfortunately this crash is reproducible, but 
timing dependent. It does not always happen at exact the same position and 
therefore, I can't check, for example, for an invalid register value to see, 
when it is loaded...

regards,
Jörg

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Am Donnerstag, 18. Mai 2006 19:53 schrieb Blue Swirl:
> >I've checked a lot of the executed instructions in qemu and cannot find
> > any problems up to now. Does somebody else has an idea what to check? The
> > test program simply adds two float variables (fadds-instruction) in a
> > loop and this crashes the program reproducible.
>
> Some instructions trap when FPU is disabled, and they shouldn't, like
> stfsr?

I've checked and changed a lot of code inside the kernel and in qemu and added 
debbugging output. The crash is more or less reproducible and the program 
crashes after 2-3 FPU disabled traps somewhere inside the libc init routines. 
The FPU instructions cannot be the problem, because I disabled the trap in 
qemu and nothing crashed. Bit the trap is implemented like any other trap and 
all other traps seem to work. Since the crash is only reproducible in, lets 
say 95% of all tests, it looks like a timing problem. Unfortunately, I have 
no idea about qemu's timer simulation. What else can I check?

regards,
Jörg

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Blue Swirl]

>I've checked and changed a lot of code inside the kernel and in qemu and 
>added
>debbugging output. The crash is more or less reproducible and the program
>crashes after 2-3 FPU disabled traps somewhere inside the libc init 
>routines.
>The FPU instructions cannot be the problem, because I disabled the trap in
>qemu and nothing crashed. Bit the trap is implemented like any other trap 
>and
>all other traps seem to work. Since the crash is only reproducible in, lets
>say 95% of all tests, it looks like a timing problem. Unfortunately, I have
>no idea about qemu's timer simulation. What else can I check?

I'd still check the ld/stfsr implementation. The V8 spec says that stfsr 
_may_ zero the ftt field in fsr and what you describe sounds like the 
trapping happens too often. Just add env->fsr &= ~FSR_FTT_MASK into 
op_stfsr.

The timer frequency can be changed by modifying CNT_FREQ in slavio_timer.c 
if you want to try that.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Am Freitag, 19. Mai 2006 21:14 schrieb Blue Swirl:
Hi!

> I'd still check the ld/stfsr implementation. The V8 spec says that stfsr
> _may_ zero the ftt field in fsr and what you describe sounds like the
> trapping happens too often. Just add env->fsr &= ~FSR_FTT_MASK into
> op_stfsr.

I already log each fsr access. All bits, except the fcc bits, are always zero 
when linux or the program try to access the fsr.

> The timer frequency can be changed by modifying CNT_FREQ in slavio_timer.c
> if you want to try that.

Thanks, I'll try that later.

regards,
Jörg

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Am Freitag, 19. Mai 2006 21:14 schrieb Blue Swirl:
Hi!

I added some debug output to the do_interrupt function. Maybe I'm totally 
wrong, but env->pc is set some times to the same value again and again. And 
other debug output indicates, that sometimes a portion of code containing an 
FPU instruction is executed more than one time. Hence, it looks like the pc 
is always set to the pc of the tb, and not to the pc of the interrupted 
function. If the tb ands with the interrupted function this does not seem to 
be a problem, but in case of FPU interrupts it may be raised everywhere...

This re-execution of the same tb could explain my discovered behavior of the 
FPU programs. 

regards,
Jörg

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Am Montag, 22. Mai 2006 19:51 schrieb Joerg Platte:
> Am Freitag, 19. Mai 2006 21:14 schrieb Blue Swirl:
Hi!

> This re-execution of the same tb could explain my discovered behavior of
> the FPU programs.

A "save_state(dc);" call was missing before all invocations 
of "gen_op_trap_ifnofpu();" in translate.c. Therefore, the whole tb instead 
of the interrupted instruction has been re-executed after a trap. This seems 
to solve my FPU problems. I can provide a patch after I'm able to do a "cvs 
up"...

regards,
Jörg

PS: Booting a normal SPARC-Image with init, hotplug, ... seems to work now 
much better than before. There is no bash segfault any more:

ARCH: SUN4M
TYPE: SparcStation
Ethernet address: 52:54:0:12:34:56
Boot time fixup v1.6. 4/Mar/98 Jakub Jelinek (jj@ultra.linux.cz). Patching 
kernel for srmmu[Fujitsu Swift]/iommu
63MB HIGHMEM available.
Power off control detected.
Built 1 zonelists
Kernel command line: root=/dev/sda benchscript=crafty console=ttyS0 
video=tcxfb:off skipclock=1000 parallel=2
PID hash table entries: 1024 (order: 10, 16384 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 253572k/261904k available (1960k kernel code, 8072k reserved, 424k 
data, 144k init, 65296k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
SCSI subsystem initialized
IOMMU: impl 0 vers 4 table 0xfbe80000[262144 B] map [65536 b]
sbus0: Clock 25.0 MHz
dma0: Revision 2
dma1: Revision 2
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Console: switching to mono PROM 80x25
rtc_init: no PC rtc found
ioremap: done with statics, switching to malloc
zs2 at 0xfd014004 (irq = 44) is a SunZilog
zs3 at 0xfd014000 (irq = 44) is a SunZilog
Console: ttyS0 (SunZilog zs0)
ttyS0 at MMIO 0x0 (irq = 44) is a SunZilog
ttyS1 at MMIO 0x0 (irq = 44) is a SunZilog
io scheduler noop registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
sunlance.c:v2.02 8/24/03 Miguel de Icaza (miguel@nuclecu.unam.mx)
SunLance: using auto-carrier-detection.
SunLance: warning: overriding option 'tpe-link-test?'
SunLance: warning: mail any problems to ecd@skynet.be
eth0: LANCE 52:54:00:12:34:56
esp0: IRQ 36 SCSI ID 7 Clk 20MHz CCYC=50000 CCF=4 TOut 167 NCR53C90(esp100)
ESP: Total of 1 ESP hosts found, 1 actually in use.
scsi0 : Sparc ESP100 (NCR53C90)
  Vendor: QEMU      Model: QEMU HARDDISK     Rev:
  Type:   Direct-Access                      ANSI SCSI revision: 01
  Vendor: QEMU      Model: QEMU HARDDISK     Rev:
  Type:   Direct-Access                      ANSI SCSI revision: 01
  Vendor: QEMU      Model: QEMU CDROM        Rev:
  Type:   CD-ROM                             ANSI SCSI revision: 01
sda : sector size 0 reported, assuming 512.
SCSI device sda: 1 512-byte hdwr sectors (0 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
SCSI device sda: 300001 512-byte hdwr sectors (154 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
 sda: unknown partition table
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
sdb : sector size 0 reported, assuming 512.
SCSI device sdb: 1 512-byte hdwr sectors (0 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
SCSI device sdb: 512001 512-byte hdwr sectors (262 MB)
sdb: asking for cache data failed
sdb: assuming drive cache: write through
 sdb: unknown partition table
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 0x/0x caddy
Uniform CD-ROM driver Revision: 3.20
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0,  type 0
Attached scsi generic sg2 at scsi0, channel 0, id 2, lun 0,  type 5
rtc_sun_init: Registered Mostek RTC driver.
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
input: Sun Type 5 keyboard on zs/serio0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 144k freed
INIT: version 2.86 booting
Activating swap.
System time was Wed May 22 21:08:21 UTC 1974.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Wed May 22 21:08:25 UTC 1974.
Checking all file systems...
fsck 1.37 (21-Mar-2005)
WARNING: Your /etc/fstab does not contain the fsck passno
        field.  I will kludge around things for you, but you
        should fix your /etc/fstab file as soon as you can.

Setting kernel variables ...
... done.
Mounting local filesystems...
Cleaning /tmp /var/run /var/lock.
Starting hotplug subsystem:
   pci
cat: /sys/bus/pci/devices/*/class: No such file or directory
cat: /sys/bus/pci/devices/*/vendor: No such file or directory
cat: /sys/bus/pci/devices/*/device: No such file or directory
cat: /sys/bus/pci/devices/*/subsystem_vendor: No such file or directory
cat: /sys/bus/pci/devices/*/subsystem_device: No such file or directory
Bad PCI agent invocation
   pci      [success]
   usb
   usb      [success]
   isapnp
   isapnp   [success]
   ide
   ide      [success]
   input
/etc/hotplug/input.agent: arith: syntax error: "0x010"

   input    [success]
   scsi
modprobe: Can't open dependencies file /lib/modules/2.6.13-sam/modules.dep (No 
such file or directory)
     sd_mod: can't be loaded (for disk)
modprobe: Can't open dependencies file /lib/modules/2.6.13-sam/modules.dep (No 
such file or directory)
     sd_mod: can't be loaded (for disk)
modprobe: Can't open dependencies file /lib/modules/2.6.13-sam/modules.dep (No 
such file or directory)
     sr_mod: can't be loaded (for cdrom)
modprobe: Can't open dependencies file /lib/modules/2.6.13-sam/modules.dep (No 
such file or directory)
     sg: can't be loaded (for cdrom)
   scsi     [success]
done.

Setting the System Clock using the Hardware Clock as reference...
System Clock set. Local time: Wed May 22 21:09:37 UTC 1974

Initializing random number generator...done.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

Am Montag, 22. Mai 2006 21:12 schrieb Joerg Platte:
Hi!

> PS: Booting a normal SPARC-Image with init, hotplug, ... seems to work now
> much better than before. There is no bash segfault any more:

Shit, the bash still not works (I forgot the bash symlink pointing to a 
dash :-). But programs using the FPU are running much better now.

regards,
Jörg

Re: [Qemu-devel] fpu problems with qemu-system-sparc

[Joerg Platte]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

Am Donnerstag, 18. Mai 2006 18:16 schrieb Joerg Platte:
Hi!

Here is a patch fixing the problem by calling save_state before all possible 
fpu-interrupts.

regards,
Jörg

[-- Attachment #2: qemu-sparc-fpu-pc.patch --]
[-- Type: text/x-diff, Size: 1101 bytes --]

--- translate.c	2005-11-22 00:33:12.000000000 +0100
+++ translate.c.new	2006-05-22 20:40:07.000000000 +0200
@@ -982,6 +982,7 @@
 		{
 		    int cc = GET_FIELD_SP(insn, 20, 21);
 #if !defined(CONFIG_USER_ONLY)
+		    save_state(dc);
 		    gen_op_trap_ifnofpu();
 #endif
 		    target = GET_FIELD_SP(insn, 0, 18);
@@ -1002,6 +1003,7 @@
 	    case 0x6:		/* FBN+x */
 		{
 #if !defined(CONFIG_USER_ONLY)
+		    save_state(dc);
 		    gen_op_trap_ifnofpu();
 #endif
 		    target = GET_FIELD(insn, 10, 31);
@@ -1236,6 +1238,7 @@
 #endif
 	    } else if (xop == 0x34) {	/* FPU Operations */
 #if !defined(CONFIG_USER_ONLY)
+		save_state(dc);
 		gen_op_trap_ifnofpu();
 #endif
                 rs1 = GET_FIELD(insn, 13, 17);
@@ -1424,6 +1427,7 @@
 		int cond;
 #endif
 #if !defined(CONFIG_USER_ONLY)
+		save_state(dc);
 		gen_op_trap_ifnofpu();
 #endif
                 rs1 = GET_FIELD(insn, 13, 17);
@@ -2346,6 +2350,7 @@
 #endif
 	    } else if (xop >= 0x20 && xop < 0x24) {
 #if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64)
+		save_state(dc);
 		gen_op_trap_ifnofpu();
 #endif
 		switch (xop) {