> -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@xxxxxxxxxx] > Sent: Tuesday, November 18, 2014 5:16 PM > To: Wang, Yalin > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx; peter.maydell@xxxxxxxxxx > Subject: Re: arm64: virtio broken in upstream kernel > > On Tue, Nov 18, 2014 at 04:33:19PM +0800, Wang, Yalin wrote: > > > -----Original Message----- > > > From: Richard W.M. Jones [mailto:rjones@xxxxxxxxxx] > > > Sent: Tuesday, November 18, 2014 4:30 PM > > > To: Wang, Yalin > > > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx; peter.maydell@xxxxxxxxxx > > > Subject: Re: arm64: virtio broken in upstream kernel > > > > > > On Tue, Nov 18, 2014 at 10:04:10AM +0800, Wang, Yalin wrote: > > > > No, this patch add some change in arm64_memblock_init(), It will > > > > reserve the whole tail page memory, In case it is used by other > > > > drivers, Please try it. :) > > > > > > Not sure I understand. I tried the patch you posted and it didn't > > > fix virtio-mmio for me. Is there another patch you want me to try? > > > > > > Rich. > > > > > A little Strange. if you revert all my patch, Could you re-produce the > > virtio-mmio crash ? > > So I can make sure if it is my patch's problems. > > If I revert 421520ba98290a73b35b7644e877a48f18e06004 and the patch you > posted in this thread, then I get a different problem: > > supermin: internal insmod virtio.ko > supermin: internal insmod virtio_ring.ko > supermin: internal insmod virtio_blk.ko > supermin: internal insmod virtio-rng.ko > supermin: internal insmod virtio_console.ko > supermin: internal insmod virtio_net.ko > supermin: internal insmod scsi_transport_spi.ko > supermin: internal insmod virtio_scsi.ko > supermin: internal insmod virtio_balloon.ko > supermin: internal insmod virtio_mmio.ko > [ 2.653849] BUG: failure at > include/linux/virtio_config.h:125/virtio_device_ready()! > [ 2.654529] Kernel panic - not syncing: BUG! > [ 2.655420] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.18.0-rc4+ #49 > [ 2.655866] Hardware name: linux,dummy-virt (DT) > [ 2.656572] Workqueue: events control_work_handler [virtio_console] > [ 2.657236] Call trace: > [ 2.657770] [<fffffe0000096c70>] dump_backtrace+0x0/0x164 > [ 2.658289] [<fffffe0000096df0>] show_stack+0x1c/0x28 > [ 2.658673] [<fffffe00007259f4>] dump_stack+0x74/0x94 > [ 2.658991] [<fffffe0000724ea4>] panic+0xe8/0x228 > [ 2.659352] [<fffffdfffc142518>] add_port+0x378/0x37c [virtio_console] > [ 2.659902] [<fffffdfffc142fa0>] control_work_handler+0x374/0x390 > [virtio_console] > [ 2.660440] [<fffffe00000cf888>] process_one_work+0x148/0x3a4 > [ 2.660867] [<fffffe00000d0314>] worker_thread+0x13c/0x488 > [ 2.661208] [<fffffe00000d53b8>] kthread+0xe0/0xf8 > [ 2.662145] Rebooting in 1 seconds..Reboot failed -- System halted > > which I'm still investigating ... It looks related actually: in both cases > virtio-mmio is totally broken. > > BTW I'm using 64K pages, if that makes a difference. > Mm.. seems not related with my patch, I suggest you set a write watchpoint in virtio device status memory, To see who change the memory status which is used by virtio_device_ready(). So you can locate the BUG. Good luck! _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
