Nullmodem console error with Pegasos 2 <-> EFIKA

[ironfist]

Hi all,
Has anyone else experienced that the serial output from the EFIKA looks
like a mess in Minicom? I sent an e-mail to Genesi and was told that this
is a bug in kernel 2.6.17. I compiled the latest 2.6.19-r1 and still had the
same problem.

Then I tried an old 2.6.16-r13 kernel and then everything looked fine.

I also tried my Ultra1 with 9600 and on that one 2.6.19-r1 worked.

So, running Minicom on my Pegasos 2 with Gentoo-sources:
* 2.6.18-r1 and 2.6.19-r1 to my EFIKA in 115200 8N1 is just a mess
* 2.6.19-r1 in 9600 8N1 works just fine to my Sun Ultra1.
* 2.6.16-r13 worked with 15200 8N1 to my EFIKA.

Does anyone have any idea where the bug is and how to fix it?
It's pretty annoying..

[ironfist]

??

Are all you developers running old 2.6.16 kernels?

[JoseJX]

Well, I wasn't given an Efika, but I have no problem with an ML403 and minicom at those speeds on my PowerBook using a USB->Serial adaptor. Did Genesi give you a link to more info on the bug? Does it happen using other serial terminals?
_________________
Gentoo PPC FAQ: http://www.gentoo.org/doc/en/gentoo-ppc-faq.xml

[ironfist]

JoseJX:
Thanks for your reply.

I tried both CuteCOM and GTK-Term, but I could not get any
output in those clients. I tried both ttyS0 and ttyS1 on my
Pegasos. Minicom is the only one where I get output.

I didn't get any more information from Genesi than this;

"This looks like a "normal" bug introduced in recent Linux
kernel (2.6.17 and +). The serial port seems mess up
with the debug output console and then there are two
or more "entity" dealing at the same time with the it.
This ends ups in a big mess." /Nicolas DET.

[nixnut]

How about good old screen?
screen -m -c /dev/null /dev/ttyS0 115200 8N1
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

talk is cheap. supply exceeds demand

[ironfist]

Screen gives the same output. It's definitely a
kernel problem that needs to be addressed..

[JoseJX]

Well, if it changed between 2.6.16 and 2.6.17, could you do a git bisect and figure out where it broke so we can fix it?
_________________
Gentoo PPC FAQ: http://www.gentoo.org/doc/en/gentoo-ppc-faq.xml

[ironfist]

I would be happy to help, but I don't really understand
how git works or what it does.

I read these:
How To Use git-bisect To Isolate a Bogus Commit
Using git bisect to locate bugs in sbcl

[JoseJX]

Okay, so it's simple to do, just time consuming. :)

Basically, you're checking out the version of the kernel where you started to have a problem with the source code revision tool "git". You then tell git which version was the last that worked well. It chugs for a while and then tells you which patch is in the middle of these two. Test the kernel compiled from that and see if the problem remains. You'll then tell git if it worked, and based on your input will divide the remaining patches between your working kernel and the non-working kernel again. Continue doing this until git tells you that it found the patch that causes the problem.
_________________
Gentoo PPC FAQ: http://www.gentoo.org/doc/en/gentoo-ppc-faq.xml

[amne]

edit:
never mind, don't post when you're tired.
_________________
Dinosaur week! (Ok, this thread is so last week)