Re: 2.6.13: Crash in Yenta initialization

["Marcus Wegner" <wegner3000@hotmail.com>]

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

>  On Sat, Sep 03, Ivan Kokshaysky wrote:
>
>>On Sat, Sep 03, 2005 at 02:45:08AM +0200, Andreas Koch wrote:
>> > crucial part seem to be the different bridge initialization sections:
>>
>>Indeed.
>>
>> > 2.6.12-rc6 + Ivan's patches:
>>...
>> >           PCI: Bus 7, cardbus bridge: 0000:06:09.0
>> >             IO window: 00006000-00006fff
>> >             IO window: 00007000-00007fff
>> >             PREFETCH window: 82000000-83ffffff
>> >             MEM window: 8c000000-8dffffff
>> >           PCI: Bus 11, cardbus bridge: 0000:06:09.1
>> >             IO window: 00008000-00008fff
>> >             IO window: 00009000-00009fff
>> >             PREFETCH window: 84000000-85ffffff
>> >             MEM window: 8e000000-8fffffff
>> >           PCI: Bus 15, cardbus bridge: 0000:06:09.3
>>...
>> > ... Versus the much shorter output from 2.6.13
>>...
>> >           PCI: Bus 7, cardbus bridge: 0000:06:09.0
>> >             IO window: 00004000-000040ff
>> >             IO window: 00004400-000044ff
>> >             PREFETCH window: 82000000-83ffffff
>> >             MEM window: 88000000-89ffffff
>> >           PCI: Bridge: 0000:00:1e.0
>>
>>It's mysterious.
>>So 2.6.13 doesn't see cardbus bridge functions 06:09.1 and 06:09.3,
>>which means that these devices are not on the per-bus device list.
>>OTOH, they are still visible on the global device list, since yenta
>>driver found them. No surprise that it crashes with some uninitialized
>>pointer.
>
>Did you find the reason for this already?
>We have a similar report:
>https://bugzilla.novell.com/show_bug.cgi?id=113778
>...
>It dies in yenta_config_init because dev->subordinate is NULL.
>...
I had the same problem with an ACER 8101 WLMI. I reverted the initialization
partly and it works now, but I don't know if it really fixes the bug.
Something seems to wrong in the pci initcode.

But other hardware errors with the acer notebook still remain. The detection
of the ioapic results in a deadlock in the boot process (the
multiple-ioapic-fix or "noapic" solved this).

yenta related:
- pccard hardware is working now
- O2 Micro 4-1 cardreader is not working

Does someone have ideas, configs or patches for the cardreader? Do you need 
more info? Let me know.

Marcus


[-- Attachment #2: pci-assign-res-fix --]
[-- Type: application/octet-stream, Size: 785 bytes --]

Crash in Yenta initialization
see http://marc.theaimsgroup.com/?l=linux-kernel&m=112570441428703&w=2

This fixes the pci initialization (revert back to previous state).

Marcus Wegner <wegner3000@hotmail.com>


diff -urN linux-2.6.13-8/drivers/pci/probe.c linux-2.6.13-8-marcus/drivers/pci/probe.c
--- linux-2.6.13-8/drivers/pci/probe.c	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-8-marcus/drivers/pci/probe.c	2005-09-11 00:46:05.000000000 +0200
@@ -523,11 +523,8 @@
 			 * as cards with a PCI-to-PCI bridge can be
 			 * inserted later.
 			 */
-			for (i=0; i<CARDBUS_RESERVE_BUSNR; i++)
-				if (pci_find_bus(pci_domain_nr(bus),
-							max+i+1))
-					break;
-			max += i;
+			max += CARDBUS_RESERVE_BUSNR;
+
 			pci_fixup_parent_subordinate_busnr(child, max);
 		}
 		/*

[-- Attachment #3: multiple-ioapic-fix --]
[-- Type: application/octet-stream, Size: 1900 bytes --]

ACPI MADT contains info on 2 IO-APICs.
 io_apic_get_unique_id panics due to being unable to assign an id to the
 second one (the memory location reads as all ones). The chipset spec
 (specifically: ICH6-M) is only talking about one IO-APIC, so most likely the
 MADT is in error.

Marcus Wegner <wegner3000@hotmail.com>


diff -urN linux-2.6.13-8/arch/i386/kernel/io_apic.c linux-2.6.13-8-marcus/arch/i386/kernel/io_apic.c
--- linux-2.6.13-8/arch/i386/kernel/io_apic.c	2005-09-06 17:53:38.000000000 +0200
+++ linux-2.6.13-8-marcus/arch/i386/kernel/io_apic.c	2005-09-11 03:44:08.000000000 +0200
@@ -2493,7 +2493,10 @@
 
 		/* Sanity check */
 		if (reg_00.bits.ID != apic_id)
-			panic("IOAPIC[%d]: Unable change apic_id!\n", ioapic);
+		{
+			printk("IOAPIC[%d]: Unable change apic_id!\n", ioapic);
+			return(-1);
+		}
 	}
 
 	apic_printk(APIC_VERBOSE, KERN_INFO
diff -urN linux-2.6.13-8/arch/i386/kernel/mpparse.c linux-2.6.13-8-marcus/arch/i386/kernel/mpparse.c
--- linux-2.6.13-8/arch/i386/kernel/mpparse.c	2005-08-29 01:41:01.000000000 +0200
+++ linux-2.6.13-8-marcus/arch/i386/kernel/mpparse.c	2005-09-11 04:01:18.000000000 +0200
@@ -893,6 +893,7 @@
 	u32			gsi_base)
 {
 	int			idx = 0;
+	int			tmpid = 0;
 
 	if (nr_ioapics >= MAX_IO_APICS) {
 		printk(KERN_ERR "ERROR: Max # of I/O APICs (%d) exceeded "
@@ -912,8 +913,13 @@
 	mp_ioapics[idx].mpc_apicaddr = address;
 
 	set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address);
-	if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 < 15))
-		mp_ioapics[idx].mpc_apicid = io_apic_get_unique_id(idx, id);
+	if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 < 15)) {
+		if ((tmpid = io_apic_get_unique_id(idx, id)) == -1) {
+			nr_ioapics--;
+			return;
+		}
+		mp_ioapics[idx].mpc_apicid = tmpid;
+	}
 	else
 		mp_ioapics[idx].mpc_apicid = id;
 	mp_ioapics[idx].mpc_apicver = io_apic_get_version(idx);