| Submitter | Yinghai Lu |
|---|---|
| Date | 2009-10-11 21:00:22 |
| Message ID | <4AD24766.7050205@kernel.org> |
| Download | mbox | patch |
| Permalink | /patch/53027/ |
| State | Superseded |
| Headers | show |
Comments
> Brad reported that his SGI 750 (Itanium 1) will crash from 2.6.26, and > bisected 2.6.26 to 2.6.29 are fine -- the commit responsible was introduced in 2.6.30, so only those kernels >= 2.6.30 exhibit the problem. For searching purposes (so that Debian unstable etc can backport the fix to their 2.6.30 kernel), the error causing the panic at boot was: General Exception: IA-64 Reserved Register/Field fault (data access) 48 and occurred a few lines after "ACPI: PCI Root Bridge [PCI0] (0000:00)" -Brad
On Sun, Oct 11, 2009 at 05:32:45PM -0400, Brad Spengler wrote: > > Brad reported that his SGI 750 (Itanium 1) will crash from 2.6.26, and > > bisected > > 2.6.26 to 2.6.29 are fine -- the commit responsible was introduced in 2.6.30, > so only those kernels >= 2.6.30 exhibit the problem. For searching > purposes (so that Debian unstable etc can backport the fix to their > 2.6.30 kernel), the error causing the panic at boot was: > > General Exception: IA-64 Reserved Register/Field fault (data access) 48 > > and occurred a few lines after "ACPI: PCI Root Bridge [PCI0] (0000:00)" The SAL config code _used_ to use SAL 3.2 if the SAL revision were >3.1. Unfortunately, this broke a few HP machines where HP were reporting a SAL revision in the 60-80 range (a bug fixed in later firmware, but some people had prototype machines which couldn't be upgraded to newer firmware ...) So how about we go back to adding that check ... this does require that SGI's 750 machine reports its SAL revision correctly. Could you send the dmesg?
> So how about we go back to adding that check ... this does require that > SGI's 750 machine reports its SAL revision correctly. Could you send > the dmesg? The dmesg of the working kernel: http://grsecurity.net/~spender/dmesg.txt The output of lspci -vvxxxx: http://grsecurity.net/~spender/lspci1.txt The output of lspci -tvnn: http://grsecurity.net/~spender/lspci2.txt I don't have a serial console hooked up to the machine, and I'm not able to scroll up/down after the panic, so I only have the following picture from the crash. I modified the code that spews out registers on a panic so that the context of the panic could be seen. The stack trace didn't show anything useful, only repeats of an address similar to IP (for which no symbols exist). http://img132.yfrog.com/i/img1457u.jpg/ -Brad
Patch
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 8105e32..0c80a07 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -901,11 +901,24 @@ int pci_cfg_space_size(struct pci_dev *dev) { int pos; u32 status; + +#ifndef CONFIG_IA64 +/* + * not use it with IA64 at this point + * ia64 SAL 3.2 before doesn't support ext space, so + * pci_read_config_dword(dev, 0x100, &status) would cause GP + * the problem is not triggered, because system with SAL 3.2 before + * doesn't include PCI-X 2.0 or PCI Express, so pci_cfg_spce_size_ext() + * is not called with them. + * need to extend ia64 to detect sal version, and pci_root_ops + * to use raw_pci_ops and raw_pci_ext_ops like x86 + */ u16 class; class = dev->class >> 8; if (class == PCI_CLASS_BRIDGE_HOST) return pci_cfg_space_size_ext(dev); +#endif pos = pci_find_capability(dev, PCI_CAP_ID_EXP); if (!pos) {