SuSE AMD x86-64 bits installation issue

SuSE AMD x86-64 bits installation issue

[HurryLin-6hSdJfI2Hxp9nmWX13WWKA]

[-- Attachment #1.1: Type: text/plain, Size: 2232 bytes --]

Dear ACPI developers:

	I am VIA bios engineer. We have APCI problem for SuSe.  We need your kindly support. 

	Now we meet a installation issue in APIC mode when we install SuSe 9.0 beta 3 on VIA platform. In ACPI part of BIOS, each interrupt pin (i.e. INTA, INTB, INTC, INTD ) of the device will get a assigned IRQ when we will claim device's IRQ routing on _PRT device configuration object. If interrupt pins of the device is dynamically decided IRQ through device object, then the system will hang during installation after _CRS control method is executed by OS on the refered device object and the current IRQ is returned. If we directly assign IRQ number to each interrupt pin of the device, the installation is OK. We think some problems on ACPI parsing duing installation.

	We also find another problem about the behavior of different OS version. For SuSe 9.0 beta 3, the devices can operate in APIC mode (above IRQ 16) when we directly assign IRQ number to each interrupt pin of the device. The system will hang when interrupt pins of the device is dynamically decided IRQ through device object. For SuSe 9.0 beta 6 and final version, the device always only operate in PIC mode. Customers can't accept our chipset that the IRQ routing of the devices is limited operated in PIC mode. We hope the IRQ routing results of the PCI devices to go back SuSe 9.0 beta 3 for future SuSe OS version. Let our platform operate in APIC mode. We have at least chance to operate in APIC mode for VIA chipset when interrupt pins of the device is directly assigned to IRQ number. 

	The "SuSE AMD x86-64 bits installation issue.txt" is more detailed descriptions about above problems and our analysis The "log.txt" is the log file gotten from the beta3 which we think the real problem existed in ACPI kernel.  If you have any questions please let me know. Thanks !

 <<SuSE AMD x86-64 bits installation issue.txt>>  <<log.txt>> 
	
	
Best Regards,

林皓琳            Hurry Hao-Lin Lin
=========================================
Software BIOS Team, System Platform, R & D Division, VIA Technologies, Inc.
8F, 533, Chung-Cheng Rd., Hsin-Tien,
Taipei, Taiwan, R.O.C.
Tel : 886-2-22185452 EXT. 7619
Fax: 886-2-8667-1061



[-- Attachment #1.2: Type: text/html, Size: 4428 bytes --]

[-- Attachment #2: SuSE AMD x86-64 bits installation issue.txt --]
[-- Type: text/plain, Size: 4503 bytes --]


We roughly describe for IRQ routing below.
In ACPI 1.0b, there are two methods to assign IRQ number for PCI devices.
1.	We claim device object for each interrupt pin, PCI devices can refer these device objects to dynamically determine its IRQ number according to the methods of these device objects. In current bios, internal devices(such as IDE, LAN, USB, Audio) will be dynamically decided IRQ numbers according to different SB. 	

Example:

Device(ALKD)
{
	Name(_HID, EISAID("PNP0C0F"))                          // PCI interrupt link
	Name(_UID, 8)
            Method(_PRS, ResourceTemplate() {                 
                    Interrupt(ResourceConsumer,Level,ActiveLow,Shared) {21}  
            })
            Method(_DIS){}
            Method(_CRS,0){
                     Name(B77D, ResourceTemplate() {                 
                                  Interrupt(ResourceConsumer,Level,ActiveLow,Shared,,,IRD2) {0}
                     })
                     CreateWordField(B77D,IRD2._INT,IREI)
                     if(LGreater(SBFL, 0x1)){  // Check if SB is after 177 
                             If(LNotEqual(\_SB.PCI0.USB3.U3IR,0x00)){    //Check if USB's IRQ is 0 then return 0 else return USB's IRQ 
                                        Store(\_SB.PCI0.USB3.U3IR, IREI)     //USB3 IRQ
                             }
                             If(LNotEqual(\_SB.PCI0.USB4.U4IR,0x00)){
                                        Store(\_SB.PCI0.USB4.U4IR, IREI)        USB4 IRQ
                             }
                             If(LNotEqual(\_SB.PCI0.USB5.U5IR,0x00)){
                                        Store(\_SB.PCI0.USB5.U5IR, IREI)        USB5 IRQ
                             }
                             If(LNotEqual(\_SB.PCI0.USB6.U6IR,0x00)){
                                        Store(\_SB.PCI0.USB6.U6IR, IREI)        USB6 IRQ
                             }
                     	     Return(B77D)                                    
                     }
              } // End of _CRS
}
                
Device(PCI0){
          ...    
          Name(_PRT, Package(){   
	...
          	Package(){0x00[VT8235_USB_ID]ffff, 0, ALKD, 0},  // VT8235 USB	
          	Package(){0x00[VT8235_USB_ID]ffff, 1, ALKD, 0},  // VT8235 USB
          	Package(){0x00[VT8235_USB_ID]ffff, 2, ALKD, 0},  // VT8235 USB
          	Package(){0x00[VT8235_USB_ID]ffff, 3, ALKD, 0},  // VT8235 USB
          }
}
		
2.   We can also directly assign immediate value to PCI devices. In current bios, we fix the IRQ routing for PCI slots.

Example:

Device(PCI0){
          ...    
          Name(_PRT, Package(){   
	...
          	Package(){0x00[SLOT1_ID]ffff, 0, 0, 0x10}, 	// Slot 1, INTA
	Package(){0x00[SLOT1_ID]ffff, 1, 0, 0x11}, 	// Slot 1, INTB
	Package(){0x00[SLOT1_ID]ffff, 2, 0, 0x12}, 	// Slot 1, INTC
	Package(){0x00[SLOT1_ID]ffff, 3, 0, 0x13}, 	// Slot 1, INTD

          }
}

About internal devices, we summarize the installation results between the OS version and IRQ assignment.
 
		SuSe 8.2		SuSe 9.0 beta 3		SuSe 9.0 beta 6	   
Device objects	Can¡¦t install		Can¡¦t install		PIC mode	   
Immediate value	APIC mode		APIC mode		PIC mode	 

From the above table, we have some analysis shown as follows:

1.	For SuSe 9.0 beta 6, installation fail issue has been fixed with original bios that can¡¦t install on SuSe 8.2. We can install SuSe 9.0 beta 6 but the devices are only in PIC mode even we assign immediate values (above IRQ number 16). From our viewpoint, Customers can't accept our chipset that the IRQ routing of the devices is limited operated in PIC mode. We hope the IRQ routing results of the PCI devices to go back SuSe 9.0 beta 3. So we hope that SuSe developer can provide a method we can re-operate in APIC mode for internal devices. Thus we can continue to debug our ASL code. 

2.	In SuSe 9.0 beta 3 installation, we use original bios that internal devices will refer device object of interrupt pin to determine its IRQ number.  We debug the control methods of device objects refered by internal devices. We find that OS execute the internal devices¡¦ PCI IRQ routing of the ASL code the sequence is _STA,  _PRS,  _STA,  _CRS,  _SRS,  _STA,  _CRS, then the system will hang after ASL code return resource in _CRS control method. The attached file is log that records entire result before system hang. We hope the information can give you some idea to debug.

 

[-- Attachment #3: log.txt --]
[-- Type: text/plain, Size: 7716 bytes --]

ok
Bootdata ok (command line is BOOT_IMAGE=linux SuSE=,1207300200,81867234., initrd
=initrd ramdisk_size=65536 vga=0x31a splash=silent earlyprintk=serial,ttyS0,3840
0 console=ttyS0,38400)
booting x86_64 kernel... Linux version 2.4.21-69-default (root@x86_64.suse.de) (
gcc version 3.3.1 (SuSE Linux)) #1 SMP Wed Sep 10 00:13:16 UTC 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
kernel direct mapping tables upto 10100000000 @ 8000-b000
Scan SMP from 0000010000000000 for 1024 bytes.
Scan SMP from 000001000009fc00 for 1024 bytes.
Scan SMP from 00000100000f0000 for 65536 bytes.
found SMP MP-table at 00000000000f53a0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f0000 reserved twice.
hm, page 000f1000 reserved twice.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 VIAK8                      ) @ 0x00000000000f6e10
ACPI: RSDT (v001 VIAK8  AWRDACPI 16944.11825) @ 0x000000000fff3000
ACPI: FADT (v001 VIAK8  AWRDACPI 16944.11825) @ 0x000000000fff3040
ACPI: MADT (v001 VIAK8  AWRDACPI 16944.11825) @ 0x000000000fff9140
ACPI: DSDT (v001 VIAK8  AWRDACPI 00000.04096) @ 0x0000000000000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x3] trigger[0x3])
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ d0000000 size 128 MB
Building zonelist for node : 0
Kernel command line: BOOT_IMAGE=linux SuSE=,1207300200,81867234., initrd=initrd
ramdisk_size=65536 vga=0x31a splash=silent earlyprintk=serial,ttyS0,38400 consol
e=ttyS0,38400
bootsplash: silent mode.
Initializing CPU#0
time.c: Detected 1.193182 MHz PIT timer.
time.c: Detected 1595.493 MHz TSC timer.
Disabling early console
ok
Bootdata ok (command line is BOOT_IMAGE=linux SuSE=,1207300200,81867234., initrd
=initrd ramdisk_size=65536 vga=0x31a splash=silent earlyprintk=serial,ttyS0,3840
0 console=ttyS0,38400)
Linux version 2.4.21-69-default (root@x86_64.suse.de) (gcc version 3.3.1 (SuSE L
inux)) #1 SMP Wed Sep 10 00:13:16 UTC 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
kernel direct mapping tables upto 10100000000 @ 8000-b000
Scan SMP from 0000010000000000 for 1024 bytes.
Scan SMP from 000001000009fc00 for 1024 bytes.
Scan SMP from 00000100000f0000 for 65536 bytes.
found SMP MP-table at 00000000000f53a0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f0000 reserved twice.
hm, page 000f1000 reserved twice.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
ACPI: RSDP (v000 VIAK8                      ) @ 0x00000000000f6e10
ACPI: RSDT (v001 VIAK8  AWRDACPI 16944.11825) @ 0x000000000fff3000
ACPI: FADT (v001 VIAK8  AWRDACPI 16944.11825) @ 0x000000000fff3040
ACPI: MADT (v001 VIAK8  AWRDACPI 16944.11825) @ 0x000000000fff9140
ACPI: DSDT (v001 VIAK8  AWRDACPI 00000.04096) @ 0x0000000000000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x3] trigger[0x3])
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ d0000000 size 128 MB
Building zonelist for node : 0
Kernel command line: BOOT_IMAGE=linux SuSE=,1207300200,81867234., initrd=initrd
ramdisk_size=65536 vga=0x31a splash=silent earlyprintk=serial,ttyS0,38400 consol
e=ttyS0,38400
bootsplash: silent mode.
Initializing CPU#0
time.c: Detected 1.193182 MHz PIT timer.
time.c: Detected 1595.493 MHz TSC timer.
Disabling early console
Console: colour dummy device 80x25
Calibrating delay loop... 3185.04 BogoMIPS
Memory: 245092k/262080k available (1888k kernel code, 14428k reserved, 1210k dat
a, 172k init)
Dentry cache hash table entries: 32768 (order: 7, 524288 bytes)
Inode cache hash table entries: 16384 (order: 6, 262144 bytes)
Mount cache hash table entries: 256 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 5, 131072 bytes)
Page-cache hash table entries: 65536 (order: 7, 524288 bytes)
CPU: L1 I Cache: 64K (64 bytes/line/2 way), D cache 64K (64 bytes/line/2 way)
CPU: L2 Cache: 1024K (64 bytes/line/8 way)
Machine Check Reporting enabled for CPU#0
POSIX conformance testing by UNIFIX
mtrr: v2.02 (20020716))
CPU: L1 I Cache: 64K (64 bytes/line/2 way), D cache 64K (64 bytes/line/2 way)
CPU: L2 Cache: 1024K (64 bytes/line/8 way)
CPU0: AMD Athlon(tm) 64 Processor 2800+ stepping 00
per-CPU timeslice cutoff: 5121.25 usecs.
task migration cache decay timeout: 10 msecs.
Only one processor found.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
testing the IO APIC.......................

.................................... done.
Using local APIC timer interrupts.
Detected 12.464 MHz APIC timer.
cpu: 0, clocks: 1994366, slice: 997183
CPU0<T0:1994352,T1:997168,D:1,S:997183,C:1994366>
time.c: Using PIT/TSC based timekeeping.
migration_task 0 on cpu=0
ACPI: Subsystem revision 20030619
PCI: Using configuration type 1
Looking for DSDT in initrd ... not found!
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: System [ACPI] (supports S0 S1 S4 S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [ALKA] (IRQs 20)
ACPI: PCI Interrupt Link [ALKB] (IRQs 23)
ACPI: PCI Interrupt Link [ALKC] (IRQs 22)
ACPI: PCI Interrupt Link [ALKD] (IRQs 21)
PCI: Using configuration type 1
PCI: Probing PCI hardware
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 11
Li

Re: SuSE AMD x86-64 bits installation issue

[Len Brown]

Hurry,

I'm delighted to hear directly from VIA about these issues.

We've had difficulty in the past addressing VIA issues because detailed
information about VIA hardware is not publically published.  Having
access to a BIOS engineer who can actually change the BIOS to debug a
problem -- now _this_ is very exciting!

Agreed, customers will expect the IOAPIC to work -- the curret
workaround of running high performance systems in PIC mode is not
acceptable.

Re: the problem
I think what you're saying is that your _PRT uses PCI Link Devices in
APIC mode, and when you do the system hangs.  On the other hand, if the
_PRT returns static interrutps in APIC mode then the system works --
yes?

Not having a hardware diagram showing how this thing is wired up, I have
to ask why you don't simply use the static entries in APIC mode?

PCI Link Devices are actually quite rare in APIC mode.  They're more
often used in PIC mode to map all the PIRQs down onto the PIC pins.  So
Linux has not been heavily exercised in this configuration and we may
indeed have bugs there.

But on the other hand, programming a link device runs BIOS AML that
touches the hardware, and if that AML has bugs, or if the devices it
reads and writes to has bugs, then anything can happen.

Here's how you can help us work this issue.

1. send mail in plain text format if possible, or at least not html.
   I found your message in my Spam mailbox -- which is where
   all html messages go.  Others may have automatically delted it
   and not seen it at all.

2. I could not read the attachments to your message.
   Please file a bug and attach the supporting information to
   the bug report.

If the issue is specific to the SuSE kernel, then you want to file
it at http://bugzilla.suse.de  More likely this issue is not unique
to SuSE, and so you should file the bug against the baseline kernel(s).

How to file a bug against ACPI:

http://bugzilla.kernel.org/
Category: Power Management
Component: ACPI

Please attach the output from dmidecode, available in /usr/sbin/, or
here:
http://www.nongnu.org/dmidecode/

Please attach the output from acpidmp, available in /usr/sbin/, or in
here
http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar.gz

Please attach /proc/interrupts and the dmesg output showing the failure,
if possible.

Please attach the output of lspci -v

thanks,
-Len Brown
Linux 2.4, Linux 2.6 ACPI maintainer


On Tue, 2003-11-04 at 04:34, HurryLin-6hSdJfI2Hxp9nmWX13WWKA@public.gmane.org wrote:
> Dear ACPI developers:
> 
>         I am VIA bios engineer. We have APCI problem for SuSe.  We
> need your kindly support. 
> 
>         Now we meet a installation issue in APIC mode when we install
> SuSe 9.0 beta 3 on VIA platform. In ACPI part of BIOS, each interrupt
> pin (i.e. INTA, INTB, INTC, INTD ) of the device will get a assigned
> IRQ when we will claim device's IRQ routing on _PRT device
> configuration object. If interrupt pins of the device is dynamically
> decided IRQ through device object, then the system will hang during
> installation after _CRS control method is executed by OS on the
> refered device object and the current IRQ is returned. If we directly
> assign IRQ number to each interrupt pin of the device, the
> installation is OK. We think some problems on ACPI parsing duing
> installation.
> 
>         We also find another problem about the behavior of different
> OS version. For SuSe 9.0 beta 3, the devices can operate in APIC mode
> (above IRQ 16) when we directly assign IRQ number to each interrupt
> pin of the device. The system will hang when interrupt pins of the
> device is dynamically decided IRQ through device object. For SuSe 9.0
> beta 6 and final version, the device always only operate in PIC mode.
> Customers can't accept our chipset that the IRQ routing of the devices
> is limited operated in PIC mode. We hope the IRQ routing results of
> the PCI devices to go back SuSe 9.0 beta 3 for future SuSe OS version.
> Let our platform operate in APIC mode. We have at least chance to
> operate in APIC mode for VIA chipset when interrupt pins of the device
> is directly assigned to IRQ number. 
> 
>         The "SuSE AMD x86-64 bits installation issue.txt" is more
> detailed descriptions about above problems and our analysis The
> "log.txt" is the log file gotten from the beta3 which we think the
> real problem existed in ACPI kernel.  If you have any questions please
> let me know. Thanks !
> 
> <<SuSE AMD x86-64 bits installation issue.txt>>  <<log.txt>> 
>          
>         
> Best Regards,
> 
> 林皓琳            Hurry Hao-Lin Lin
> =========================================
> Software BIOS Team, System Platform, R & D Division, VIA Technologies,
> Inc.
> 8F, 533, Chung-Cheng Rd., Hsin-Tien,
> Taipei, Taiwan, R.O.C.
> Tel : 886-2-22185452 EXT. 7619
> Fax: 886-2-8667-1061
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: SuSE AMD x86-64 bits installation issue

[Andi Kleen]

[some comments, although I'm not Hurry]

On Fri, Nov 07, 2003 at 05:57:15AM -0500, Brown, Len wrote:
> If the issue is specific to the SuSE kernel, then you want to file
> it at http://bugzilla.suse.de  More likely this issue is not unique
> to SuSE, and so you should file the bug against the baseline kernel(s).

I believe it is generic (although I haven't retested with latest
2.6 with IO-APIC enabled, older 2.6 showed it)

> 
> How to file a bug against ACPI:
> 
> http://bugzilla.kernel.org/
> Category: Power Management
> Component: ACPI
> 
> Please attach the output from dmidecode, available in /usr/sbin/, or
> here:
> http://www.nongnu.org/dmidecode/

I don't think dmi blacklisting would do any good. The problem seems
to occur over a wide range of VIA chips with BIOS/motherboards from
multiple vendors. On the x86-64 kernel I actually ended up with checking 
for every bridge from VIA to disable the IO-APIC.

> 
> Please attach the output from acpidmp, available in /usr/sbin/, or in
> here
> http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar.gz
> 
> Please attach /proc/interrupts and the dmesg output showing the failure,
> if possible.

The symptom is when IO-APIC is enabled the system does not boot and 
hangs early in some device driver like IDE. With IO-APIC disabled you obviously
get a very different /proc/interrupts.

-Andi



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: Re: SuSE AMD x86-64 bits installation issue

[James Courtier-Dutton]

Andi Kleen wrote:

> 
> The symptom is when IO-APIC is enabled the system does not boot and 
> hangs early in some device driver like IDE. With IO-APIC disabled you obviously
> get a very different /proc/interrupts.
> 
> -Andi
> 
> 
I think I have a solution for the VIA IO-APIC failure. But I don't have 
a VIA motherboard to test it on, so if anyone would like to work with 
me, I think I could fix it.
My current theory is that it has to do with: -
Faulty Motherboards/Bios give: -
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...  failed.
...trying to set up timer as Virtual Wire IRQ... works.
testing the IO APIC.......................
.................................... done.

Good Motherboards/Bios give: -
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

What is happening, is that the 8254 timer is actually connected to the 
IO-APIC, but there is a VIA register that that switches on/off routing 
of the Timer IRQ to the IO-APIC. I suspect that some BIOS's switch it 
on, and some do not, so we would need to manually switch it on by 
writing to the VIA register before testing the timer.

Cheers
James



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: SuSE AMD x86-64 bits installation issue

[Len Brown]

On Fri, 2003-11-07 at 06:13, Andi Kleen wrote:

> The symptom is when IO-APIC is enabled the system does not boot and 
> hangs early in some device driver like IDE. With IO-APIC disabled you obviously
> get a very different /proc/interrupts.

Ok, then the bug report needs to include the console output captured via
serial console.

Also, it may be useful to see what windows does on the same hardware.
If the bug report can include the IRQ info from "winmsd"
run on Win2K or WinXP, that may be helpful.

thanks,
-Len




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: SuSE AMD x86-64 bits installation issue

[Andi Kleen]

On Fri, Nov 07, 2003 at 02:01:49PM -0500, Brown, Len wrote:
> On Fri, 2003-11-07 at 06:13, Andi Kleen wrote:
> 
> > The symptom is when IO-APIC is enabled the system does not boot and 
> > hangs early in some device driver like IDE. With IO-APIC disabled you obviously
> > get a very different /proc/interrupts.
> 
> Ok, then the bug report needs to include the console output captured via
> serial console.

That was all in the original report, which was perfect readable in mutt 
BTW.

-Andi


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

RE: SuSE AMD x86-64 bits installation issue

[HurryLin-6hSdJfI2Hxp9nmWX13WWKA]

Dear Len:
	I have filed a bug into http://bugzilla.kernel.org/. And I also attached files for your information. 
	If you have any questions please let me know. Thanks !
Hurry

-----Original Message-----
From: Len Brown [mailto:len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org]
Sent: Saturday, November 08, 2003 3:02 AM
To: Andi Kleen
Cc: Hurry Lin; ACPI Developers; Dream Ku; Stephen Chen; Pear Huang;
Norman Chung; Ken Cho
Subject: Re: SuSE AMD x86-64 bits installation issue


On Fri, 2003-11-07 at 06:13, Andi Kleen wrote:

> The symptom is when IO-APIC is enabled the system does not boot and 
> hangs early in some device driver like IDE. With IO-APIC disabled you obviously
> get a very different /proc/interrupts.

Ok, then the bug report needs to include the console output captured via
serial console.

Also, it may be useful to see what windows does on the same hardware.
If the bug report can include the IRQ info from "winmsd"
run on Win2K or WinXP, that may be helpful.

thanks,
-Len




-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/