Re: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy)
On Monday, September 15, 2014 11:25:47 AM John Baldwin wrote: > On Saturday, September 13, 2014 10:57:53 AM d...@gmx.com wrote: > > John Baldwin wrote on 09/12/2014 23:06: > > > 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. > > > > Who is to blame? The user who tried to manually load an unsupported > > combination of modules, or the system, which should have handled things > > gracefully (whether by automatically unloading the first driver, or > > producing a soft-error upon loading the 2nd driver)? > > > > On a side-note, I also had a "resource_list_alloc: resource entry is busy" > > panic right after switching from the 10.0-supported Xorg to the "new" > > Xorg; > > I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran > > "startx", and got the panic. Surely this wasn't my fault! > > I can turn the panic into a resource allocation failure, but specifically > with KMS I am unsure if it will actually be better. FYI, I wrote a test for the patch I sent to make this not panic and verified it worked ok and committed it. -- 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 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: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy)
On Saturday, September 13, 2014 10:57:53 AM d...@gmx.com wrote:
> John Baldwin wrote on 09/12/2014 23:06:
> > 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.
>
> Who is to blame? The user who tried to manually load an unsupported
> combination of modules, or the system, which should have handled things
> gracefully (whether by automatically unloading the first driver, or
> producing a soft-error upon loading the 2nd driver)?
>
> On a side-note, I also had a "resource_list_alloc: resource entry is busy"
> panic right after switching from the 10.0-supported Xorg to the "new" Xorg;
> I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran
> "startx", and got the panic. Surely this wasn't my fault!
I can turn the panic into a resource allocation failure, but specifically with
KMS I am unsure if it will actually be better. It depends on when the driver
does this IRQ allocation. You may very well end up with a black screen and a
seemingly "hung" system (though it would not actually be hung).
I do think we should fix i915kms to fail fast if i915 is loaded, or more
likely I think we should probably look at removing the old i915 driver from
HEAD entirely so that 11 doesn't ship with it. It won't work with the Xorg we
are shipping with 11, so it's really dead code at this point.
The proposed diff would be:
Index: subr_bus.c
===
--- subr_bus.c (revision 271627)
+++ subr_bus.c (working copy)
@@ -3301,7 +3301,10 @@ resource_list_alloc(struct resource_list *rl, devi
rle->flags |= RLE_ALLOCATED;
return (rle->res);
}
- panic("resource_list_alloc: resource entry is busy");
+ device_printf(bus,
+ "resource entry %#x type %d for child %s is busy\n", *rid,
+ type, device_get_nameunit(child));
+ return (NULL);
}
if (isdefault) {
--
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 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: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy)
John Baldwin wrote on 09/12/2014 23:06: 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. Who is to blame? The user who tried to manually load an unsupported combination of modules, or the system, which should have handled things gracefully (whether by automatically unloading the first driver, or producing a soft-error upon loading the 2nd driver)? On a side-note, I also had a "resource_list_alloc: resource entry is busy" panic right after switching from the 10.0-supported Xorg to the "new" Xorg; I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran "startx", and got the panic. Surely this wasn't my fault! ___ 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 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 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 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: 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 vgapc
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=, > >> bus=, child=, type= >> optimized out>, > >> > >> rid=, start=, end= >> > >> optimized out>, count=, flags=) > >> > >> at /usr/src/sys/kern/subr_bus.c:3304 > >> > >> #11 0x8061ddae in pci_alloc_resource (dev=, > >> child=, type=, rid= >> optimized out>, > >> > >> start=, end=, count= >> > >> optimized out>, flags=) 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=, type=1, rid=0xf80008c0b2d4, start=0, > >> > >> end=, count=18446744071580876744, flags= >> > >> 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=, type=1, > rid=0xf80008c0b2d4, start=0, end=, > count=18446744071580876744, flags=) > 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 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=, bus=, child=, type=, rid=, start=, end=, count=, flags=) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=, child=, type=, rid=, start=, end=, count=, flags=) 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=, type=1, rid=0xf80008c0b2d4, start=0, end=, count=18446744071580876744, flags=) 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=, type=1, rid=0xf80008c0b2d4, start=0, end=, count=18446744071580876744, flags=) 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 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=, > bus=, child=, type= optimized out>, > rid=, start=, end= optimized out>, count=, flags=) > at /usr/src/sys/kern/subr_bus.c:3304 > #11 0x8061ddae in pci_alloc_resource (dev=, > child=, type=, rid= optimized out>, > start=, end=, count= optimized out>, flags=) 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=, type=1, rid=0xf80008c0b2d4, start=0, > end=, count=18446744071580876744, flags= 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"
panic: resource_list_alloc: resource entry is busy
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=, bus=, child=, type=out>, rid=, start=, end=optimized out>, count=, flags=) at /usr/src/sys/kern/subr_bus.c:3304 #11 0x8061ddae in pci_alloc_resource (dev=, child=, type=, rid=out>, start=, end=, count=optimized out>, flags=) 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=, type=1, rid=0xf80008c0b2d4, start=0, end=, count=18446744071580876744, flags=optimized out>) at /usr/src/sys/dev/pci/vga_pci.c:318 #14 0x808c4420 in bus_alloc_resource (dev=0xf800026d7300, type=1, rid=0x811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #15 0x81e94f73 in drm_attach (kdev=0xf800026d7300, idlist=optimized out>) at bus.h:416 #16 0x808c202f in device_attach (dev=0xf800026d7300) at device_if.h:180 #17 0x808c34c9 in bus_generic_driver_added (dev=, driver=) at /usr/src/sys/kern/subr_bus.c:2792 #18 0x808c022a in devclass_driver_added (dc=0xf80002504a80, driver=0x81e714c0) at bus_if.h:204 #19 0x808c018c in devclass_add_driver (dc=0xf80002504a80, driver=0x81e714c0, pass=, dcp=out>) at /usr/src/sys/kern/subr_bus.c:1136 #20 0x80873a12 in module_register_init (arg=0x81e714a8) at /usr/src/sys/kern/kern_module.c:123 #21 0x80866f24 in linker_load_module (kldname=, modname=0xf80002407400 "i915kms", parent=0x0, verinfo=0x0, lfpp=0xfe0096d05a80) at /usr/src/sys/kern/kern_linker.c:224 #22 0x80868a18 in kern_kldload (td=, file=optimized out>, fileid=0xfe0096d05ac4) at /usr/src/sys/kern/kern_linker.c:1029 #23 0x80868b5b in sys_kldload (td=0xf80008911490, uap=optimized out>) at /usr/src/sys/kern/kern_linker.c:1055 X -version: X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 11.0-CURRENT amd64 Current Operating System: FreeBSD radziecki.saper.info 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r271197M: Sat Sep 6 19:19:12 CEST 2014 r...@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO amd64 Build Date: 04 September 2014 01:06:53AM Devices: vgapci0@pci0:0:2:0: class=0x03 card=0x81e6104d chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x81e6104d chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller' class = display (this laptop also has a possbility to switch to NVidia card on boot, not tested yet with this kernel). Kernel: # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode # vt is the new video console driver device vt device vt_vga device vt_efifb device agp # support several AGP chipsets Loader: kern.vty=vt By the way, how do I get a nicer FB console during boot (not just after starting X)? I have difficulty getting back to the console text printed when it was "vga" (in 640x480x16 mode) - no more output shown on the hires console (I've had "tail -f somelog") running on the text console 0 when starting X from another window. //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
On Sun, Mar 25, 2001 at 05:58:53AM +0100, Cameron Grant wrote: > can you try http://people.freebsd.org/~cg/mssfix.diff.gz ? Fixed my panics too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: resource_list_alloc
>From: "Cameron Grant" <[EMAIL PROTECTED]> >Date: Sun, 25 Mar 2001 05:58:53 +0100 >can you try http://people.freebsd.org/~cg/mssfix.diff.gz ? Yup. Works -- thanks! (Same kernel config that I had been using: I didn't disable sound.) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: resource_list_alloc
> just upgraded my tree and did a reinstall ... trace is: > > resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at resource_list_alloc+0xd3 > isa_alloc_resource() @ +0xd0 > bus_alloc_resource() @ +0x5f > opti_detect @ +0x99 > mss_detect @ +0x52 > mss_probe @ +0x30a > device_probe_child @ +0xca > device_probe_and_attach @ +0x41 > isa_probe_children @ +0xde > configure @ +0x32 > mi_startup @ +0x6e > begin @ +0x29 can you try http://people.freebsd.org/~cg/mssfix.diff.gz ? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: panic: resource_list_alloc
On 25-Mar-01 The Hermit Hacker wrote:
>
> removing pcm fixes the panic, it appears ...
David O`Brien just confirmed it on his box as well.
> On Sat, 24 Mar 2001, John Baldwin wrote:
>
>>
>> On 25-Mar-01 The Hermit Hacker wrote:
>> >
>> > just upgraded my tree and did a reinstall ... trace is:
>> >
>> > resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at
>> > resource_list_alloc+0xd3
>> > isa_alloc_resource() @ +0xd0
>> > bus_alloc_resource() @ +0x5f
>> > opti_detect @ +0x99
>>
>> This is the second such one I've seen in opti_detect. I'm guessing that
>> 'mms'
>> is a sound driver? If so, can you try taking it out of your kernel to see
>> if
>> that is what is causing the panic?
>>
>> > mss_detect @ +0x52
>> > mss_probe @ +0x30a
>> > device_probe_child @ +0xca
>> > device_probe_and_attach @ +0x41
>> > isa_probe_children @ +0xde
>> > configure @ +0x32
>> > mi_startup @ +0x6e
>> > begin @ +0x29
>> >
>> > Marc G. Fournier ICQ#7615664 IRC Nick:
>> > Scrappy
>> > Systems Administrator @ hub.org
>> > primary: [EMAIL PROTECTED] secondary:
>> > scrappy@{freebsd|postgresql}.org
>> >
>> >
>> > To Unsubscribe: send mail to [EMAIL PROTECTED]
>> > with "unsubscribe freebsd-current" in the body of the message
>>
>> --
>>
>> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
>> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
>> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>>
>
> Marc G. Fournier ICQ#7615664 IRC Nick:
> Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary:
> scrappy@{freebsd|postgresql}.org
>
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: panic: resource_list_alloc
On 25-Mar-01 The Hermit Hacker wrote:
>
> doing so right now ... one quick/stupid question ... how does one
> 'reinstall' a new kernel so that you don't lose the /boot/kernel.old (aka
> backup that worked)? I've been moving files around before installing the
> rebuilt kernel, but that doesn't sound very efficient ... :)
>
> thanks ..
# cd /sys/compile/FOO
# < build like normal >
# make reinstall
Also, if you want to be super careful, keep a /boot/kernel.good lying around
that has a known working kernel in it.
> On Sat, 24 Mar 2001, John Baldwin wrote:
>
>>
>> On 25-Mar-01 The Hermit Hacker wrote:
>> >
>> > just upgraded my tree and did a reinstall ... trace is:
>> >
>> > resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at
>> > resource_list_alloc+0xd3
>> > isa_alloc_resource() @ +0xd0
>> > bus_alloc_resource() @ +0x5f
>> > opti_detect @ +0x99
>>
>> This is the second such one I've seen in opti_detect. I'm guessing that
>> 'mms'
>> is a sound driver? If so, can you try taking it out of your kernel to see
>> if
>> that is what is causing the panic?
>>
>> > mss_detect @ +0x52
>> > mss_probe @ +0x30a
>> > device_probe_child @ +0xca
>> > device_probe_and_attach @ +0x41
>> > isa_probe_children @ +0xde
>> > configure @ +0x32
>> > mi_startup @ +0x6e
>> > begin @ +0x29
>> >
>> > Marc G. Fournier ICQ#7615664 IRC Nick:
>> > Scrappy
>> > Systems Administrator @ hub.org
>> > primary: [EMAIL PROTECTED] secondary:
>> > scrappy@{freebsd|postgresql}.org
>> >
>> >
>> > To Unsubscribe: send mail to [EMAIL PROTECTED]
>> > with "unsubscribe freebsd-current" in the body of the message
>>
>> --
>>
>> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
>> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
>> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>>
>
> Marc G. Fournier ICQ#7615664 IRC Nick:
> Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary:
> scrappy@{freebsd|postgresql}.org
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: resource_list_alloc
Try "make reinstall". I have been doing quite a bit of this since my kernel panics before it ever gets all the way up. The last good kernel I have is about a month old. Actually, I moved /boot/kernel.old to another name in case I accidentally did an install instead of a reinstall. I don't want to leave my machine unable to boot. Jim Bloom [EMAIL PROTECTED] The Hermit Hacker wrote: > > doing so right now ... one quick/stupid question ... how does one > 'reinstall' a new kernel so that you don't lose the /boot/kernel.old (aka > backup that worked)? I've been moving files around before installing the > rebuilt kernel, but that doesn't sound very efficient ... :) > > thanks .. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: resource_list_alloc
On Sat, Mar 24, 2001 at 11:24:47PM -0400, The Hermit Hacker wrote: > > doing so right now ... one quick/stupid question ... how does one > 'reinstall' a new kernel so that you don't lose the /boot/kernel.old (aka make reinstall -or- make kernel-reinstall > removing pcm fixes the panic, it appears ... Yep! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: panic: resource_list_alloc
removing pcm fixes the panic, it appears ...
On Sat, 24 Mar 2001, John Baldwin wrote:
>
> On 25-Mar-01 The Hermit Hacker wrote:
> >
> > just upgraded my tree and did a reinstall ... trace is:
> >
> > resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at
> > resource_list_alloc+0xd3
> > isa_alloc_resource() @ +0xd0
> > bus_alloc_resource() @ +0x5f
> > opti_detect @ +0x99
>
> This is the second such one I've seen in opti_detect. I'm guessing that 'mms'
> is a sound driver? If so, can you try taking it out of your kernel to see if
> that is what is causing the panic?
>
> > mss_detect @ +0x52
> > mss_probe @ +0x30a
> > device_probe_child @ +0xca
> > device_probe_and_attach @ +0x41
> > isa_probe_children @ +0xde
> > configure @ +0x32
> > mi_startup @ +0x6e
> > begin @ +0x29
> >
> > Marc G. Fournier ICQ#7615664 IRC Nick:
> > Scrappy
> > Systems Administrator @ hub.org
> > primary: [EMAIL PROTECTED] secondary:
> > scrappy@{freebsd|postgresql}.org
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: panic: resource_list_alloc
doing so right now ... one quick/stupid question ... how does one
'reinstall' a new kernel so that you don't lose the /boot/kernel.old (aka
backup that worked)? I've been moving files around before installing the
rebuilt kernel, but that doesn't sound very efficient ... :)
thanks ..
On Sat, 24 Mar 2001, John Baldwin wrote:
>
> On 25-Mar-01 The Hermit Hacker wrote:
> >
> > just upgraded my tree and did a reinstall ... trace is:
> >
> > resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at
> > resource_list_alloc+0xd3
> > isa_alloc_resource() @ +0xd0
> > bus_alloc_resource() @ +0x5f
> > opti_detect @ +0x99
>
> This is the second such one I've seen in opti_detect. I'm guessing that 'mms'
> is a sound driver? If so, can you try taking it out of your kernel to see if
> that is what is causing the panic?
>
> > mss_detect @ +0x52
> > mss_probe @ +0x30a
> > device_probe_child @ +0xca
> > device_probe_and_attach @ +0x41
> > isa_probe_children @ +0xde
> > configure @ +0x32
> > mi_startup @ +0x6e
> > begin @ +0x29
> >
> > Marc G. Fournier ICQ#7615664 IRC Nick:
> > Scrappy
> > Systems Administrator @ hub.org
> > primary: [EMAIL PROTECTED] secondary:
> > scrappy@{freebsd|postgresql}.org
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: panic: resource_list_alloc
On 25-Mar-01 The Hermit Hacker wrote:
>
> just upgraded my tree and did a reinstall ... trace is:
>
> resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at
> resource_list_alloc+0xd3
> isa_alloc_resource() @ +0xd0
> bus_alloc_resource() @ +0x5f
> opti_detect @ +0x99
This is the second such one I've seen in opti_detect. I'm guessing that 'mms'
is a sound driver? If so, can you try taking it out of your kernel to see if
that is what is causing the panic?
> mss_detect @ +0x52
> mss_probe @ +0x30a
> device_probe_child @ +0xca
> device_probe_and_attach @ +0x41
> isa_probe_children @ +0xde
> configure @ +0x32
> mi_startup @ +0x6e
> begin @ +0x29
>
> Marc G. Fournier ICQ#7615664 IRC Nick:
> Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary:
> scrappy@{freebsd|postgresql}.org
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: resource_list_alloc
just upgraded my tree and did a reinstall ... trace is:
resource_list_alloc(c0d9eec0,c0d90180,c0d99b80,4,c0d4a30c) at resource_list_alloc+0xd3
isa_alloc_resource() @ +0xd0
bus_alloc_resource() @ +0x5f
opti_detect @ +0x99
mss_detect @ +0x52
mss_probe @ +0x30a
device_probe_child @ +0xca
device_probe_and_attach @ +0x41
isa_probe_children @ +0xde
configure @ +0x32
mi_startup @ +0x6e
begin @ +0x29
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel panic: resource_list_alloc: resource entry is busy
>Date: Sat, 24 Mar 2001 09:15:29 -0800 (PST) >From: David Wolfskill <[EMAIL PROTECTED]> >This from CVSup shortly before midnight (PST); I recall that I got >the update to sys/kern/kern_intr.c rev. 1.50 (to pin down the time a little >better). OK; I re-booted it under -STABLE, so I can report a bit more about the context. Yesterday, the thought occurred to me that it might be handy to record the start time for the CVSup (as well as the end time, so: CVSup ended at Wed Mar 21 23:53:49 PST 2001 CVSup ended at Thu Mar 22 23:51:54 PST 2001 CVSup started at Fri Mar 23 23:47:01 PST 2001 CVSup ended at Fri Mar 23 23:53:40 PST 2001 (and I had built & booted -CURRENT successfully yesterday; I append /var/log/messages from that boot after my .sig.) And the following shows the CVS activity from the working sources to the failing ones (I elided the "cvs update:" lines): Script started on Sat Mar 24 05:27:55 2001 dhcp-135[1] cd /C/usr/src dhcp-135[2] cvs update -d ? PATCHES U bin/getfacl/getfacl.1 U bin/setfacl/setfacl.1 U contrib/gcc.295/except.c U contrib/gcc.295/expr.c U contrib/gcc.295/expr.h U contrib/gcc.295/varasm.c U etc/Makefile U etc/primes U etc/mtree/BSD.x11-4.dist U games/fortune/datfiles/fortunes U gnu/usr.bin/tar/tar.c U include/arpa/inet.h U include/rpc/rpc.h U lib/libc/gen/Makefile.inc U lib/libc/gen/__xuname.c U lib/libc/gen/uname.c U lib/libc/net/inet.3 U lib/libc/net/inet_addr.c U lib/libc/net/inet_lnaof.c U lib/libc/net/inet_makeaddr.c U lib/libc/net/inet_neta.c U lib/libc/net/inet_netof.c U lib/libc/net/inet_network.c U lib/libc/rpc/key_call.c U lib/libc/rpc/rpc_soc.3 U lib/libc/rpc/rpc_soc.c U lib/libfetch/fetch.3 U lib/libfetch/ftp.c U lib/libposix1e/acl_add_perm.3 U lib/libposix1e/acl_clear_perms.3 U lib/libposix1e/acl_copy_entry.3 U lib/libposix1e/acl_create_entry.3 U lib/libposix1e/acl_delete_perm.3 U lib/libposix1e/acl_get_permset.3 U lib/libposix1e/acl_get_qualifier.3 U lib/libposix1e/acl_get_tag_type.3 U lib/libposix1e/acl_set_permset.3 U lib/libposix1e/acl_set_qualifier.3 U lib/libposix1e/acl_set_tag_type.3 U libexec/ypxfr/ypxfr_extern.h U release/Makefile U release/texts/HARDWARE.TXT U secure/lib/libtelnet/Makefile U share/man/man9/module.9 U sys/compat/linux/linux_misc.c RCS file: /cvs/freebsd/src/sys/dev/an/if_aironet_ieee.h,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into if_aironet_ieee.h M sys/dev/an/if_aironet_ieee.h RCS file: /cvs/freebsd/src/sys/dev/an/if_an.c,v retrieving revision 1.15 retrieving revision 1.16 Merging differences between 1.15 and 1.16 into if_an.c M sys/dev/an/if_an.c RCS file: /cvs/freebsd/src/sys/dev/an/if_anreg.h,v retrieving revision 1.5 retrieving revision 1.6 Merging differences between 1.5 and 1.6 into if_anreg.h M sys/dev/an/if_anreg.h U sys/dev/ata/atapi-all.c U sys/dev/ata/atapi-all.h U sys/dev/ata/atapi-cd.c U sys/dev/cnw/if_cnw.c U sys/dev/sound/isa/mss.c U sys/dev/sound/isa/mss.h U sys/dev/sound/pcm/ac97.c ? sys/i386/conf/LAPTOP_30W U sys/ia64/ia64/interrupt.c U sys/ia64/ia64/mp_machdep.c U sys/ia64/include/clock.h U sys/ia64/include/param.h U sys/kern/kern_intr.c U sys/kern/kern_lockf.c U sys/kern/kern_prot.c U sys/kern/kern_xxx.c U sys/kern/vnode_if.pl U sys/net/if_spppsubr.c U sys/netinet/in.h U sys/pc98/i386/machdep.c U sys/pc98/pc98/npx.c U sys/sys/types.h U sys/sys/utsname.h U sys/ufs/ffs/ffs_alloc.c U usr.bin/fetch/fetch.1 U usr.bin/fetch/fetch.c U usr.sbin/mptable/Makefile U usr.sbin/pkg_install/info/info.h U usr.sbin/pkg_install/info/main.c U usr.sbin/pkg_install/info/perform.c U usr.sbin/pkg_install/info/pkg_info.1 U usr.sbin/pkg_install/info/show.c U usr.sbin/pkg_install/lib/deps.c U usr.sbin/pkg_install/lib/exec.c U usr.sbin/pkg_install/lib/lib.h U usr.sbin/pkg_install/lib/match.c U usr.sbin/pkg_install/lib/msg.c U usr.sbin/pkg_install/lib/pen.c U usr.sbin/pkg_install/lib/str.c U usr.sbin/ppp/Makefile U usr.sbin/ppp/defs.h U usr.sbin/ppp/main.c U usr.sbin/ppp/systems.c U usr.sbin/sysinstall/config.c U usr.sbin/sysinstall/index.c U usr.sbin/sysinstall/install.c U usr.sbin/sysinstall/installUpgrade.c U usr.sbin/sysinstall/label.c U usr.sbin/sysinstall/menus.c U usr.sbin/sysinstall/sysinstall.8 U usr.sbin/sysinstall/wizard.c U usr.sbin/sysinstall/help/html.hlp U usr.sbin/sysinstall/help/options.hlp U usr.sbin/sysinstall/help/shortcuts.hlp dhcp-135[3] ^Dexit I had a PCcard in it, as usual -- a Cisco/Aironet 340 (an driver; the "messiness" around sys/dev/an up there is because I had been testing (for some time) the code that Archie committed). Here's a uni-diff of GENERIC vs. my kernel config. (I cheated a little: in my real config, I commented stuff (like SCSI-related things) out; for this exercise, I deleted the lines, then made the diff, so the result would be shorter & clearer.) --- GENERIC Fri Mar 16 12:22:15 2001 +++ LAPTOP_30W Sat Mar 24 10:54:09 2001 @@ -15,21 +15,29 @@ # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpo
Kernel panic: resource_list_alloc: resource entry is busy
I see the same here with a GENERIC kernel. Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel panic: resource_list_alloc: resource entry is busy
This from CVSup shortly before midnight (PST); I recall that I got the update to sys/kern/kern_intr.c rev. 1.50 (to pin down the time a little better). I was able to re-boot with the kernel from /boot/kernel.old OK; once I did that, I re-built the kernel after adding "options DDB", and I then re-created the panic. An outline of the traceback (sorry; I don't have a serial console on the laptop... yet) is: Debugger(c0337e03) at Debugger+0x44 panic(c0338d20,c167810c,4,0,c047f6c4) at panic+0x70 resource_list_alloc(c1683a00,c1679d00,c168eb80,4,c167810c) at resource_list_alloc+0xc8 isa_alloc_resource(c1679d00,c168eb80,4,c167810c,f8c) at isa_alloc_resource+0xcd bus_alloc_resource(c168eb80,4,c167810c,f8c,f95) at bus_alloc_resource+0x5d opti_detect(c168eb80,c1678100) at opti_detect+0xaa [abbreviating beyond this point for now; my hands are getting tired -- dhw] mss_detect( mss_probe( device_probe_child( device_probe_and_attach( isa_probe_children( configure( mi_startup() at mi_startup+0x68 begin() at begin+0x29 The addition of DDB is the first change I've needed to make since getting -CURRENT running on the machine a couple of weeks ago, and I've been CVSuping daily and rebuilding both -STABLE and -CURRENT daily. I don't happen to have a copy of the kernel config on a different machine, so I'll need to boot it normally to supply that; sorry. But given the above, unless something changed that would require a change to the kernel config within the last day or so, I'd have thought it would have been expected to not panic :-} There are some other things I'd like to do with the machine (build today's -STABLE, for example), but I can leave it "broken" for debugging for a while easily enough. The panic appears to come faily early in the boot process (resource allocation, I'd guess :-}), and it appears eminently reproducable, so I'm willing to play with it, fetch more code, or whatever. It's a 750/600 MHx P3 w/ 256 MB RAM, so I should be able to try changes reasonably quickly. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[andreas@klemm.gtn.com: -current install on Laptop, panic: resource_list_alloc: resource entry is busy]
Send one copy to -current, just for the case, that Soren is currently not available and somebody other could help. -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 5.2.0 and songs from our band -> http://www.freebsd.org/~andreas Hi Søren, I have a problem to install a self created FreeBSD 4.0-SNAP-2311 on my LAPTOP: The last things I see on screen pcib0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x3f4-0x3f7,0x374-0x377,0x1f4-0x1f7,0x174-0x177 at device 1.1 on pci0 atapci0: Busmastering DMA not supported panic: resource_list_alloc: resource entry is busy Uptime: 0s Automatic reboot in 15 seconds . Is that info o.k. for you or do you need something from boot_verbose ? Currently I have FreeBSD 3.4 installed onto it, since 4.x didn't run. So I would have the possibility to build 4.0 and boot test kernels onto it... This boot was from the boot floppy of the SNAP. Would you have time and interest to make it run ? Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD Get new songs from our band: http://www.freebsd.org/~andreas/64bits/index.html
Re: RC3 install floppies: panic: resource_list_alloc: resource entry is busy
secondarybus=0
intpin=a, irq=10
map[10]: type 1, range 32, base fc80, size 7
map[14]: type 1, range 32, base ffbffc00, size 7
pci0: on pcib0
CPU: Pentium, 66MHz, CPU->Memory posting ON, read around write
Warning: Cache parity disabled!
Warning: DRAM parity mask!
Cache: 256KB writeback, cache clocks=3-2-2-2/4-2-2-2
Cache flags: cache-all byte-control
DRAM: page mode memory clocks=X-4-4-4 (70ns)
CPU->PCI: posting ON, burst mode ON, PCI clocks=2-1-1-1
PCI->Memory: posting ON
Refresh: RAS#Only BurstOf4
atapci0: port
0x3f4-0x3f7,0x1f0-0x1f7 at device 1.0 on pci0
atapci0: Busmastering DMA not supported
panic: resource_list_alloc: resource entry is busy
Debugger("panic")
Stopped at Debugger+0x35: movb$0,in_Debugger.372
db>
SMAP type=01 base= len= 0009fc00
SMAP type=01 base= 0010 len= 03f0
SMAP type=02 base= fffc len= 0004
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #0: Fri Mar 10 22:57:58 CET 2000
[EMAIL PROTECTED]:/home/src/sys/compile/CUSTOM
Calibrating clock(s) ... TSC clock: 66643293 Hz, i8254 clock: 1193159 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 66643293 Hz
CPU: Pentium/P5 (66.64-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x517 Stepping = 7
Features=0x1bf
real memory = 67108864 (65536K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x002cf000 - 0x03ff7fff, 64131072 bytes (15657 pages)
avail memory = 62275584 (60816K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00f0120
bios32: Entry = 0xf145c (c00f145c) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0x1440
pnpbios: Found PnP BIOS data at 0xc00f0130
pnpbios: Entry = f:1245 Rev = 1.0
Other BIOS signatures found:
ACPI:
Intel Pentium detected, installing workaround for F00F bug
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a): mode1res=0x (0x8000)
pci_open(1b): mode1res=0x (0xff01)
pci_open(2):mode 2 enable port (0x0cf8) is 0x00
pci_open(2a): mode2res=0x0e (0x0e)
pci_open(2a): now trying mechanism 2
pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086)
npx0: on motherboard
npx0: INT 16 interface
i586_bzero() bandwidth = 75058170 bytes/sec
bzero() bandwidth = 37572797 bytes/sec
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a): mode1res=0x (0x8000)
pci_open(1b): mode1res=0x (0xff01)
pci_open(2):mode 2 enable port (0x0cf8) is 0x00
pci_open(2a): mode2res=0x0e (0x0e)
pci_open(2a): now trying mechanism 2
pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=04a38086)
pcib0: on motherboard
found-> vendor=0x8086, dev=0x04a3, revid=0x03
class=06-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
found-> vendor=0x1042, dev=0x1000, revid=0x01
class=01-01-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[10]: type 1, range 32, base 01f0, size 3
map[14]: type 1, range 32, base 03f4, size 2
found-> vendor=0x8086, dev=0x0484, revid=0x03
class=00-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
found-> vendor=0x102b, dev=0x051b, revid=0x00
class=03-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=11
map[10]: type 1, range 32, base a000, size 24
map[14]: type 1, range 32, base a100, size 14
map[18]: type 1, range 32, base a180, size 23
found-> vendor=0x10b7, dev=0x9200, revid=0x74
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=10
map[10]: type 1, range 32, base fc80, size 7
map[14]: type 1, range 32, base ffbffc00, size 7
pci0: on pcib0
CPU: Pentium, 66MHz, CPU->Memory posting ON, read around write
Warning: Cache parity disabled!
Warning: DRAM parity mask!
Cache: 256KB writeback, cache clocks=3-2-2-2/4-2-2-2
Cache flags: cache-all byte-control
DRAM: page mode memory clocks=X-4-4-4 (70ns)
CPU->PCI: posting ON, burst mode ON, PCI clocks=2-1-1-1
PCI->Memory: posting ON
Refresh: RAS#Only BurstOf4
ata-pci0: port 0x3f4-0x3f7,0x1f0-0x1f7 at
device 1.0 on pci0
ata-pci0: Busmastering DMA not supported
ata0: iobase=0x01f0 altiobase=0x03f4 bmaddr=0x
ata0: mask=03 status0=50 status1=50
ata0: mask=03 status0=50 status1=50
ata0: devices = 0x3
ata0 at 0x01f0 irq 14 on ata-pci0
isab0: at d
Re: RC3 install floppies: panic: resource_list_alloc: resource entry is busy
It seems Hans Ottevanger wrote: > Hi folks, > > I just tried to boot the RC3 install floppies on my Pentium 66 testbox. > It gets through the config stage without trouble, but then panics > immediately with: > > ... > pcib0: on motherboard > pci0: on pcib0 > atapci0: possible> port 0 > x3f4-0x3f7,0x1f0-0x1f7 at device 1.0 on pci0 > atapci0: Busmastering DMA not supported > panic: resource_list_alloc: resource entry is busy > > I am also having this problem with 4.0-CURRENT kernels since February > 18, both with my own custom kernel config and GENERIC. > I have to revert to the ata driver of February 17 or earlier to get the > system booting again, and then it runs perfectly. Hmm, seems to be a resource conflict problem, question is what is causing this. Could you do a verbose boot both with the old working kernel, and the new failing one ? > This machine has an Intel motherboard with a Mercury chipset, 64 Mbyte > RAM, Matrox Millenium II, two Western Digital disks, and it ran all > previous FreeBSD releases perfectly for almost five years. Yeah I notice the RZ 1000 chips in there, BE CAREFULL, I wouldn't use this for anything I cared about... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RC3 install floppies: panic: resource_list_alloc: resource entry is busy
Hi folks, I just tried to boot the RC3 install floppies on my Pentium 66 testbox. It gets through the config stage without trouble, but then panics immediately with: ... pcib0: on motherboard pci0: on pcib0 atapci0: port 0 x3f4-0x3f7,0x1f0-0x1f7 at device 1.0 on pci0 atapci0: Busmastering DMA not supported panic: resource_list_alloc: resource entry is busy I am also having this problem with 4.0-CURRENT kernels since February 18, both with my own custom kernel config and GENERIC. I have to revert to the ata driver of February 17 or earlier to get the system booting again, and then it runs perfectly. This machine has an Intel motherboard with a Mercury chipset, 64 Mbyte RAM, Matrox Millenium II, two Western Digital disks, and it ran all previous FreeBSD releases perfectly for almost five years. Anybody else having this problem ? And before I start digging, any idea where to look for a solution, if it makes sense at all ? Kind regards, Hans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
