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. >> >> Interesting though that OpenBSD has the same issue. >> >> 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? > > 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 > 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>