Created attachment 23075 [details] boot log of problem Loading the intel-agp driver on our machine, which has an onboard intel 915G (2582) on AGP and an ATI Rage XL on PCI, causes the machine to panic. We originally saw on SLES11/OpenSuSE 11 variants, and have recreated back on a SLES10 vintage OS. If we don't load the intel-agp module everything works ok, though we can't use agp. On SLES11 the backtrace looks similar to bug 14117, in that we're around smp_apic_timer_interrupt when it panics, but on 2.6.31-rc9 we have a different backtrace (though similar results). Attached the full boot log. We've already talked to Intel/Zhenyu about this.
Mike, I think you set external gfx device as primary in BIOS right? How about setting that to intel IGD i915?
If we do that then intel-agp will work, but then it appears that the ATI card is not accessible.
I don't know if it makes a difference, but I saw this when looking at a 6.9 xorg log (I booted it to something ancient to see how it had changed): (WW) VESA(1): Bad V_BIOS checksum (II) VESA(1): Primary V_BIOS segment is: 0xc000 (II) VESA(1): VESA BIOS detected (II) VESA(1): VESA VBE Version 3.0 (II) VESA(1): VESA VBE Total Mem: 7872 kB (II) VESA(1): VESA VBE OEM: Intel(r)915G/915GV/910GL Graphics Chip Accelerated VGA BIOS (II) VESA(1): VESA VBE OEM Software Rev: 1.0 (II) VESA(1): VESA VBE OEM Vendor: Intel Corporation (II) VESA(1): VESA VBE OEM Product: Intel(r)915G/915GV/910GL Graphics Controller (II) VESA(1): VESA VBE OEM Product Rev: Hardware Version 0.0 That happens on both systems where I've recreated this problem. More current xorg seems less verbose here...
The only thing in the dmesg I see going wrong other than the panic is the presence of vesafb. It's a long shot, but that's all I see differing from my configuration to yours. (still working off of the assumption that hw platform is irrelevant because I was told you're reproducing this problem on 6 different hw platforms from 855 through G45).
I only have this one platform with 915 unfortunately, but that's what I've heard, too. I tried with CONFIG_FB off, I get a symptom where after loading intel-agp running a command like ls just results in Killed. In those cases I have to end up cycling the box, without any idea of what happened. I'll include the latest where I did get some output from dmesg (my serial console was re-allocated, but not sure that would show more). agpgart-intel 0000:00:00.0: Intel 915G Chipset agpgart-intel 0000:00:00.0: detected 7932K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xc0000000 BUG: unable to handle kernel paging request at df562000 IP: [<c03043cf>] journal_get_descriptor_buffer+0x52/0x7c *pde = 00010067 *pte = 1e05b001 Oops: 0003 [#1] SMP last sysfs file: /sys/devices/virtual/net/lo/type Modules linked in: intel_agp agpgart processor thermal_sys hwmon ipv6 e100 mii loop dm_mod rtc_cmos rtc_core rtc_lib pata_amd aacraid aic79xx aic7xxx scsi_transport_spi sd_mod crc_t10dif piix ide_core ahci libata scsi_mod [last unloaded: speedstep_lib] Pid: 87, comm: kjournald Not tainted (2.6.32-rc5-git6 #2) 4800782 EIP: 0060:[<c03043cf>] EFLAGS: 00010206 CPU: 0 EIP is at journal_get_descriptor_buffer+0x52/0x7c EAX: 00000000 EBX: de4b96ec ECX: 00000400 EDX: 00001000 ESI: de4e3514 EDI: df562000 EBP: dc617edc ESP: dc617ed0 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process kjournald (pid: 87, ti=dc616000 task=dc63b2b0 task.ti=dc616000) Stack: 004002a7 de4b9684 dc61b600 dc617f74 c0300bf4 dc617f40 dc63b2b0 c0440db4 <0> dd72aa00 948b573c 00000023 dc61b600 dd72aa14 dd72aac0 dd72aad8 c0612aa0 <0> c060e818 00000000 dd6bb800 00000000 00000000 c18b1024 00000fdc 00000001 Call Trace: [<c0300bf4>] ? journal_commit_transaction+0xbed/0x105d [<c0440db4>] ? schedule+0x93e/0x9ea [<c02399e1>] ? lock_timer_base+0x1f/0x3e [<c0239ead>] ? try_to_del_timer_sync+0x7d/0x85 [<c0303c2a>] ? kjournald+0x11f/0x2f8 [<c0242c67>] ? autoremove_wake_function+0x0/0x33 [<c0303b0b>] ? kjournald+0x0/0x2f8 [<c0242a04>] ? kthread+0x61/0x66 [<c02429a3>] ? kthread+0x0/0x66 [<c02034f7>] ? kernel_thread_helper+0x7/0x10 Code: e2 fb ff 85 c0 89 c3 74 45 f0 0f ba 28 02 19 c0 85 c0 74 07 89 d8 e8 b5 ee fb ff 8b 97 b0 00 00 00 31 c0 8b 7b 14 89 d1 c1 e9 02 <f3> ab f6 c2 02 74 02 66 ab f6 c2 01 74 01 aa f0 80 0b 01 89 d8 EIP: [<c03043cf>] journal_get_descriptor_buffer+0x52/0x7c SS:ESP 0068:dc617ed0 CR2: 00000000df562000 ---[ end trace b85e784ebe3932b0 ]--- Or, on a different try, ext errors after just listing directories: Linux agpgart interface v0.103 agpgart-intel 0000:00:00.0: Intel 915G Chipset agpgart-intel 0000:00:00.0: detected 7932K stolen memory agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xc0000000 EXT3-fs error (device sda4): ext3_lookup: deleted inode referenced: 1056656 EXT3-fs error (device sda4): ext3_lookup: deleted inode referenced: 1063098 EXT3-fs error (device sda4): ext3_lookup: deleted inode referenced: 1062951 EXT3-fs error (device sda4): ext3_lookup: deleted inode referenced: 1056995 EXT3-fs error (device sda4) in ext3_reserve_inode_write: IO failure The fs is clean after boot-up and I otherwise don't see this sort of thing. I get lots of variations on this. I don't know if that's helpful...
Closing as obsolete, if this is incorrect please update the bug