On Fri, Oct 11, 2013 at 07:33:27AM +0000, Stojsavljevic, Zoran wrote:
> Hello to seabios list (and to direct participants of below thread),
> I have problem to boot to GRUB from SeaBIOS, since I was able to
> overcome some of the obstacles on my way to here. Now I am blocked
> with the KBD: int09h_handler(): unknown scancode read: 0x5c!
Please compile seabios at debug level 8 and then post the full log.
The previous reports that you found may not be related to the issue
you are seeing.
Hello to seabios list (and to direct participants of below thread),
I have problem to boot to GRUB from SeaBIOS, since I was able to overcome some of the obstacles on my way to here. Now I am blocked with the KBD: int09h_handler(): unknown scancode read: 0x5c!
I was researching/goggling around, and I was able to determine the main cause why KBD does not work. Here is the update.
I found the thread: http://www.seabios.org/pipermail/seabios/2012-March/003288.html
Unfortunately, the SaeBIOS code has been changed. In src/usb-ohci.c I could not find any more ohci_free_pipe(), there is only ohci_free_pipes(), so I am not able to apply patch:
diff --git a/src/usb-ohci.c b/src/usb-ohci.c
index 7a437ad..4e020cb 100644
The reason (my best guess) is that from march 2012 to Present SeaBIOS changed significantly.
Another patch which converts alloc_low() to alloc_high() (3 calls) I found and applied, but so far it did not work.
Could anybody advice what I should do to overcome this problem?
Most of The Time you should be "intel inside" to be capable to think "out of the box".
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
Comments are inline.
----- Original Message -----
> From: "Kevin O'Connor" <kevin(a)koconnor.net>
> To: "Dave Frodin" <dave.frodin(a)se-eng.com>
> Cc: "seabios" <seabios(a)seabios.org>
> Sent: Tuesday, October 8, 2013 7:26:25 PM
> Subject: Re: [SeaBIOS] MP Table corruption
> On Tue, Oct 08, 2013 at 05:27:34PM -0500, Dave Frodin wrote:
> > We have a customer that runs a RTOS that uses the MP Tables (rather
> > than ACPI). They are having an issue with the RTOS not being able
> > to determine certain system interrupt settings from the MP
> > tables. The sent me a MPDiag utility (this may be their own MPDiag
> > utility, I believe I've seen others) that exposes the problem. Using
> > it I was able to determine that the mptable that coreboot generates
> > is getting corrupted somehow by seabios. When I bisected seabios I
> > found that there are several commits that cause the mptable
> > corruption. The first two problem commits are ...
> > 5DBF1732
> > ECA5A947
> This is on coreboot, right?
Yes this is for a coreboot build.
> I don't see a commit ECA5A947 in seabios,
Oooops. I rebased and deleted 5DBF1732 after I bisected down to it.
The 2nd commit that breaks the MPtable is actually A2A86E29.
Sorry for the confusion.
> and I don't see how 5DBF1732 could impact mptable. I guess it's
> possible that 5DBF1732 could impact the interrupts as we no longer run
> a sipi on all the processors, but I don't think SeaBIOS should have to
> issue a sipi - if that is doing something that impacts the OS then
> coreboot should do it as part of initializing the processors.
On Mon, Oct 07, 2013 at 01:16:30PM +0300, Evgeny Budilovsky wrote:
> Signed-off-by: Evgeny Budilovsky <evgeny.budilovsky(a)ravellosystems.com>
Thanks for submitting.
I'm fine with the patch. But can you expand on what "pvscsi" is, what
advantages there is for an user to enable it, what hypervisors support
it, etc. Ideally this info would be in the Kconfig menu as well.
We have a customer that runs a RTOS that uses the MP Tables (rather than ACPI).
They are having an issue with the RTOS not being able to determine certain system interrupt
settings from the MP tables. The sent me a MPDiag utility (this may be their own MPDiag utility, I
believe I've seen others) that exposes the problem. Using it I was able to determine that the mptable
that coreboot generates is getting corrupted somehow by seabios. When I bisected seabios I found
that there are several commits that cause the mptable corruption. The first two problem commits are ...
I reverted both of those commits and still had issues, so for the short term solution I just used a
seabios branch based off of 4EDDA08 (which is the commit that precedes 5DBF1732) to allow
the customers MPDiag to pass.
Has anybody else seen an issue like this?
Anybody have any suggestions on how to approach fixing this?