Date: Sat, 18 May 1996 21:50:57 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: erich@uruk.org Cc: freebsd-bugs@freebsd.org Subject: Re: Post 2.1.0 FreeBSD bug in PCI code ?? Message-ID: <199605181950.AA18243@Sisyphos> In-Reply-To: erich@uruk.org "Re: Post 2.1.0 FreeBSD bug in PCI code ??" (May 16, 21:11)
next in thread | raw e-mail | index | archive | help
On May 16, 21:11, erich@uruk.org wrote:
} Subject: Re: Post 2.1.0 FreeBSD bug in PCI code ??
}
}
} [ Please e-mail responses directly to me, as I'm not on the list ]
}
} I decided to bite the bullet and simply debug the problem. As is typical
} of such situations, I found it in about 20 minutes, and had it fixed and
} tested in another 10.
}
} Please see that this fix is included in the main source tree.
Thanks a lot!
This was a typo, which I introduced a few months ago ... :(
The fix has been committed to -current (the bug did not exist
in -stable).
} > chip0 <Intel 82375EB PCI-EISA bridge> rev 5 on pci0:14:0
} > pci0:15:0: Intel Corporation, device 0x0008, class=0xff
} >
} > Fatal trap 12: page fault while in kernel mode
} > fault virtual address = 0x16d0d16c
} > fault code = supervisor read, page not present
} > instruction pointer = 0x8:0xf016d1aa
} > stack pointer = 0x10:0xefbfff0c
} > frame pointer = 0x10:0xefbfff1c
} > code segment = base 0x0, limit 0xfffff, type 0x1b
} > = DPL 0, pres 1, def32 1, gran 1
} > processor eflags = interrupt enabled, resume, IOPL = 0
} > current process = 0 ()
} > interrupt mask = net tty bio
} > panic: page fault
}
} The "class=0xff" was the key here. My diff is on the kernel source from
} the 2.2-960224-SNAP snapshot (I think that was it... it was from the end
} of february). When checking an array indexed by "class", the check was
} made against "subclass". Then it indexed by class and possibly goes
} off following a random pointer (well, not random, but not what you want,
} either).
Well, I didn't see the class=0xff message before, but
you are completely right with your diagnosis, of course!
} --------------------------(pci.c.diff)--------------------------
} --- pci.c.old Thu May 16 19:46:48 1996
} +++ pci.c Thu May 16 21:04:08 1996
} @@ -1700,7 +1700,7 @@
} printf(", class=0x%02x", class);
} }
}
} - if (subclass < sizeof(subclasses) / sizeof(subclasses[0])) {
} + if (class < sizeof(subclasses) / sizeof(subclasses[0])) {
} const subclass_name *p = subclasses[class];
} while (p->name && (p->subclass != subclass))
} p++;
} --------------------------(pci.c.diff)--------------------------
Thanks again!
Seems I really need a test system with lots of
different devices and a at least three levels
deep PCI bus structure (i.e. PCI to PCI bridges
on bridged PCI busses) for testing ...
But I had written some configuration space emulation
code a few months ago, when a PCI to PCI bridge
problem existed, and I'll try to produce a few test
cases and have them in my development kernel to do
some regression testing ... (i.e. I'll simulate all
devices that have caused problems at some time).
I choose to commit the one line (ahemm, three letter :)
patch and not the version you sent in a later mail,
since I think the additional protection against
internal inconsistencies is useful, and the additional
test costs only a few extra bytes (in the order of 10).
Regards, STefan
--
Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160
==============================================================================
http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605181950.AA18243>