On Tue, Dec 06, 2011 at 07:32:55PM -0500, Amos Kong wrote:
> ----- Original Message -----
> > On Tue, Dec 06, 2011 at 01:39:35PM +0800, Amos Kong wrote:
> > > Only func 0 is registered to guest driver (we can
> > > only found func 0 in slot->funcs list of driver),
> > > the other functions could not be cleaned when
> > > hot-removing the whole slot. This patch adds
> > > device per function in ACPI DSDT tables.
> > > Notify only when func0 is added and removed.
> > >
> > > Have tested with linux/winxp/win7, hot-adding/hot-remving,
> > > single/multiple function device, they are all fine(all
> > > added devices can be removed).
> > >
> > This includes some bits I wrote but this is not an ack
> > of the patch yet :)
> >
> > I find it surprising that this works: a function
> > has _EJ0 so would not guest expect that ejecting
> > a single one will only remove it, and not all functions?
>
> Removing single func is not supported by specific, and current code
> (qemu/kernel pci driver) process hot-remove with the whole slot.
> We could not hot-remove single func with/without this patch.
>
> Register _EJ0() for each func, then all the funcs will be record
> into the function list of the slot.
Just as an update - it's not clear to me what this patch does, and it
seems like Michael had some concerns.
Also, it doesn't seem right to hardcode the generation of that many
devices (248) in the AML code.
So, unless there are further comments I'm going to hold off on this
patch.
-Kevin
On 2012-02-27 10:51, Daniel P. Berrange wrote:
> I'm seeing current QEMU GIT fail to boot MS-Dos 6.22 with the following
> crash:
>
> # qemu-system-x86_64 -fda ~/MS-DOS\ 6.22.img -m 1 -curses
> iPXE v1.0.0-591-g7aee315
> iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+00000000+00000000 C900
>
> Booting from Floppy..
> . qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000001000effff
>
> EAX=ffffffff EBX=ffffffff ECX=0000c934 EDX=00000068
> ESI=00006801 EDI=00000000 EBP=0000002b ESP=0000fff5
> EIP=ffffffff EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0040 00000400 0000ffff 00009300
> CS =f000 000f0000 0000ffff 00009b00
> SS =9ec4 0009ec40 0000ffff 00009300
> DS =9ec4 0009ec40 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT= 000fcd78 00000037
> IDT= 00000000 000003ff
> CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> CCS=000000d0 CCD=00000068 CCO=SARL
> EFER=0000000000000000
> FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
> FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
> XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
> XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
> XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
> XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
> Aborted
>
>
> Git bisect blames this
>
> commit 41bd360325168b3c1db78eb7311420a1607d521f
> Author: Jan Kiszka <jan.kiszka(a)siemens.com>
> Date: Sun Jan 15 17:48:25 2012 +0100
>
> seabios: Update to release 1.6.3.1
>
> User visible changes in seabios:
> - Probe HPET existence (fix for -no-hpet)
> - Probe PCI existence (fix for -machine isapc)
> - usb: fix boot paths
>
> Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
>
>
> I tried to bisect Seabios, but every revision in Seabios upstream works
> fine.
>
> Then I noticed, that if I rebuild the BIOS, from the exact same revision
> 1.6.3.1 revision that is committed in 'seabios' submodule in QEMU, then
> it works fine. So AFAICT, it is not the Seabios source code at fault,
> but rather the binary build we have commited to GIT. Should/can we rebuild
> the bios.bin in GIT ?
Probably not without understanding what causes this strange
inconsistency. If Seabios builds without errors and then later on fails,
this is also a bug.
Kevin, what information do you need to assess my tool chain?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Hi,
New revision of my 64bit pci patches. This is what I'm using to play
with 64bit PCI bars (ivshmem + qxl devices) and bridge support (patches
from mst).
Changes in v2:
* tried to reduce the stack footprint of 64bit hex number printing.
* changed patch splitting to make them (hopefully) more readable.
* full support for bridges with 64bit memory windows, even nested.
Also availabe from:
git://git.kraxel.org/seabios pci64
enjoy,
Gerd
Gerd Hoffmann (6):
output: add 64bit hex print support
pci: split device discovery into multiple steps
pci: 64bit support.
pci: bridges can have two regions too
pci: fix bridge ressource allocation.
pci: add prefmem64
src/acpi-dsdt.dsl | 7 ++
src/acpi-dsdt.hex | 72 ++++++++++++---
src/config.h | 2 +
src/output.c | 23 ++++-
src/pci.h | 14 ++-
src/pciinit.c | 272 ++++++++++++++++++++++++++++++++++++++---------------
6 files changed, 294 insertions(+), 96 deletions(-)
I'm a new subscriber to seabios.org so feel free to straighten me out if needed.
I've been debugging an problem we've been seeing with not being able to boot (Ubuntu specifically) off
of a variety of "newer" USB thumb drives. I've been specifically looking at an older/newer pair of
Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down the problem to the blockcmd.c file.
The function scsi_init_drive() queries the USB device to determine stuff like vendor/device/size/etc.
Near the end of the function is a call to cdb_mode_sense_geom(&dop, &geomdata) to retrieve the info
related to cyl/head type stuff. On the older/working thumbdrive it returns zeroes for all of the values
that get used by the code. The newer/failing drive generates a "stall" on the USB bus, which it never
recovers from. The cdb_mode_sense_geom() function is sending a SCSI CDB Mode Sense (CMD=0x5A) to the device.
As a hack of a test, I removed the call to cdb_mode_sense_geom() and filled the buffer it should have returned
with zeroes and the failing thumbdrive now boots.
I have some searching I need to do to find out...
1) Is there a SCSI command to determine what protocols are supported?
2) Is there another SCSI command that might return similar required data?
Has anyone out there experienced similar booting difficulties?
Or does anyone have any recommendations on what approach I should take?
thanks,
Dave
To allow guests to load the native SHPC driver
for a bridge, we must declare an OSHP method
for the appropriate device which lets the OS
take control of the SHPC.
As we don't access SHPC at the moment, we
don't need to do anything - just report success.
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
---
diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl
index 442e7a8..3f50169 100644
--- a/src/ssdt-pcihp.dsl
+++ b/src/ssdt-pcihp.dsl
@@ -24,6 +24,7 @@ DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1)
ACPI_EXTRACT_METHOD_STRING aml_ej0_name \
Method (_EJ0, 1) { Return(PCEJ(0x##slot)) } \
Name (_SUN, 0x##slot) \
+ Method (OSHP, 1) { Return(0x0) } \
}
hotplug_slot(03)
Hi,
I'm not sure what the correct procedure is for requesting these so I
hope it is ok to post here.
Xen is currently using the 1.6.3-stable branch of SeaBIOS, our users
have requested a backport of two commits (related to building on NetBSD
IIRC):
97f1ffcfac4ca382b5008a7aabfc2c300131f978 Add PYTHON definition to Makefile.
805ede2bd35243a4298bc64bd81be6db7cf57f58 Permit .rodata.__PRETTY_FUNCTION__. sections in roms.
Would it be possible to backport those two?
I actually already backported these to our own 1.6.3-stable-xen branch
but belatedly thought I should inquire about the possibility of an
upstream backport -- it would be much preferable to keep the divergence
between 1.6.3-stable and -xen to a minimum.
If you are happy to backport then you could (if you wanted) pull
directly from the Xen branch:
The following changes since commit 80d11e8577bf03e98f2eb1b0cb3a281ab2879c9e:
Update version to 1.6.3.1 (2011-11-24 12:02:03 -0500)
are available in the git repository at:
git://xenbits.xen.org/seabios.git 1.6.3-stable-xen
Kevin O'Connor (2):
Add PYTHON definition to Makefile.
Permit .rodata.__PRETTY_FUNCTION__. sections in roms.
Makefile | 7 ++++---
tools/layoutrom.py | 12 ++++++++----
2 files changed, 12 insertions(+), 7 deletions(-)
Cheers,
Ian.
Greeting,
As part of the xen code for PV-Drivers in Seabios I am trying to boot
from a PV drive. The two ends are connected, and it should be working,
but when I try to boot from the harddrive it fails.
Inside the code I treat the cdrom as a drive, except I register it in
seabios with the cdrom function, but also it fails to boot from cdrom
with Error 003.
This could mean that maybe I am adding the drives incorrectly, or that
my read/write opertaion is wrong.
Since the operation runs in 16bit how can I debug it to see what is being done?
Thanks for the answers.
Daniel
--
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| | | Daniel Castro, |
| | | Consultant/Programmer.|
| | | U Andes |
+-------------------------------------+
Op woensdag 22-02-2012 om 23:52 uur [tijdzone +0100], schreef Christian
Gmeiner:
> ping
> --
The only thing that comes to my mind is that you could try coreboot
version 4.0-1975-g1b785c7 because that's the last version that i used.
According to the coreboot mailinglist there seems to be a problem in
recent versions with vbios and option rom init in seabios.
See 'Fix multipleVGA cards resource conflict on Windows' .
Maybe it affects your board also.
Greetings, Nils.