[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Falcon panics, DEBUG & ST_POOL_SIZE (Was: Testing sysinst.fs)
On Wed, 12 Nov 2008, T. Makinen wrote:
On Tue, Nov 11, 2008 at 1:42 AM, David Brownlee <abs%netbsd.org@localhost>
Excellent. So 22 fails but 40 works. Could you maybe test 32 and
a couple of other values to find the smallest value that reliably
Yes, I'll run some tests with different ST_POOL_SIZE values tomorrow with
unclean file systems.
Adding 'fsck_flags=-fp' to /etc/rc.conf will force a full fsck on
boot. (Add -P if you like a progress bar :)
Does a kernel without REAL_DMA choke on both, or does it work on
030 and fail on 060?
Kernel without REAL_DMA worked with 030 and 060. So far the only crash has been
with kernel which has REAL_DMA defined and ST_POOL_SIZE set to 22.
Interesting... so with a high enough ST_POOL_SIZE we may not
need to undefine REAL_DMA at all, which would be nice.
If you run out of other tests it might be interesting to see
the relative performance with and without REAL_DMA (something
like pkgsrc/benchmarks/iozone would probably be a reasonable
test case). Only if you run out of other things to play with :)
OK, so we're choking in one of the three uvm_map() calls in
pmap_init() in sys/arch/atari/atari/pmap.c
uvm_km_check_empty() is checking that an area of memory
is free to map (that is doesn't overlap with any existing
Could you add printf() calls before each of those uvm_map()s
showing the address and length in each case? That should let
us know which is failing, and hopefully some insight into
what is overlapping.
It fails at first uvm_map() call. I added debug printf() calls with address and
value of addr, hopefully this helps.
Here's picture of panic (sorry about crappy quality this time), debug printf()
output is at second line:
I'm curious that the 0x4fb0000 in uvm_map is given as a size, but
uvm_km_check_empty() panics when it gets to virtual *address*
Here's also dmesg with debug printf() calls from FALCON kernel without DEBUG
OK, those the numbers in the uvm_map calls make ~no sense to me.
The same vaddr_t start in all cases but with different sizes?
I think something very bogus is going on.
Hmmm, in atari/pmap.c we have
pmap_bootstrap(kernel_size, hw_addr, hw_pages)
While atari/atari_init.c calls
pmap_bootstrap(vstart, stio_addr, ptextra);
where (as far as I can tell)
vstart: first free virtual address
stio_addr: is set to 0xff8000, then
reset to something else in map_io_areas()
ptextra: number of pages needed by the initial
kernel pagetable (probably)
There is a maze of twisty code going on here :/
I think we need to go through atari/atari_init.c and work out
what areas of memory its using and then pass those across to
pmap_bootstrap() so the uvm_map() calls can get it right...
./build.sh -m atari kernel=FALCON
Thanks for the tip, I have been using just nbconfig and nbmake-atari to
configure and build kernel.
Ah, excellent - that will be slightly faster than build.sh as
it will not need to rebuild make each time :)
David/absolute -- www.NetBSD.org: No hype required --
Main Index |
Thread Index |