Re: buildd macs, was Re: [buildd] Etch?
On Mon, 14 Aug 2006, Michael Schmitz wrote:
> > > it used to be the case that half of them were macs, but this time is
> > > past, there are "only" five: 2 840AV, 2 Quadra 950, one Quadra 650.
> > > For experimental, I have one more Quadra 950 and a Centris 650.
> >
> > Well, it's not pretty, but I can give you advance warning of the
> > issues on those machines.
> >
> > 650: No real time clock or serial drivers. Broken MacII ADB driver.
>
> Not sure the RTC ever worked, but the serial drivers used to.
RTC used to work in 2.2. The m68k repo tells me that it was deliberately
left in a broken state (because of ADB breakage? build failure?). I'm sure
it can be made to work on those models that have working ADB. Just needs
someone to find the time (no pun intended). Recently upstream has a new
RTC API that will probably need to be adopted too.
> I've ported the Atari SCC serial driver to 2.4 last year, and submitted
> patches to linux-m68k. The Mac serial driver is based on the same SCC
> chip, so it should be possible to use that patch as a starting point.
>
> What's broken with the ADB driver? Interrupts, or generic ADB comms
> trouble? I didn't follow the driver rewrites, but MacII ADB is a simple
> braindead state machine and should even work in polling mode.
I've done some investigation but haven't made a lot of progress so far.
What I found was that the two kinds of crashes were caused by either
calling an invalid call back pointer in the adb_request struct, or
dereferencing an invalid buffer pointer in the same struct. Many of these
adb_request structs are allocated on the stack. Maybe they are being used
after being freed. Maybe they are being clobbered accidentally by the
MacII driver itself. The fact CUDA ADB doesn't crash doesn't mean it
doesn't have the same problem, since the bug is timing sensitive. The
speed of the machine (Q700 vs Q650), or the presence of a few extra if
statements, can make the difference between immediate crash and waiting a
few minutes or hours. And if it doesn't crash, it does detect the mouse
and keyboard, but they don't function. So I think this could actually be
two bugs, one of which may be related to VIA timing.
I've tried a few different approaches to debugging this, like reverting
changes made to the mac68k ancestors, comparing it to the CUDA ADB driver,
adding overflow checks and tracking stack-based struct pointers, but it is
slow going. I'll probably try capturing some ADB traffic. And stare at the
code more.
It appears that there is no way to collect a crash dump on this arch :-(
I hope to do some more work on this when I get back to Melbourne in a
couple of weeks.
> Can the ADB code be modularized
>
> > 840av: No real time clock or serial drivers.
> > 9x0: Hard to say (I don't have any). Certainly no RTC.
> >
> > The workaround for the RTC is ntpd and tune2fs.
>
> ntpd/ntpdate is what I've used in q650 from day one.
It seems that the filesystem checks run before ntpdate, so you need to
disable the last-mount timestamp test that fsck does. You can find this in
the list archives, but here is the workaround again anyway:
tune2fs -i 0 /dev/sdaN
> > The 650's onboard ethernet needs the SONIC driver enabled in the
> > kernel config. Avoid ethernet cards unless SONIC (DP83932) based. Last
> > I checked SONIC was not enabled in the debian config due to build
> > problems, but it can be enabled now.
>
> That's good to know. If I can pull q650 off duty, I could use it to debug
> the ADB driver that way.
Personally, I'm curious to see what happens when you boot a Q9x0 with a
kernel having no IOP ADB driver. I don't have a Q9x0 to try that, and the
debian kernels all have IOP ADB (I guess that is because it works on the
IIfx).
-f
>
> Michael
>
Reply to: