Re: PCI range checking under qemu-system-sparc64

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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[email protected]"