Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path

2013-06-03 Thread Stefan Priebe - Profihost AG
Am 31.05.2013 13:02, schrieb Amos Kong:

 ...

 thanks for this great explanation. I've done what you sayd but it still
 does not work.

 Here is the output of the seabis debug log where you see the loop:
 http://pastebin.com/raw.php?i=e53rdW2b
 
 | found virtio-scsi at 0:5
 | Searching bootorder for: /pci@i0cf8/*@5/*@0/*@0,0
 | virtio-scsi vendor='QEMU' product='QEMU HARDDISK' rev='1.5.' type=0 
 removable=0
 | virtio-scsi blksize=512 sectors=104857600
 
 It mean the fixed fw_dev_path can be identified.
 
 You problem is a disrelated issue. I didn't see handle_18 before restart, it
 means guest succeses to boot from second nic. How does the resume be
 caused?

No it def. does not succeed. Only the first nic gets a reply from a tftp
server. It shows a menu and then does:
  localboot -1

which causes to go to the next boot device (pxelinux.cfg).

It then tries to boot from the 2nd nic. But there it gets only an IP
through DHCP but no tftp details or even an answer.

PS: this was working fine with Qemu 1.4.2

 Please only aasign two nics for guest, let's see if restart occurs.

With one nic i see correctly - no bootable device restart in 1 sec.
With only two nics the screen just turns black and nothing happens at
all after trying PXE from 2nd nic. But no message and no restart.

 Did you config pxe+tftp service for second nic? did you set some rom
 that just reboot the system?
DHCP yes tftp service no.

Stefan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios


Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path

2013-05-31 Thread Stefan Priebe - Profihost AG
Am 31.05.2013 13:02, schrieb Amos Kong:

 ...

 thanks for this great explanation. I've done what you sayd but it still
 does not work.

 Here is the output of the seabis debug log where you see the loop:
 http://pastebin.com/raw.php?i=e53rdW2b
 
 | found virtio-scsi at 0:5
 | Searching bootorder for: /pci@i0cf8/*@5/*@0/*@0,0
 | virtio-scsi vendor='QEMU' product='QEMU HARDDISK' rev='1.5.' type=0 
 removable=0
 | virtio-scsi blksize=512 sectors=104857600
 
 It mean the fixed fw_dev_path can be identified.
 
 You problem is a disrelated issue. I didn't see handle_18 before restart, it
 means guest succeses to boot from second nic. How does the resume be
 caused?

No it def. does not succeed. Only the first nic gets a reply from a tftp
server. It shows a menu and then does:
  localboot -1

which causes to go to the next boot device (pxelinux.cfg).

It then tries to boot from the 2nd nic. But there it gets only an IP
through DHCP but no tftp details or even an answer.

PS: this was working fine with Qemu 1.4.2

 Please only aasign two nics for guest, let's see if restart occurs.

With one nic i see correctly - no bootable device restart in 1 sec.
With only two nics the screen just turns black and nothing happens at
all after trying PXE from 2nd nic. But no message and no restart.

 Did you config pxe+tftp service for second nic? did you set some rom
 that just reboot the system?
DHCP yes tftp service no.

Stefan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios