Re: buildd macs, was Re: [buildd] Etch?
> > 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
The RTC hangs off the ADB or ADB-VIA, so thats the reason, perhaps.
> 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.
As soon as it's working again...
> > 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
I used to have such a stupid bug introduced into the driver initially
myself (callback data allocated on the stack instead of statically). If
the request didn't complete in one go of the interrupt handler you would
eventually crash. Reentering the handler might also be an issue.
> 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
Yep, the above bug didn't really show on every boot either.
> 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.
The keyboard and mouse not functioning means the driver likely fails to
poll the last active device, or fails to recognize devices signaling a
SRQ. IIRC the Mac II ADB design does not implement autopolling, so you
have to query the last active device repeatedly to keep the bus alive (SRQ
can only be signaled if there is activity on the bus). Maybe better to
just poll all detected devices in turn :-)
> 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 :-(
Not at this early stage in booting. You'd really need to delay ADB init
until after syslogd starting :-) Dumping state information from the ADB in
handler is what I did to figure out what happened. Have fun :-)
> > 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
I'll keep that in mind, thanks.
Michael
Reply to: