On Monday 20 April 2009, Ingo Molnar wrote: > The proper approach would be to use one of the async_synchronize*() > facilities in kernel/async.c to properly order the opening of the > console with device init. Stepping back a moment from "how" to make sure "what" is agreed on. I think I see three scenarios here: - Classic PC or server, where there's a meaningful console; - Deeply embedded systems, where there isn't; - Development stages of "deeply embedded", where there *may* be one. If that's correct, then async_synchronize() isn't a full answer... I think a fair number of cases can be papered over with a serial console with no hardware flow control, which isn't hooked up to anything. Maybe the board needs a test/development jig to get one; without it, the "console" bits spill out into the aether. Linux can dump bits to ttyS0, which will act like /dev/null. But the problem case here seems to be one where such un-hooked-up serial ports are not realistic options. Which is why the regression in USB console functionality has been troublesome. Is that correct? - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html