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
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
>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
> 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 @
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:
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 s
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
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,
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
> >
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
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
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_pro
>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
31 matches
Mail list logo
