Date: Mon, 20 Jun 2011 10:07:39 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Ansar Mohammed <ansarm@gmail.com> Subject: Re: Shooting trouble on a PCI bus hang Message-ID: <7B9E5AE3-C895-4D07-B923-A2F178B7B9BF@bsdimp.com> In-Reply-To: <201106200849.10862.jhb@freebsd.org> References: <BANLkTinGGTpwGdUFSW7jNHmpR8fyYoGd6Q@mail.gmail.com> <BANLkTimrYbXSaZtRtZ5%2BPst_S=X9nu8uHA@mail.gmail.com> <BANLkTinhOxLXzg=zH9TMHX13ppSfcX%2By4Q@mail.gmail.com> <201106200849.10862.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 20, 2011, at 6:49 AM, John Baldwin wrote: > On Sunday, June 19, 2011 12:35:49 pm Ansar Mohammed wrote: >> I appreciate that. The system works fine with NetBSD, LInux and = Windows XP, >> so I doubt its hardware. >>=20 >> Interesting though that OpenBSD has the same issue. >>=20 >> A question about the debug kernel load process: as it hangs on * >> pci_print_verbose* in pci.c, can I deduce that this is the exact code >> segment that is the issue? >=20 > Well, if that was the last device on the bus it might be in a device = driver > probe routine. You can try adding more printfs to device_probe(), = etc. to=20 > output each driver name as it probes each device perhaps. We've also had problems with interrupt storms after the drivers have all = probed, and people blame the last printf :) It sounds, however, with the OpenBSD datapoint that something is being = initialized bogusly, perhaps tripping over an erratum that the other = systems avoid or have specific code to work around. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7B9E5AE3-C895-4D07-B923-A2F178B7B9BF>