Port-macppc archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MacPPC serial ports in 4.0.1 - not quite
Oddly enough, what I did in the Cyclades driver was to add a call to
the interrupt handler every time it made a trip through the
"top half" polling loop.
It didn't fix the interrupts, but it got the job done.
On the 4.0.1 machine,
I can set up an account on the machine for debugging,
or run some tests, w/ extra debug code on the machine in
question if that is helpful. I would need a patch or at least
some pointers on what debug code would be required. It's a
production machine, but I can "mess with it" at will because all
it does is monitor the other machines, so its operation is
not critical.
-dgl-
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hello,
>
>On Dec 30, 2008, at 1:38 AM, der Mouse wrote:
>
>> It's reminiscent of my own experiences with macppc serial; I found that
>> if I used the serial line for anything substantial it would wedge in
>> some way. That machine seems to have stopped working, though, and for
>> the next week I'm in the wrong city to investigate. My macppc issues
>> were with 1.4T, which seems to point towards it being something very
>> long-standing.
>
>Pre-4.0 macppc had completely hosed interrupt handling. It would lose
>interrupts left and right, level-triggered interrupts didn't really work at
>all, edge-triggered ones ( like serial ports ) were likely to get stuck under
>heavy load.
>
>Donald's G3 uses a Heathrow PIC, basically two old style PICs glued together
>to allow 64 IRQ lines. For the serial ports it shouldn't make any difference,
>only the onboard ethernet controller and some other device I forgot about uses
>IRQs >31, the serial ports are where they used to be on Grand Central and the
>likes.
>What I'd suggest is to have a look at arch/macppc/macppc/pic_heathrow.c and
>add some debug code that checks wether edge-triggered interrupts get properly
>dealt with. These old PICs are prone to lose interrupts, if you disable one,
>it fires and then you re-enable it you won't get an interrupt. So what we do
>is to check the appropriate registers when enabling an interrupt and mark it
>pending if we find it already active. This seems to work fine for almost
>everyone but in this case that's still the first place I'd look at.
>
>have fun
>Michael
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.7 (Darwin)
>
>iQEVAwUBSVpDqMpnzkX8Yg2nAQIZNAf8DH0M5wS8HF+D7OhaV36fcFdPpW8ic88y
>D3qkMjgW2lqXX53/xtHplu3yBTq/91dKZ4RhN/uLhPj5xGsLMMj7J+4+VEHNT4NP
>QLRUM0t94Mpzd9TLUsLAGTIAuGM5DRgCV/v8cNA/ayiICg1Yz0c8axX5uNSnzhre
>/i43hdgr0fLED4fun3mFbzuIxu0LTNK3d0AhK3X+Zk5aNGuim+QMNaXupHIEADaj
>dIv9xi4PejbliK0VvLbznG5sJSBWIa6XMWxfZVMJo8V92dXPSbfNonxwwr2ya8TE
>uOuTlQFbo5XtEGf1uKGZfT9qaIMk6NdS76ncMYnMrIetFPvoljUJGw==
>=Gn5l
>-----END PGP SIGNATURE-----
Home |
Main Index |
Thread Index |
Old Index