On Thu, Feb 09, 2012 at 01:22:23PM +0100, Fred . wrote:
> Lots of stuff have been happening lately (namely VGA and VBE related
> stuff). Also some fixes.
>
> Perhaps it is time for a new release soon?
It's a good question. I have some USB fixes I want to integrate
before releasing. Does anyone else know of any issues that should be
fixed before a release?
-Kevin
Hi Kevin,
You wrote:
>> >Out of curiousity, if you disable ohci_free_pipe() (by adding a
>> >"return" as the first statement of the function) does the keyboard
>> >work long enough to get to the boot menu?
>>
>> I tested this and i couldn't get to the boot menu.
>
>Okay - that's weird. I wonder if this isn't just a matter of the
>"free" code being incorrect. Can you send the log of the session with
>ohci_free_pipe disabled?
As i do not have a normal USB keyboard at the moment (last december i
borrowed one) i have tested latest git again with my wireless Logitech
keyboard/mouse combo.
See attached log.
If you prefer a log with a normal USB keyboard i will try to borrow it
again.
I have tried to debug this a little but had no succes yet.
I tried to understand the OHCI spec.
Am i right that you use the "LEGACY SUPPORT INTERFACE SPECIFICATION" via
emulation interrupts and Legacy Support Registers 100h, 104h,(i/o
address 60h) 108h(i/o address 60h) and 10Ch(i/o address 64h) ?
I have "# CONFIG_PS2PORT is not set" because my target doesn't have a
ps2 keyboard controller.
I could not find the Legacy Support Register: HceControl (100h) being
setup in SeaBIOS .(for emulating 60h + 64h)
I think i found some code for that in Geode VSA that i suspect to be
wrong, but i'm not sure yet.
I also attached a lspci with coreboot/SeaBIOS + linux for reference.
On Tue, Feb 14, 2012 at 10:48:09AM +0100, Fred . wrote:
> With the VBE 3.0 support claimed, perhaps it is time for a new release soon?
I have a few more things on my list that I'd like to get through
before starting a release process. (For example, some OHCI fixes.)
It's probably worthwhile to start the discussion though.
-Kevin
Hello All,
I am writing some code to share some devices via the xenstore, yet I
found a small problem.
When I list the devices from the PCI I get the device id and the
vendor id. On the xenstore I get the virtual-device, yet I have no
apparent way to correctly map them, Do I need to enumerate the PCI
devices, ask the size and then compare to xenstore so I can map them?
but what if they have the same size?
For example on my test VM I have to vbd 832 and 768 first is cdrom the
second disk.
On the pci I have this:
Device Vendor
32902 4663
4115 184
22611 1
I am interested in 226611 that corresponds to XEN.
Some light on this small issue?
Thanks for the help.
Daniel
--
+-=====---------------------------+
| +---------------------------------+ | This space intentionally blank
for notetaking.
| | | Daniel Castro, |
| | | Consultant/Programmer.|
| | | U Andes |
+-------------------------------------+
On Mon, 2012-02-13 at 23:21 +0900, Daniel Castro wrote:
> Hello,
>
> I have encountered something a little strange, if I set up the debug
> lvl to 3 or more Y will get a Triple VCPU fault. If I set it to 1 the
> bios runs normally but I loose a lot of information that I need to
> debug. Sometimes if I try to print char * variables regardless of the
> debug level I still get the fault.
>
> Any ideas why?
My guess is that there is a debug print at lvl>=3 which ends up
dereferencing a NULL pointer in one of its arguments (probably a %s) and
this leads to a page fault. This in turn leads to a double fault because
SeaBIOS does not install a page fault handler and then a triple fault
because it also does not install a double fault handler. Likewise when
you are printing "char * variables regardless of the debug level".
You could test this by adding an explicit check for null in the bit of
bvprintf which handles %s, perhaps putc()ing "(null)" instead.
> Thanks for the ideas/pointers/ anything!
>
> Daniel
>
>On Mon, Dec 26, 2011 at 10:31:35PM +0100, Nils wrote:
>> With that patch:
>>
>> pmm_free 0x1f7b4a30 (detail=0x1f7b4a60)
>> ohci_free_pipe 0x1f7b4aa0
>> signal_freelist control=97
>> signal_freelist2 control=87
>> WARNING - Timeout at ohci_waittick:275!
>> pmm_free 0x1f7b4a90 (detail=0x1f7b4ac0)
>> ohci_free_pipe 0x1f7b4b00
>> signal_freelist control=97
>> signal_freelist2 control=87
>> WARNING - Timeout at ohci_waittick:275!
>> pmm_free 0x1f7b4af0 (detail=0x1f7b4b20)
>> init serial
>> Found 1 serial ports
>
>Out of curiousity, if you disable ohci_free_pipe() (by adding a
>"return" as the first statement of the function) does the keyboard
>work long enough to get to the boot menu?
I tested this and i couldn't get to the boot menu.
Thanks, Nils.
