On Sat, 27 Sep 2008, Michael Schmitz wrote: > > mac_scsi actually works (once I fixed the > > enable_irq-before-request_irq bug -- already fixed in various other > > NCR5380 wrapper drivers ... sigh) but it only works in PIO mode. The > > PDMA read routine causes a bus error (The Guide to Mac Family Hardware > > says "if a read or write operation over the SCSI bus is not completed > > within certain time (different for different machines), the general > > logic IC asserts a bus error (/BERR) to the CPU.") The driver tries to > > fall back to PIO mode when that happens. > > The bus error is caught OK by the PDMA function? Yes. Here's a log where the PB 190 booted to login prompt. This kernel had PDMA enabled, and you can see that the fallback to PIO worked in this instance, http://marc.info/?l=linux-m68k&m=121930677128486&w=2 Note that the sector size response was screwed up. That happens sometimes. It could be related to the other problem I mentioned -- > > The fall back succeeds only on the powerbook 190 and only if the code > > was compiled with gcc-3. It just hangs on the PB 150 and Mac II, > > though PIO works on those machines too when PDMA is disabled. So I > > think there's a race there somewhere. And PIO doesn't work anywhere > > once debugging printks are enabled. > > I've worked around that in the past by hooking into the Mac level 7 > interrupt, listing the driver state from the NMI post-mortem. (Actually > I did that on the old Mac ESP driver, but the same sort of hack should > apply. ESP was a lot more debug friendly though ...) OK. But PIO shouldn't be timing sensitive, right? Anyway, I don't want to get sidetracked with PIO.. unless there are macs that can't do PDMA. > > All of which gives me little confidence in NCR5380.c. > > > > (I tested those 3 machines because they have the 3 different kinds of > > VIA2. Logs can be found here > > <http://www.telegraphics.com.au/~fthain/mac_scsi_logs/> should anyone > > want to see them.) > > Looks like a race with the ADB interrupt to me. Well, I know Mac interrupt handling used to be flaky, but that's all fixed now. Anyway, I did some tests using the adb_sync parameter, to prevent the background ADB probe task, and I get the same results (you can find some new logs at the same URL). > In the second Mac II gcc4 case, it even seems to fail to add the target > to the disconnect queue. I dunno why. I haven't seen that happen before or since. > What are these unknown interrupts? DRQ? PDMA stalling? The schematics say that only the NCR5380 drives that VIA input (VIA2 CB2 aka IRQ_MAC_SCSI), so IRQ 19 is definitely the IRQ line from the chip (and not the DRQ line). The DRQ interrupt was/is never registered (BTW, I found that it doesn't fire on one of the PowerBooks). Anyway, it probably isn't PDMA related since that was disabled (#undef PSEUDO_DMA). BASR 0x18 would indicate "IRQ active" and "phase match"... I haven't read enough of the datasheet to know what that combination means. > > There is so much duplication of code for the NCR5380 drivers -- sun3, > > atari, g_NCR5380, 2.4 & 2.2 branches in the mac68k CVS -- that I don't > > know where to start looking for fixes. > > The Mac driver originated from the Atari one, but I haven't done more > than the absolute minimum in fixes to keep that one alive. There are some mac_scsi.c/NCR5380.c fixes in the mac68k CVS, but it is hard to know whether they are relevant to atari_NCR5380.c... http://linux-mac68k.cvs.sourceforge.net/linux-mac68k/linux-mac68k/drivers/scsi/NCR53C9x.c?view=log&pathrev=MAIN http://linux-mac68k.cvs.sourceforge.net/linux-mac68k/linux-mac68k/drivers/scsi/NCR53C9x.c?view=log&pathrev=linux-2_2 > > > Thinking that the bug would be trivial, I started out writing cleanup > > patches for the existing mac_scsi.c/NCR5380.c combination. But the > > more I think about it, the less I want to go in that direction. > > > > Now I'm thinking that mac_scsi should adopt the atari core, since that > > appears to be the better maintained contender. Michael, does that > > sound sensible? Does it have working PDMA? > > Atari uses real DMA. When I adapted it for Mac, I added PIO and that did > work fine (slowish, but OK). Must have been in the 2.2 kernel series, > more than 10 years ago, so it may not work in the driver's current > state. I can test that if you need to. Thanks. I don't know if PIO will be needed though? > Better maintained ... I strongly doubt it. It still works in the regular > case, but I haven't pushed it hard enough to test whether my 2.6 error > handling changes still work today. > > > Another thing, should we look at merging sun3_NCR5380.c and > > atari_NCR5380.c? The diff is huge, but that is because of the code > > style and formatting cleanups in atari_NCR5380.c. The functional > > differencess are few and far between. > > In order to avoid duplication maintenance effort, we should merge those > if it is at all possible. I didn't write the Atari code, and my > discussions with the author were so long ago I have trouble remembering > the details. Much of the peculiar things in the Atari driver result from > the fact that the SCSI chip hangs quite frequently on Atari (hardware > issue), and the command in-flight may not be in any of the queues if > that happens (or so a comment in the code claims; I think I fixed the > most glaring case a while ago). Maybe we can let the error handler clean > up after these hangs now; changes since 2.2 in locking and error > handling have been simplifying things enormously after all. > One implication for a creating a shared driver core is that it rules out #ifdef CONFIG_ATARI if we want "make allyesconfig" to work and give complete code coverage. We'd have to have run-time conditionals for hardware bugs. I will see what can be done about merging sun3_NCR5380.c with atari_NCR5380.c. Finn -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
