hmmm, we set baud to zero in order to avoid the serial initialization
phase in Xen, this way we can make sure that the serial terminal that
worked during OF will work for Xen.
I'm willing to bet that closing stdin will require that init phase,
assuming I'm correct, we have 4 options:
1) probe the devtree for all the serial port settings and fully
init the driver.
2) require the bootparam to have the correct serial setting and
fully init the driver
3) figure out another way decide if we close stdin or not (stdin !
= stdout? detect that it is not USB?)
4) since this is specifically a SLOF on JS20 problem get the SLOf
guys to do something about it.
Thoughts?
On Jun 13, 2006, at 4:31 PM, Maria Butrico wrote:
Unfortunately, if we close stdin we get no console output on the js20.
Hollis Blanchard wrote:
On Thu, 2006-06-08 at 19:02 -0400, Jimi Xenidis wrote:
On Jun 8, 2006, at 6:30 PM, Hollis Blanchard wrote:
On Thu, 2006-06-08 at 22:10 +0000, Xen patchbot-xenppc-unstable
wrote:
[ppc] some OF implementations do not take kindly to closing
console ihandles.
Not closing stdin/stdout has caused real bugs with Linux on
pSeries.
I thought that was a pmac problem, but I see from linux that it
is indeed a pSeries problem
Not closing stdin/stdout has caused real bugs with Linux on
pSeries.
After much hair loss, it was discovered that a USB controller
was DMAing
over kernel memory in very very early boot, which doesn't sound
like a
problem I'd like to debug, so I don't like this patch.
Can we create a platform blacklist for this logic?
We don't have a concept of platform yet, so we are just maple
and JS2x and this patch is sufficient, and tested.
prom_init.c suggests that it is safe to always close stdin for
these platforms so I'll put the close back in.
agreed?
Maria, is that ok with you?
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home