WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] [xenppc-unstable] [ppc] some OF implementations do not take

I vote against 2. Beside myself, who else has run xen on js20? Michal has requested a better version of slof for js20. Let's wait to test on that.
Jimi Xenidis wrote:
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