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"
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
)?
>
> 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&qu
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
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
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
>
> >> - kldload i915
> >>
> >> - startx
> >>
> >> During X server start I get the following:
> >>
> >> #10 0x808c2947 in resource_list_alloc (rl=,
> >> bus=, child=, type= >> optimized out>,
&g
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
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 0xffff808c2947 in resource_list
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/sy
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 @ +0x
d 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
>&
1, 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
&g
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) a
... :)
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
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 @ +
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
>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
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_
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
Hi,
created a FreeBSD 4.0 SNAP yesterday. Made the experience, that
4.0 can't be booted on my Laptop.
Unfortunately the reboot takes in effect after a very short time, too
short to write down more lines from the kernel
Could we perhaps raise the reboot time by default to something like
60
On 16 Jan 2000, Thomas Graichen wrote:
> i'm currently trying to get the initio driver from initio ready for
> -current and have it working fine with an u2w controller on one
> machine (smp btw.) after finding out the COMPAT_PCI_DRIVER thing :-)
> but still have problems with an 9100 utra control
i'm currently trying to get the initio driver from initio ready for
-current and have it working fine with an u2w controller on one
machine (smp btw.) after finding out the COMPAT_PCI_DRIVER thing :-)
but still have problems with an 9100 utra controller on another
machine where i get:
resoource
34 matches
Mail list logo
