ok, I get it. Will you work on this issue ? it has block our nightly test. Hope
will be fixed as soon as possible.
best regards
yang
-----Original Message-----
From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
Sent: Thursday, July 15, 2010 11:20 PM
To: Zhang, Yang Z
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Zhang, Jianwu; Xu, Jiajun
Subject: Re: cs:21768 causes guest spend more time on boot up
At 16:14 +0100 on 15 Jul (1279210449), Zhang, Yang Z wrote:
> Is type 11 data structure cover 0xEB180 ? where is the start address
> of type 11 structure? and the max length ?
No, the type-11 table is in the middle of the other SMBIOS tables. The
SMBIOS tables cover 0xEB000 -- 0xEB171 before my patch; after the patch
they go a little further. Extending them to cover 0xEB000 -- 0xEB187
(just by making existing strings a little longer, not adding a type-11
table) makes CentOS 5.5 x64 hang up on boot.
Cheers,
Tim.
>
> best regards
> yang
>
>
> -----Original Message-----
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Thursday, July 15, 2010 8:23 PM
> To: Zhang, Yang Z
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Zhang, Jianwu; Xu, Jiajun
> Subject: Re: cs:21768 causes guest spend more time on boot up
>
> At 10:48 +0100 on 15 Jul (1279190937), Tim Deegan wrote:
> > At 09:07 +0100 on 15 Jul (1279184841), Zhang, Yang Z wrote:
> > > In our recently nightly test, we find guest will cost more
> > > time to boot up. After our investigation, we find that for rhel5u3 and
> > > rh5u5 guest it will stop at ?start udev ? for long time when boot
> > > up. And we find cs:21768 will cause this issue. Do you meet the same
> > > problem?
> >
> > Nope, works fine for me[tm]. RHEL 5.5 stops at start_udev for about 5
> > seconds, but that's not unusual. I'll try RHEL 5.3.
>
> I've reproduced this slowdown on CentOS 5.5 x64. It seems to be caused
> by the size of the SMBIOS tables - reverting the part of this cset that
> adds a type 11 object fixes the boot time; then just making some of the
> other SMBIOS strings longer causes it to hang again. I wonder whether
> we're running into some other BIOS datastructure around 0xEB180
>
> Tim.
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, XenServer Engineering
> Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home