When booting a "DPT PM3334UW FW Rev. 07M0, 2 channels, 64 CCBs" on 4.1-STABLE the bios asigns an irq and the kernel seems to think it is on a different one. Causing a kernel panic during boot. On my machine the bios asigns an IRQ of 9, but the kernel comes up with 16. In reading sys/dev/dpt/dpt.h I saw a comment about information read from the dpt being both Big endian, as well as in network byte order, This seems like a reasonable place to think the problem may be.... But not YET being a wizard, I don't know. Plus I don't know anything about newbus yet.. ;) Fix: possible endian-ness/byte order missmatch in dpt_read_conf? or in the way newbus handles the data... Again, don't know.... How-To-Repeat: Compile a newbusified dpt kernel (after aug 10) and try to boot up a DPT PM3334UW. (pci)
Responsible Changed From-To: freebsd-bugs->gibbs Over to the maintainer.
The following should fix the problem: Index: dpt_pci.c =================================================================== RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v retrieving revision 1.17.2.1 diff -u -r1.17.2.1 dpt_pci.c --- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1 +++ dpt_pci.c 2000/08/26 21:40:26 @@ -106,7 +106,7 @@ } rid = 0; - irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE); + irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); if (!irq) { device_printf(dev, "No irq?!\n"); error = ENOMEM; -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\ Jonathan Chen jon@spock.org /_/// <____) No electrons were harmed during production of this message (____> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
State Changed From-To: open->closed Jonathan's patch was committed as rev 1.21 and merged onto the stable branch as rev 1.17.2.2.
Responsible Changed From-To: gibbs->peter Peter applied the patch.
A commit references this bug: Author: brooks Date: Fri Mar 18 21:15:28 UTC 2016 New revision: 411371 URL: https://svnweb.freebsd.org/changeset/ports/411371 Log: Use more correct perl in ccc-analyzer. PR: 208052, 20706 Submitted by: Aleksander Alekseev <afiskon@devzen.ru> Changes: head/devel/llvm38/Makefile head/devel/llvm38/files/clang-patch-tools_clang_tools_scan-build_libexec_ccc-analyzer