Re: Testing sysinst.fs

["David Ross" <dross%pobox.com@localhost>]

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