On 26 Jan 2003, Eric Jones wrote:

> On Thu, 2003-01-23 at 23:56, Steve Kargl wrote:
>
> Sorry if this is the second copy, I'm not sure if it went out the first
> time or not
>
> > On Thu, Jan 23, 2003 at 05:40:16PM -1000, Vincent Poy wrote:
> > >
> > > /boot/kernel/acpi.ko text=0x2fab4 data=-0x1a84+0x6e0
> > > syms=[0x4+0x5540+0x702d|]
> >
> > snip
> >
> > > embedded  0     6     A   0x60  3 4 5 6 7 9 10 11 12 14 15
> > > panic: pmap_mapdev: Couldn't alloc kernel virtual memory
> > > Debugger("panic")
> > > Stopped at      Debugger+0x45:  xchgl  %ebx,in_Debugger.0
> > > db> trace
> > > Debugger(c0435e9c) at Debugger+0x45
> > > panic(c0460ba0,0,0,c064cbc4,0) at panic+0x7c
> > > pmap_mapdev(1ffd0000,0,c064cc54,c064cbd4,c060547a) at pmap_mapdev+0x5d
> > > AcpiOsMapMemory(1ffd0000,0,0,c064cbc4,0) at AcpiOsMapMemory+0x12
> > > AcpiTbGetThisTable(c064cc54,c064cc08,c064cc64,c064cc54,c064cc54) at
> > > AcpiTbGetThisTable+0xa6
> > > AcpiTbGetTableBody(c064cc54,c064cc08,c064cc64,0,0) at AcpiTbTableBody+0x3b
> > > AcpiTbGetTable(c064cc54,c064cc64,c064cc54,9,1ffd0000) at AcpiTbGetTable+0x29
> > > AcpiTbGetTableRsdt(1,fd6e0,0,c061a520,c159ec80) at AcpiTbGetTableRsdt+0x1a
> > > AcpiLoadTables(0,c66d8118,c061a3c8,c1586aa0,c064ccfc) at AcpiLoadTables+0x85
> > > acpi_identify(c061a3c8,c159ec80) at acpi_identify+0x99
> > > bus_generic_probe(c159ec80,c66b1090,c064cd34,c028e724,c159ec80) at
> > > bus_generic_probe+0x54
> > > nexus_probe(c159ec80) at nexus_probe+0x186
> > > device_probe_child(c159ef00,c159ec80,c028e4e5,c15917c8,1) at
> > > device_probe_child+0xcc
> > > device_probe_and_attach(c159ec80) at device_probe_and_attach+0x4b
> > > root_bus_configure(c159ef00,c045b660,0,4) at root_bus_configure+0x16
> > > configure(0,649c00,649000,0,c01378b5) at configure+0x22
> > > mi_startup() at mi_startup+0x9a
> > > begin() at begin+0x2c
> > > db>
> > >
> >
> > Disable acpi. acpi is broken.
>
> I had the same problem until today.  If ACPI was enabled, I would get a
> panic on boot.  I removed MAXMEM from my kernel config, recompiled, and
> voila, no panic.  Everything seems to be working, acpi is doing
> something, according to the dmesg.  When I had MAXMEM as an option, I
> received the following panic less than a second into the kernel boot.
>
> pmap_mapdev: Couldn't alloc kernel virtual memory
>
> With MAXMEM unspecified, no problems.  Is there any reason, on newer
> motherboards, to need the MAXMEM option?  Without it specified, I see
> all 256M in the system.  I originally had it for my old MB (a K6-2) that
> wouldn't work without it (4-CURRENT days).  My new MB doesn't need it.
>
> Just my $0.02

        I've actually been using the MAXMEM option since the 2.x days
since I remember unless MAXMEM was specified, FreeBSD will only see 64megs
of ram but I guess they fixed it so it detects more than that sometime
later.


Cheers,
Vince - [EMAIL PROTECTED] - Vice President             ________   __ ____
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / |  / |[__  ]
WurldLink Corporation                                  / / / /  | /  | __] ]
San Francisco - Honolulu - Hong Kong                  / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____]
Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to