Re: panic: resource_list_alloc: resource entry is busy
On Friday, September 12, 2014 10:03:26 PM Marcin Cieslak wrote: On Fri, 12 Sep 2014, John Baldwin wrote: Please note I originally loaded i915.ko, not i915kms.ko Oh, that is probably your problem. X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Would that be possible to fail with EBUSY or something instead of panic? Yes, though in this case you probably will end up with a black screen and an apparent hang due to how KMS works which wouldn't be a lot better. :( -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, Kevin Oberman wrote: On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak sa...@saper.info wrote: Please note I originally loaded i915.ko, not i915kms.ko Unfortunately, kldunload i915kms makes my screen blank and probably crashes the system (disk activity stops after a short while and there is no response to the keyboard input). //Marcin That explains most of it. You need i915kms. It is conflicting with i915 which already has the IRQ allocated. The black screen is expected. Once KMS starts talking to the graphics system, syscons can no longer talk to the display, so you get a black screen. To have a working display, you must enable vt(4). Add kern.vty=vt to /boot/loader.conf to enable vt(4) which will keep the display alive. Yes, I do have kern.vty=vt enabled in the loader and without i915kms loaded my system boots correctly. I can load i915kms later per hand or when starting X, but it does not work with bootloader. I think it's a known problem as of September 2nd as stated on the http://wiki.freebsd.org/Newcons page. (My machine is Sony VAIO SZ5MN). //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Wed, 10 Sep 2014, John Baldwin wrote: On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? Sure, here it goes: (kgdb) f 13 #13 0x80626092 in vga_pci_alloc_resource ( dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Friday, September 12, 2014 05:45:31 PM Marcin Cieslak wrote: On Wed, 10 Sep 2014, John Baldwin wrote: On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? Sure, here it goes: (kgdb) f 13 #13 0x80626092 in vga_pci_alloc_resource ( dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. Oh, some other child of vgapci has already allocated the IRQ. That seems odd. Can you get 'devinfo -r' output before you kldload i915kms and again after doing the kldload? (No need to run startx) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, John Baldwin wrote: at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. Oh, some other child of vgapci has already allocated the IRQ. That seems odd. Can you get 'devinfo -r' output before you kldload i915kms and again after doing the kldload? (No need to run startx) Please note I originally loaded i915.ko, not i915kms.ko Full output of the devinfo -r attached (no modules, w/i915 and w/i915kms), snippets: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd000-0xdfff 0xf830-0xf837 0xf840-0xf843 agp0 I/O memory addresses: 0x8000-0x8fff acpi_video0 vgapci1 I/O memory addresses: 0xf838-0xf83f With i915.ko loaded: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 Interrupt request lines: 16 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd000-0xdfff 0xf830-0xf837 0xf840-0xf843 agp0 I/O memory addresses: 0x8000-0x8fff acpi_video0 drm0 vgapci1 I/O memory addresses: 0xf838-0xf83f with i915kms.ko loaded: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 Interrupt request lines: 16 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd000-0xdfff 0xf830-0xf837 0xf840-0xf843 agp0 I/O memory addresses: 0x8000-0x8fff acpi_video0 drmn0 intel_iicbb0 iicbb0 iicbus0 iicsmb0 smbus0 smb0 iic0 intel_gmbus0 iicbus1 iicsmb1 smbus1 smb1 iic1 intel_iicbb1 iicbb1 iicbus2 iicsmb2 smbus2 smb2 iic2 intel_gmbus1 iicbus3 iicsmb3 smbus3 smb3 iic3 intel_iicbb2 iicbb2 iicbus4 iicsmb4 smbus4 smb4 iic4 intel_gmbus2 iicbus5 iicsmb5 smbus5 smb5 iic5 intel_iicbb3 iicbb3 iicbus6 iicsmb6 smbus6 smb6 iic6 intel_gmbus3 iicbus7 iicsmb7 smbus7 smb7 iic7 intel_iicbb4 iicbb4 iicbus8 iicsmb8 smbus8 smb8 iic8 intel_gmbus4 iicbus9 iicsmb9 smbus9 smb9 iic9 intel_iicbb5 iicbb5 iicbus10 iicsmb10 smbus10 smb10 iic10 intel_gmbus5 iicbus11 iicsmb11 smbus11 smb11 iic11 intel_iicbb6 iicbb6 iicbus12 iicsmb12 smbus12 smb12 iic12 intel_gmbus6 iicbus13 iicsmb13 smbus13 smb13 iic13 intel_iicbb7 iicbb7 iicbus14 iicsmb14 smbus14 smb14 iic14 intel_gmbus7 iicbus15 iicsmb15 smbus15 smb15 iic15 fbd0 vgapci1
Re: panic: resource_list_alloc: resource entry is busy
On Friday, September 12, 2014 08:57:55 PM Marcin Cieslak wrote: On Fri, 12 Sep 2014, John Baldwin wrote: at /usr/src/sys/dev/pci/vga_pci.c:318 318return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. Oh, some other child of vgapci has already allocated the IRQ. That seems odd. Can you get 'devinfo -r' output before you kldload i915kms and again after doing the kldload? (No need to run startx) Please note I originally loaded i915.ko, not i915kms.ko Oh, that is probably your problem. X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, John Baldwin wrote: Please note I originally loaded i915.ko, not i915kms.ko Oh, that is probably your problem. X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Would that be possible to fail with EBUSY or something instead of panic? //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak sa...@saper.info wrote: On Fri, 12 Sep 2014, John Baldwin wrote: at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. Oh, some other child of vgapci has already allocated the IRQ. That seems odd. Can you get 'devinfo -r' output before you kldload i915kms and again after doing the kldload? (No need to run startx) Please note I originally loaded i915.ko, not i915kms.ko Unfortunately, kldunload i915kms makes my screen blank and probably crashes the system (disk activity stops after a short while and there is no response to the keyboard input). //Marcin That explains most of it. You need i915kms. It is conflicting with i915 which already has the IRQ allocated. The black screen is expected. Once KMS starts talking to the graphics system, syscons can no longer talk to the display, so you get a black screen. To have a working display, you must enable vt(4). Add kern.vty=vt to /boot/loader.conf to enable vt(4) which will keep the display alive. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: resource_list_alloc: resource entry is busy
On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0x808c2947 in resource_list_alloc (rl=value optimized out, bus=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=value optimized out, child=value optimized out, type=value optimized out, rid=value optimized out, start=value optimized out, end=value optimized out, count=value optimized out, flags=value optimized out) at /usr/src/sys/dev/pci/pci.c:4604 #12 0x808c4420 in bus_alloc_resource (dev=0xf800026d8800, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0x80626092 in vga_pci_alloc_resource (dev=0xf800026d8800, child=value optimized out, type=1, rid=0xf80008c0b2d4, start=0, end=value optimized out, count=18446744071580876744, flags=value optimized out) at /usr/src/sys/dev/pci/vga_pci.c:318 Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
