* Ming Lei <tom.leiming@xxxxxxxxx> [081103 04:59]: > 2008/11/3 Tony Lindgren <tony@xxxxxxxxxxx>: > > * David Brownell <david-b@xxxxxxxxxxx> [081102 11:26]: > >> On Sunday 02 November 2008, Rick Bronson wrote: > >> > > Is that what you saw too? > >> > > >> > Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that > >> > I had nothing except "Uncompressing Linux........". > >> > >> I don't have DEBUG_LL=y ... if you had some kind of network > >> link configured over USB, could you SSH in? (I can.) > >> > >> > >> > I guess we don't see this problem on the other 2 ports since they > >> > are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS). > >> > >> Hmm, inconsistency is to be avoided. :) > >> > >> I wonder what the root cause is ... is the driver missing > >> various barriers needed to make MT_DEVICE work? Or is the > >> MT_DEVICE incorrect in the first place? "git whatchanged" > >> didn't show any recent changes that seemed (on a quick > >> glance) to affect I/O at that level. Maybe it was one of > >> the other TTY changes interacting here. > > > > Yeah I don't know what may have changed, or have things just > > gotten faster now with cortex since 2.6.27? > > > > Anyways, this patch fixes the issue for me without marking > > things strongly ordered. Rick, does this work for you? > > This patch still works for me. > Thanks! Well the real problem has been found, there's a bug with the recent ptebits patches, which causes section mappings to be just MT_MEMORY instead of MT_DEVICE.. So let's put things on hold until we have a real fix for that on the linux-arm-kernel mailing list, hopefully today. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
