Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Sep 2015 08:28:17 +0000
From:      Alexey Dokuchaev <danfe@FreeBSD.org>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org>
Subject:   Re: PCI range checking under qemu-system-sparc64
Message-ID:  <20150917082817.GA71811@FreeBSD.org>
In-Reply-To: <20150916211914.GD18789@alchemy.franken.de>
References:  <20150906124859.GA14919@FreeBSD.org> <20150907203152.GA70457@alchemy.franken.de> <55EDFE00.9090109@ilande.co.uk> <20150913022143.GA7862@alchemy.franken.de> <20150913103940.GA60101@FreeBSD.org> <20150913180126.GC7862@alchemy.franken.de> <55F89861.1030107@ilande.co.uk> <20150916031030.GA6711@FreeBSD.org> <55F9C2B8.7030605@ilande.co.uk> <20150916211914.GD18789@alchemy.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 16, 2015 at 11:19:15PM +0200, Marius Strobl wrote:
> [...]
> Which suggest that the next thing to investigate is the CMD646
> emulation. Is there a particular reason why QEMU emulates a
> CMD646U rather than a plain CMD646 as found in the real sun4u
> machines of the USIIe/i era?
> 
> Alexey, does building the port with CDROM_DMA disabled make
> a difference?

Ironically I had it already disabled prior to your question; but I've
rebuilt the port enabling it for completeness' sake.  It did not make
a difference.

Then I've disabled all CAM/ATA stuff (scbus, ata, umass, etc.) in the
kernel config and that's what I see now (this is with CDROM_DMA=on):

  cryptosoft0: <software crypto> on nexus0
  nexus0: <syscons> type unknown (no driver attached)
  Timecounter "tick" frequency 100000000 Hz quality 1000
  Event timer "tick" frequency 100000000 Hz quality 1000
  Timecounters tick every 1.000 msec
  IPsec: Initialized Security Association Processing.
  Trying to mount root from cd9660:/dev/iso9660/TEST [ro]...
  mountroot: waiting for device /dev/iso9660/TEST ...

> Alexey, could you please try to drop into the debugger
> (apparently, ctrl-a b should bring you there with QEMU if
> you have compiled DDB into the kernel) and issue a `show
> intrcnt` (besides a backtrace)?

Not particularly interesting it seems:

  KDB: enter: Break to debugger
  [ thread pid 11 tid 100004 ]
  Stopped at      kdb_enter+0x80: ta              %xcc, 1
  db> bt
  Tracing pid 11 tid 100004 td 0xfffff80001287810
  kdb_break() at kdb_break+0x54
  uart_intr() at uart_intr+0x1e4
  intr_event_handle() at intr_event_handle+0x68
  intr_execute_handlers() at intr_execute_handlers+0x8
  intr_fast() at intr_fast+0x50
  -- interrupt level=0xb pil=0 %o7=0xc045be04 --
  sched_idletd() at sched_idletd+0x3b4
  fork_exit() at fork_exit+0x80
  fork_trampoline() at fork_trampoline+0x8
  db> show intrcnt
  db> 

> On Wed, Sep 16, 2015 at 08:27:52PM +0100, Mark Cave-Ayland wrote:
> > I also see that the output stops after "IPsec: Initialized Security
> > Association Processing." appears on the console. Maybe the crypto uses
> > paths that aren't well tested in QEMU or we are waiting for entrophy?
> 
> Unlikely; "Initialized" means just that, the SA stuff has
> been set up. Also, given that IP isn't used at that point
> IPsec simply isn't either. Unblocking the random device
> in turn comes later, i. e. at least after storage devices
> have been probed.

Marius' thinking is correct; in fact, I've tried to disable various
"auxiliary" stuff earlier (including CRYPTO) and it did not make any
difference.

./danfe



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150917082817.GA71811>