headers
Kevin O'Connor | 3 Apr 2010 02:14

[PATCH] Refactor USB hub code.


All four implementations of hubs (and root hubs) were very similar.
Replace them with a single implementation that uses callbacks for the
three custom parts (detect, reset, disconnect) of each type of hub.
---
 src/usb-ehci.c |  100 ++++++++++++++++++++++++++---------------------------
 src/usb-hub.c  |  106 ++++++++++++++++++++++++++-----------------------------
 src/usb-hub.h  |   10 -----
 src/usb-ohci.c |   82 ++++++++++++++++++-------------------------
 src/usb-uhci.c |   75 ++++++++++++++++++---------------------
 src/usb.c      |   64 ++++++++++++++++++++++++++++++++-
 src/usb.h      |   25 ++++++++++++--
 7 files changed, 253 insertions(+), 209 deletions(-)

diff --git a/src/usb-ehci.c b/src/usb-ehci.c
index 8e3219f..1f683c8 100644
--- a/src/usb-ehci.c
+++ b/src/usb-ehci.c
 <at>  <at>  -13,7 +13,6  <at>  <at> 
 #include "pci_regs.h" // PCI_BASE_ADDRESS_0
 #include "usb.h" // struct usb_s
 #include "farptr.h" // GET_FLATPTR
-#include "usb-hub.h" // struct usbhub_s
 #include "usb-uhci.h" // init_uhci
 #include "usb-ohci.h" // init_ohci

 <at>  <at>  -40,13 +39,17  <at>  <at>  struct usb_ehci_s {
 #define EHCI_TIME_POSTPOWER 20
 #define EHCI_TIME_POSTRESET 2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin O'Connor | 3 Apr 2010 02:15

[PATCH] Some improvements to optionrom preemption support.


Enable preemption during VGA mode switch call - this call can take
several milliseconds on real hardware.

Call yield() in finish_preempt() - when preemption is configured it
allows threads in wait_preempt() to run; when not configured it gives
an opportunity for threads to execute after the implicit delay from
optionrom execution.

Don't penalize priority in run_thread().  The run_thread() code would
implicitly yield because it created the new thread on the list after
the current thread and then jumped to it.  When in a preemption event,
a yield effectively waits approximately one millisecond (to the next
rtc irq).  The implicit yielding in run_thread thus limited the number
of threads one could launch during preemption to 1 per millisecond.
So, change the code so that the new thread is created prior to the
current thread - thus eliminating the effective yield from
run_thread().
---
 src/optionroms.c |    2 ++
 src/stacks.c     |   21 ++++++++++++++-------
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/src/optionroms.c b/src/optionroms.c
index 47f5808..ad88e0c 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
 <at>  <at>  -470,7 +470,9  <at>  <at>  vga_setup(void)
     memset(&br, 0, sizeof(br));
     br.flags = F_IF;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roy Tam | 13 Apr 2010 08:26
Picon

[Qemu-devel] QEMU regression problems

2010/4/12 Gerhard Wiesinger <lists at wiesinger.com>:
> Hello,
>
> Checkit reports some problems under DOS:
> 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED.
> Seems to be a problem of the instruction set.
> 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the
> KVM problem, see my previous post). Seems to be that real-time clock is not
> working correct.
> 3.) There is also a problem with the reported base memory under QEMM386
> (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
> Therefore base memory test fails. I guess that reporting memory CMOS
> tables/interrupt functions are not implemented correctly.
>
> Details are listed below.
>
> All issues are NOT present under VMWare Server 2.0 and with real hardware.
>
> QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II
> Quad Core, x86_64-softmmu.
>
> Any comments?
>

Tested with Checkit 3.0 and QEMM 9.0.
- The NPU error is confirmed and it seems to be a floating point
rounding error in QEMU. This should be a 0.12 regression as it works
in 0.11.1 and 0.10.6.
- The RTC Alarm failure is confirmed too. Is it unimplemented in QEMU?
- The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjørn Mork | 13 Apr 2010 20:48
Picon
Favicon
Gravatar

SeaBIOS error with Juniper FreeBSD kernel

Gleb Natapov <gleb at redhat.com> writes:
> On Sun, Feb 28, 2010 at 02:39:04PM -0500, Kevin O'Connor wrote:
>> On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
>>
>> > I have narrowed it down to SMBIOS.  If I disable CONFIG_SMBIOS the
>> > image boots up fine.
>> 
>> Gleb, have you seen this thread?
>> 
>> Some of the recent changes to smbios that look like possible culprits
>> are:
>> 
>> Make SMBIOS table pass MS SVVP test
>> Use MaxCountCPUs during building of per cpu tables.
>> Add malloc_high/fseg() and rework bios table creation to use them.
>> 
> If there is any seabios revision that works then it is possible to
> bisect to find problematic commit.

Hello,

I'm also bitten by this and have now attempted to bisect it.  The result
was: 

c95d2cee36db79c88253d43a90230ceadf0c26cf is first bad commit
commit c95d2cee36db79c88253d43a90230ceadf0c26cf
Author: Kevin O'Connor <kevin at koconnor.net>
Date:   Wed Jul 29 20:41:39 2009 -0400

    Add auto-generated version info to each build.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin O'Connor | 14 Apr 2010 03:27

SeaBIOS error with Juniper FreeBSD kernel

On Tue, Apr 13, 2010 at 08:48:35PM +0200, Bj?rn Mork wrote:
> Gleb Natapov <gleb at redhat.com> writes:
> > On Sun, Feb 28, 2010 at 02:39:04PM -0500, Kevin O'Connor wrote:
> >> On Sun, Feb 21, 2010 at 04:18:38PM -0700, Brandon Bennett wrote:
> >> > I have narrowed it down to SMBIOS.  If I disable CONFIG_SMBIOS the
> >> > image boots up fine.
> > If there is any seabios revision that works then it is possible to
> > bisect to find problematic commit.
> I'm also bitten by this and have now attempted to bisect it.  The result
> was: 
> 
> c95d2cee36db79c88253d43a90230ceadf0c26cf is first bad commit
> commit c95d2cee36db79c88253d43a90230ceadf0c26cf

It looks like memory layout changes in the f-segment is tickling the
underlying bug.  I don't think SMBIOS, the above commit, or the other
commit identified earlier are the root cause of the problem.  Instead,
I'd guess these commits just change the memory layout enough to avoid
the root cause.

This looks like it is going to require some careful study with a
debugger and some execution traces.  Unfortunately, since this image
isn't available for download it makes it difficult to track down.

-Kevin
Permalink | Reply | 0 comments |
headers
Kevin O'Connor | 14 Apr 2010 03:16

[Qemu-devel] QEMU regression problems

On Tue, Apr 13, 2010 at 02:26:10PM +0800, Roy Tam wrote:
> 2010/4/12 Gerhard Wiesinger <lists at wiesinger.com>:
> > 3.) There is also a problem with the reported base memory under QEMM386
> > (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB.
> > Therefore base memory test fails. I guess that reporting memory CMOS
> > tables/interrupt functions are not implemented correctly.
> 
> - The Base Memory > 640K error seems to be SeaBIOS related. QEMU Bochs
> BIOS(tested with both -old-bios hack in 0.12 series and old 0.11.1)
> will just freeze after QEMU counted RAM.(Tested with ScriptPC and
> Bochs).

The SeaBIOS log would really help.  This can be done by adding:

-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios

to the qemu command line.

The memory can be obtained in several places (int 12, int 1588, int
15e801, int 15e820, and mem 40:13).  All look fine to me from looking
at the code.

-Kevin
Permalink | Reply | 0 comments |
headers
Kevin O'Connor | 14 Apr 2010 03:22

questions about seabios ohci code

I'm CC'ing the mailing list.

On Wed, Apr 14, 2010 at 02:04:48AM +0800, Qing Pei Wang wrote:
> hi kevin,
>    i am learning the code of seabios/ohci stack followed with OHCI spec. I
> have some question.

Note that the OHCI support has only been tested on a modified qemu - I
haven't had any reports on real hardware.

> 1) in the function alloc_intr_pipe (usb.c line118)what does the frameexp
> mean?

It's log2(epdesc->bInterval) - the log of the sampling time (in ms)
requested by the device.

> 2) how does ohci get the intervals. the code just use epdesc->bInterval, how
> does it init? can pass the parameter from the usb-hid.c?

The epdesc structure is populated by get_device_config() - the config
read from the device includes the device config, interface
descriptions, and end point descriptions.

-Kevin
Permalink | Reply | 2 comments |
headers
Bjørn Mork | 14 Apr 2010 12:51
Picon
Favicon
Gravatar

SeaBIOS error with Juniper FreeBSD kernel

"Kevin O'Connor" <kevin at koconnor.net> writes:

> It looks like memory layout changes in the f-segment is tickling the
> underlying bug.  I don't think SMBIOS, the above commit, or the other
> commit identified earlier are the root cause of the problem.  Instead,
> I'd guess these commits just change the memory layout enough to avoid
> the root cause.

Sounds like a reasonable explanation.  Is there anything I can do to try
to pin down the problem?

> This looks like it is going to require some careful study with a
> debugger and some execution traces.  Unfortunately, since this image
> isn't available for download it makes it difficult to track down.

I understand that.  But I'm afraid I can't provide any such image.

I don't think Juniper has done anything extra-ordinary at this point
however, so I'll try to see if I can create a freely distributable image
triggering the bug using the same tools as them.  Will let you know if I
succeed. 

Bj?rn
Permalink | Reply | 0 comments |
headers
Qing Pei Wang | 15 Apr 2010 04:40
Picon
Gravatar

questions about seabios ohci code

Kevin,
   i had tested the OHCI keyboard, the works but not pretty good as enough.
the reaction time is too long.
So i am trying to learn more about this things.
BTW, seabios/OHCI use count=DIV_ROUND_UP(PIT_TICK_INTERVAL * 1000 * 2,
PIT_TICK_RATE * ms)+1
as the td count. i can not find any document  about that. Where can i find
or some place i missing with OHCI spec?
On Wed, Apr 14, 2010 at 9:22 AM, Kevin O'Connor <kevin at koconnor.net> wrote:

> I'm CC'ing the mailing list.
>
> On Wed, Apr 14, 2010 at 02:04:48AM +0800, Qing Pei Wang wrote:
> > hi kevin,
> >    i am learning the code of seabios/ohci stack followed with OHCI spec.
> I
> > have some question.
>
> Note that the OHCI support has only been tested on a modified qemu - I
> haven't had any reports on real hardware.
>
> > 1) in the function alloc_intr_pipe (usb.c line118)what does the frameexp
> > mean?
>
> It's log2(epdesc->bInterval) - the log of the sampling time (in ms)
> requested by the device.
>
> > 2) how does ohci get the intervals. the code just use epdesc->bInterval,
> how
> > does it init? can pass the parameter from the usb-hid.c?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin O'Connor | 16 Apr 2010 02:25

questions about seabios ohci code

On Thu, Apr 15, 2010 at 10:40:21AM +0800, Qing Pei Wang wrote:
> Kevin,
>    i had tested the OHCI keyboard, the works

Great!  Please send the full SeaBIOS log.

>but not pretty good as enough.
> the reaction time is too long.

Is the time it takes a key to be shown too long?  Or are keys being
lost when typing fast?

> So i am trying to learn more about this things.
> BTW, seabios/OHCI use count=DIV_ROUND_UP(PIT_TICK_INTERVAL * 1000 * 2,
> PIT_TICK_RATE * ms)+1
> as the td count. i can not find any document  about that. Where can i find
> or some place i missing with OHCI spec?

That's internal to SeaBIOS.  SeaBIOS doesn't register a hardware irq
for usb, instead it polls for USB activity on every timer interrupt
(~55ms).  The above calculation determines how many key events to
queue so that no keyboard drops occur.  Usually a keyboard requests
service every 10ms, causing the above calculation will return 11 queue
items.

-Kevin
Permalink | Reply | 0 comments |

Gmane