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
> > > whe
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 ha
_alloc(struct resource_list *rl, devi
rle->flags |= RLE_ALLOCATED;
return (rle->res);
}
- panic("resource_list_alloc: resource entry is busy");
+ device_printf(bus,
+
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 an
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 modul
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 min
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
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:
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 b
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
>
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
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= optimi
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
>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 b
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
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-
ci0: 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
he 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: B
pci0: 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 kerne
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
20 matches
Mail list logo
