Port-atari archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Testing sysinst.fs



I should point out as well that one of the panics I list below seems quite similar to the first one Tuomo hit:
http://koti.welho.com/tmakinen/atari/panic.jpg

David Ross
dross%pobox.com@localhost

----- Original Message ----- From: "David Ross" <dross%pobox.com@localhost>
To: "T. Makinen" <tjamaloo%gmail.com@localhost>; "David Brownlee" 
<abs%netbsd.org@localhost>
Cc: <port-atari%netbsd.org@localhost>
Sent: Wednesday, November 12, 2008 11:22 PM
Subject: Re: Testing sysinst.fs


David's latest sysinst (http://mono.org/abs/sysinst6.fs.gz) appears to run installboot properly. At least I get good output from it (I think the same as I saw with a working NetBSD 1.6.1 install). I'm just not sure yet if it really worked because I can't get to a bootable state yet. But assuming it does, nice work!

The next step for me was to get booted up on the ATARITT kernel where I have networking. From there I tried an install to see if the hard drive boot will work. I'm happy to report that as of the 11/09 build, the ATARITT kernel boots for me and I can get networking. But getting further with the install has been difficult...

I made two attempts tonight to get 200811090002Z installed but in both cases I hit different kernel panics. The first one died extracting the first large set. I got:

panic: ppol_put: buf64k: page header missing
I didn't write down the data from the stack other than the function names:
panic
pool_put
buf_mrelease
buf_trim
buf_drain
uvm_pageout
lwp_trampoline

The next panic I got was a little earlier, during the FTP of the first large set itself. I believe the panic was "lock error" but it scrolled off the screen after I dumped the stack trace. It was a very long stack trace so I only wrote down the top:
panic
lockdebug_abort
mutex_abort
mutex_vector_enter
mutex_enter
biodone2
biodone
sddone
scsipi_complete
scsipi_done
run_main
ncr_ctrl_intr
scsi_ctrl
mfp2_5380
pmap_changebit
... didn't copy the rest ...

If you'd like to tackle either one of these, let me know and I can provide more detail!

David, I think you had previously discussed some changes that would cut down the size of the ATARITT kernel. Please do make that change, since as of right now the ATARITT kernel is just slightly over the size of a 1.44MB floppy when gzip'd. I used ghostlink to transfer it, but it's a bit awkward and slow.

Also, even thought we don't yet know for sure if boot works yet, your installboot change at least allows me to get further with the install. Can you submit it?

Thank you!

David Ross
dross%pobox.com@localhost


----- Original Message ----- From: "T. Makinen" <tjamaloo%gmail.com@localhost>
To: "David Brownlee" <abs%netbsd.org@localhost>
Cc: "David Ross" <dross%pobox.com@localhost>; <port-atari%netbsd.org@localhost>
Sent: Tuesday, November 11, 2008 3:42 PM
Subject: Re: Testing sysinst.fs


On Tue, Nov 11, 2008 at 1:42 AM, David Brownlee <abs%netbsd.org@localhost> 
wrote:
       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
       works?

Yes, I'll run some tests with different ST_POOL_SIZE values tomorrow with
unclean file systems.

       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.

       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
       mappings).

       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:
http://koti.welho.com/tmakinen/atari/debug.jpg

Here's also dmesg with debug printf() calls from FALCON kernel without DEBUG
option:
http://koti.welho.com/tmakinen/atari/Falcon-netbsd-debug-dmesg

       btw, if you have another faster box you can cross build a kernel
       by running the following (once only) to build a cross compiling
       toolchain:

           ./build.sh -m atari tools

Yes, I use my PC box (running NetBSD on vmware) to cross build kernels, very
convenient way :)

       Then each time you change the source:

           ./build.sh -m atari kernel=FALCON

Thanks for the tip, I have been using just nbconfig and nbmake-atari to
configure and build kernel.

-Tuomo





Home | Main Index | Thread Index | Old Index