Bug 176869

Summary: kudzu received signal SIGILL, Illegal instruction at lrmi.c:733
Product: [Fedora] Fedora Reporter: Gianluca Cecchi <gianluca.cecchi>
Component: kudzuAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: 1.2.41-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-24 22:45:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of disas command while in gdb of kudzu sigkill none

Description Gianluca Cecchi 2006-01-03 21:44:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051216 Fedora/1.5-3 Firefox/1.5

Description of problem:
[root@fedora ~]# gdb kudzu
GNU gdb Red Hat Linux (6.3.0.0-1.94rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /sbin/kudzu
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x2c5000

Program exited normally.
(gdb) run
warning: cannot close "shared object read from target memory": File in wrong format
Starting program: /sbin/kudzu
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xd2a000

Program received signal SIGILL, Illegal instruction.
0x0805ee4f in run_vm86 () at lrmi.c:733
733             asm volatile (
(gdb) quit
The program is running.  Exit anyway? (y or n) y

kudzu-debuginfo-1.2.17-1
kudzu-devel-1.2.17-1
kudzu-1.2.17-1


Version-Release number of selected component (if applicable):
kudzu-1.2.17-1

How reproducible:
Sometimes

Steps to Reproduce:
1. start system
2. at kudzu start up the message appears
3. after system started, sometimes comes, sometimes not
  

Additional info:

Comment 1 Bill Nottingham 2006-01-06 21:54:08 UTC
What specific processor type do you have?

Comment 2 Gianluca Cecchi 2006-01-07 10:46:44 UTC
Actually I first installed FC5 devel test 1 in VMware WS 5.5, so that the system
at installation time was an Athlon MP with lsi logic scsi disk (both uni and smp
kernels were installed and I tried successfully both environments, but at 
installation VM was configured for 1 processor).
At http://www.vmware.com/pdf/ws_specs.pdf it seems that the virtualized
processor is the same as that on the host computer.
Then after doing some daily updates, I copied all / and /boot filesystems to a
pre-formatted partition (with /boot being a subdir, not a standalone fs now) on
the host system, tricking with grub and initrd files, so that I had a real fc5
devel on the host.
hw config of the host where the problem arises is: dual athlon MP 2200+ with 1Gb
of ram and serial ata disks (sata_sil kernel module).
Also symbios logic controller but without disks.
So at some point hw config for kudzu changed a lot and it seems it is not able
to manage this...
I have not available the fc5 system on the vmware environemnt at this moment...
But seeing at /var/log/messages.x files I get

at install time (vmware):
Dec  8 16:48:53 fedora syslogd 1.4.1: restart.
Dec  8 16:48:53 fedora kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec  8 16:48:53 fedora kernel: Linux version 2.6.14-1.1696_FC5
(bhcompile.redhat.com) (gcc version 4.0.2 20051109 (Red Hat
4.0.2-6)) #1 Sat Nov 19 19:02:13 EST 2005
...
Dec  8 16:48:53 fedora kernel: OEM ID: INTEL    Product ID: 440BX        APIC
at: 0xFEE00000
...
Dec  8 16:48:53 fedora kernel: Detected 1799.077 MHz processor.
...
Dec  8 16:48:54 fedora kernel: CPU: AMD Athlon(tm) MP 2200+ stepping 01
...
Dec  8 16:48:57 fedora kernel: mptbase: Initiating ioc0 bringup
Dec  8 16:48:57 fedora kernel: ioc0: 53C1030: Capabilities={Initiator}
Dec  8 16:48:57 fedora kernel: scsi0 : ioc0: LSI53C1030, FwRev=00000000h,
Ports=1, MaxQ=128, IRQ=11

After virtual --> physical copy, first boot with new (real hw) environment:
Dec 28 13:34:23 fedora syslogd 1.4.1: restart.
Dec 28 13:34:23 fedora kernel: klogd 1.4.1, log source = /proc/kmsg started.
Dec 28 13:34:23 fedora kernel: Linux version 2.6.14-1.1783_FC5smp
(bhcompile.redhat.com) (gcc version 4.1.0 20051220 (Red Hat
4.1.0-0.10)) #1 SMP Thu Dec 22 15:40:40 EST 2005
...
Dec 28 13:34:25 fedora kernel: CPU0: AMD Athlon(tm) MP 2200+ stepping 01
Dec 28 13:34:25 fedora kernel: Booting processor 1/1 eip 3000
Dec 28 13:34:25 fedora kernel: CPU 1 irqstacks, hard=c0429000 soft=c0409000
Dec 28 13:34:25 fedora kernel: Initializing CPU#1
Dec 28 13:34:25 fedora kernel: Calibrating delay using timer specific routine..
3600.61 BogoMIPS (lpj=7201225)
Dec 28 13:34:25 fedora kernel: CPU: CLK_CTL MSR was 6003d22f. Reprogramming to
2003d22f
Dec 28 13:34:25 fedora kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K
(64 bytes/line)
Dec 28 13:34:25 fedora kernel: CPU: L2 Cache: 256K (64 bytes/line)
Dec 28 13:34:25 fedora kernel: Intel machine check architecture supported.
Dec 28 13:34:25 fedora kernel: Intel machine check reporting enabled on CPU#1.
Dec 28 13:34:25 fedora kernel: CPU1: AMD Athlon(tm) MP stepping 01
Dec 28 13:34:25 fedora kernel: Total of 2 processors activated (7206.98 BogoMIPS).
...
Dec 28 13:34:30 fedora kernel: ata1: SATA max UDMA/100 cmd 0xF8864080 ctl
0xF886408A bmdma
0xF8864000 irq 169
Dec 28 13:34:30 fedora kernel: ata2: SATA max UDMA/100 cmd 0xF88640C0 ctl
0xF88640CA bmdma
0xF8864008 irq 169
Dec 28 13:34:30 fedora kernel: ata1: dev 0 ATA-7, max UDMA/133, 240121728
sectors: LBA
Dec 28 13:34:30 fedora kernel: ata1: dev 0 configured for UDMA/100
Dec 28 13:34:30 fedora kernel: scsi2 : sata_sil
Dec 28 13:34:30 fedora kernel: ata2: dev 0 ATA-7, max UDMA/133, 240121728
sectors: LBA
Dec 28 13:34:30 fedora kernel: ata2: dev 0 configured for UDMA/100
Dec 28 13:34:30 fedora kernel: scsi3 : sata_sil
Dec 28 13:34:30 fedora kernel:   Vendor: ATA       Model: Maxtor 6Y120M0    Rev:
YAR5

My lspci output is:
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System
Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 05)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 04)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03)
00:07.5 Multimedia audio controller: Advanced Micro Devices [AMD] AMD-768 [Opus]
Audio (rev 03)
00:09.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI
Adapter (rev 01)
00:09.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI
Adapter (rev 01)
00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 05)
01:05.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200]
(rev a1)
02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus] USB (rev 07)
02:04.0 Multimedia audio controller: Creative Labs SB Audigy LS
02:04.1 Input device controller: Creative Labs SB Audigy LS MIDI/Game port
02:05.0 RAID bus controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid]
Serial ATA Controller (rev 01)
02:06.0 Ethernet controller: Altima (nee Broadcom) AC9100 Gigabit Ethernet (rev 15)
02:08.0 USB Controller: NEC Corporation USB (rev 41)
02:08.1 USB Controller: NEC Corporation USB (rev 41)
02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02)



Comment 3 Bill Nottingham 2006-01-09 18:50:42 UTC
When it recieves the SIGILL, what does gdb print if you enter 'disas'?

I'll admit, I'm rather confused... in theory, if this is happening to you, it
should happen to everyone, and it's *not* currently happening to everyone.

Comment 4 Gianluca Cecchi 2006-01-09 20:02:13 UTC
I attach separately


Comment 5 Gianluca Cecchi 2006-01-09 20:03:36 UTC
Created attachment 122965 [details]
output of disas command while in gdb of kudzu sigkill

Comment 6 Bill Nottingham 2006-01-09 20:35:33 UTC
Whoops, can you get a backtrace as well?

Comment 7 Gianluca Cecchi 2006-01-09 22:28:44 UTC
I'm not an expert of debugging, sorry.
Could it be the below output sufficient?

[root@fedora RPMS]# gdb kudzu
GNU gdb Red Hat Linux (6.3.0.0-1.94rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /sbin/kudzu
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x2f2000

Program received signal SIGILL, Illegal instruction.
0x0805ee4f in run_vm86 () at lrmi.c:733
733             asm volatile (
(gdb) bt full
#0  0x0805ee4f in run_vm86 () at lrmi.c:733
        allsigs = {__val = {2147483647, 4294967294,
    4294967295 <repeats 30 times>}}
        cursigs = {__val = {0, 0, 22, 0, 0, 0, 1937336432, 1818321769,
    538976288, 859189536, 825176888, 859189046, 1735355402, 1818321769,
    538976288, 909189152, 791885875, 792016178, 668470, 0 <repeats 11 times>,
    1869770799, 1668493155}}
        oldgs = 51
#1  0x0805f300 in LRMI_int (i=16, r=0xbf885128) at lrmi.c:915
        seg = 49152
        off = 3350
#2  0x0805e02c in vbe_get_vbe_info () at vbe.c:103
        regs = {edi = 0, esi = 0, ebp = 0, reserved = 0, ebx = 0, edx = 0,
  ecx = 0, eax = 20224, flags = 0, es = 4353, ds = 0, fs = 0, gs = 0, ip = 0,
  cs = 0, sp = 0, ss = 0}
        mem = Variable "mem" is not available.


Comment 8 Bill Nottingham 2006-01-09 23:26:08 UTC
Ah, ok. So, that appears to be happening when it's executing the BIOS call to
get the vesa bios information.

It really seems to be more of a BIOS error than anything else, which I can't
really fix in kudzu. Did this happen on older releases?

Comment 9 Gianluca Cecchi 2006-01-09 23:45:51 UTC
On the same machine I have CentOS 4.2 installed that comes with
kudzu-1.1.95.15-1.i386.rpm
and it has no problems at startup.
If I connect and disconnect an usb printer over rebbots I see kudzu screen
asking me what I want to do...
I can run kudzu with gdb in CentOS if it can be of any help.
To be honest my machine seems to have indeed a kind of problem with BIOS.
It looses some bios settings during restart (date, boot sequence,
raid onboard settings, PNP OS settings).
I tried to change cmos battery but the situation didn't change.
It's annoying, but this is the only problem.
I can leave PC up'n'running compiling also for days without problems, but when I
switch it off and after some time reboot, I loose these bios settings.
I checked bios release for my MB (chaintek 7kdd) but it is already at final
release provided.
Thanks and let me know if I can provide further debugging.


Comment 10 Bill Nottingham 2006-08-24 22:45:22 UTC
Fixed in 1.2.41-1 by removing the offending code.