Re: Kernel does not boot on TT030

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On 8/30/18 8:31 AM, Stefan Niestegge wrote:
> Ah, ok. We will try that.

Did you ever get kernel booting on TT?


I've now looked a bit into this with Hatari TT emulation.

"initcall_debug" doesn't give any output, but I've enabled the dummy
IRQ handler [1] and get constant warnings from it.  There's quite
a lot of them in few seconds:
----------------------------------------------
$ grep unexpected tt-boot.log | sort | uniq -c
   1200 unexpected interrupt from 104
    212 unexpected interrupt from 112
----------------------------------------------

Any idea what those interrupts are for?


FYI: When I enable profiler at start and invoke debugger after
a while, it gives me following kernel backtrace:
----------------------------------------------
Finalizing costs for 12 non-returned functions:
- 0x46fba: console_unlock (return = 0x47932)
- 0x4781c: vprintk_emit (return = 0x47966)
- 0x4794a: vprintk_default (return = 0x4835c)
- 0x482e4: vprintk_func (return = 0x48016)
- 0x48004: printk (return = 0x585c)
- 0x5834: handle_badint (return = 0x29a0)
- 0x29a8: resume (return = 0x24b2d4)
- 0x24afd0: __schedule (return = 0x24b364)
- 0x24b31a: schedule (return = 0x24b3dc)
- 0x24b3d2: schedule_preempt_disabled (return = 0x24a07a)
- 0x24a008: rest_init (return = 0x318f64)
- 0x318f88: start_kernel (return = 0x318344)
----------------------------------------------

Attached is dot callgraph [2] of the function call counts from
first instruction until above point.

Good tool to view it is XDot (from "xdot" package).  Red lines
in the graph show which functions get called most often.

(I thought call counts are for this case more interesting than
instruction or cycle counts.)


	- Eero

[1] $ grep IRQ .config
CONFIG_IRQ_WORK=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_DUMMY_IRQ=y
CONFIG_DEBUG_SHIRQ=y

[2] Command line to get graph from the Hatari profiler readable
requires removing edges to generic low level functions:
$ hatari_profile.py -s -t -p -g -a System.map \
  --only-subroutines --no-intermediate --compact \
  --ignore-from __start,copy_process.isra.11.part.12 \
  --ignore-to 
memcpy,memset,memmove,memcmp,strlcpy,strlen,strchr,strncmp,kstrdup_const,mutex_lock,mutex_unlock,__mutex_init,__init_rwsem,__init_waitqueue_head,__ashldi3,__lshrdi3,__list_add_valid,__list_del_entry_valid,__alloc_percpu,d_alloc,__d_alloc,__kalloc,__kmalloc,kfree,new_slab,alloc_workqueue_attrs,kmem_cache_alloc,memblock_alloc_try_nid,kmem_cache_create,hwreg_present,__sw_hweight32,printk 
  profile.txt

> Am 30.08.2018 um 00:34 schrieb Michael Schmitz:
> > Quick clarification - stram_pool is only required if the kernel gets
> > loaded to TT-RAM (no -s option).
> >
> > Cheers,
> >
> >    Michael
> >
> > On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz <schmitzmic@gmail.com> 
> > wrote:
> > > Hi Stefan,
> > >
> > > Am 29.08.2018 um 01:00 schrieb Finn Thain:
> > > > On Tue, 28 Aug 2018, Stefan Niestegge wrote:
> > > >
> > > > > the kernel does not start up and run the D-I from the initrd. A serial
> > > > > terminal was connected to one TT, but all it received was "ABCDEJK".
> > > >
> > > > If you have CONFIG_EARLYPRINTK=y then you can enable the early console.
> > > > Try passing the kernel parameter 'earlyprintk'. That should cause 
> > > > kernel
> > > > messages to be sent to the same device(s) to which "ABCDEJK" was sent.
> > >
> > > I have the following options set to direct console messages to the
> > > serial port:
> > >
> > > debug=ser console=tty
> > >
> > > 'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
> > > Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
> > > Messages appearing there mean the boot process has made it out of early
> > > startup code which I'd expect for a TT.
> > >
> > > No idea about any interactions with earlyprintk, sorry.
> > >
> > > Option 'stram_pool=128k' might also be required to reserve ST-RAM for
> > > use by drivers that can only address 24 bit (not sure if that's a
> > > problem with the TT video driver).
> > >
> > > Once you have console messages on the serial port, the option
> > > 'initcall_debug' may be useful to pinpoint where the boot hangs. My
> > > guess would be during probing for optional stuff such as ROM port or
> > > CT60 expansion network card hardware in atari_platform_init(), unless
> > > your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
> > > (m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
> > > that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.

Attachment: profile-unexpected-interrupts-call-counts.dot.gz
Description: application/gzip