Fwd: Shooting trouble on a PCI bus hang

Ansar Mohammed ansarm at gmail.com
Sun Jun 19 16:35:52 UTC 2011


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?

On Wed, Jun 15, 2011 at 12:22 PM, Patrick Powell <papowell at astart.com>wrote:

> On 06/14/11 20:52, Ansar Mohammed wrote:
>
>> Hello All,
>> I have a system that is intermitently hanging during the initial PCI bus
>> scan during boot. I have turned on verbose logging and I cannot break to
>> debugger as its a hang. Can someone guide me to the relevant code section
>> where PCI bus enumeration occurs so that I may modify the kernel source to
>> output even more debug info.
>>
>> My hang occurs at the end of this partial dmesg output.
>>
>> Thank you!
>>
>> pci0:<PCI bus>  on pcib0
>> pci0: domain=0, physical bus=0
>> found->  vendor=0x100b, dev=0x0028, revid=0x21
>>
>> domain=0, bus=0, slot=1, func=0
>> class=06-00-00, hdrtype=0x00, mfdev=1
>> cmdreg=0x0005, statreg=0x0220, cachelnsz=8 (dwords)
>> lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>> map[10]: type I/O Port, range 32, base 0xac1c, size  2, enabled
>>
>> found->  vendor=0x100b, dev=0x0030, revid=0x00
>>
>> domain=0, bus=0, slot=1, func=1
>> class=03-00-00, hdrtype=0x00, mfdev=0
>> cmdreg=0x0003, statreg=0x0220, cachelnsz=8 (dwords)
>> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>> map[10]: type Memory, range 32, base 0x41000000, size 24, enabled
>> map[14]: type Memory, range 32, base 0x40ffc000, size 14, enabled
>> map[18]: type Memory, range 32, base 0x40ff8000, size 14, enabled
>> map[1c]: type Memory, range 32, base 0x40ff4000, size 14, enabled
>>
>> found->  vendor=0x10ec, dev=0x8139, revid=0x10
>>
>> domain=0, bus=0, slot=14, func=0
>> class=02-00-00, hdrtype=0x00, mfdev=0
>> cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords)
>> lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns)
>> intpin=a, irq=11
>> powerspec 2  supports D0 D1 D2 D3  current D0
>> map[10]: type I/O Port, range 32, base 0xef00, size  8, enabled
>> map[14]: type Memory, range 32, base 0xeff00000, size  8, enabled
>>
>> $PIR: 0:14 INTA routed to irq 11
>> found->  vendor=0x1022, dev=0x2090, revid=0x03
>>
>> domain=0, bus=0, slot=15, func=0
>> class=06-01-00, hdrtype=0x00, mfdev=1
>> cmdreg=0x0009, statreg=0x02a0, cachelnsz=8 (dwords)
>> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>> map[10]: type I/O Port, range 32, base 0x6000, size 3, enabled map[14]:
>> type
>> I/O Port, range 32, base 0x6100, size 8, enabled map[18]: type I/O Port,
>> range 32, base 0x6200, size 6, enabled map[1c]: type I/O Port, range 32,
>> base 0, size 5, enabled map[20]: type I/O Port, range 32, base 0x9d00,
>> size
>> 7, enabled map[24]: type I/O Port, range 32, base 0x9c00, size 6, enabled
>> ______________________________**_________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers<http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**
>> freebsd.org <freebsd-hackers-unsubscribe at freebsd.org>"
>>
>>  Before you do anything else,  get another set of hardware and try the
> same thing on it.  I had a similar problem that turned out to be a bad SATA
> controller.   It was only by accident that we had two identical systems,
>  one good and one bad.
>
> --
> Patrick Powell                 Astart Technologies
> papowell at astart.com            1530 Jamacha Road, Suite X,
> Network and System             San Diego, CA 92019
>  Consulting                   858-874-6543
> Web Site: www.astart.com
>
> ______________________________**_________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers<http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**
> freebsd.org <freebsd-hackers-unsubscribe at freebsd.org>"
>


More information about the freebsd-hackers mailing list