[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 


> 	Michael

Reply to: