On 09/07/10 14:12, Konrad Rzeszutek Wilk wrote: > On Monday 30 August 2010 07:13:17 Boaz Harrosh wrote: >> On 08/23/2010 10:59 PM, Jiri Slaby wrote: >>> Hi, >>> >>> I see that the aha152x driver for pcmcia is marked as unsupported on >>> 64bit. But I also see a patch [1] which removes the restriction based on >>> user's testing in bugzilla [2]. >>> >>> Is there a reason why it would have to be marked as !64BIT? I'm asking >>> because there is an opensuse user with this card who updated to 64-bit >>> distro and lost this driver thereafter. >>> >>> [1] http://kerneltrap.org/mailarchive/linux-scsi/2010/3/6/6832393 >>> [2] https://bugzilla.kernel.org/show_bug.cgi?id=14333 >>> >>> thanks, >> >> If memory serves correctly, it might be that you need more then 4 Gbyte >> of memory installed to exercise the bug, something about IO bouncing >> addresses > 4G. > > If the machine is using SWIOTLB, then the bounce buffer would be activated. By > default if your machine has more than 4GB compiled under x86_64 the SWIOTLB > is turned on - but if you have an Intel/AMD IOMMU it gets turned off. Which > is OK as the Intel/AMD IOMMUs would handle the 4GB restricted devices. So as > long as the driver has pci_dma_mask_set. > > Looking at the git gui blame tool history, the reason that was added was > for 'allow drivers to be built non-modular'. 023ae619 (Robert P. J. Day 2007-03-26 16:06:45 -0400 14) depends on !64BIT That commit just removed the "depends on m" part: - depends on m && !64BIT + depends on !64BIT > So, does this driver build if you make it non-modular? It shouldn't since it still depends on !64BIT. I expect someone thought or had evidence that the driver was not 64-bit clean. Is the bitkeeper kernel repo still visible somewhere? Looks like we would need to look at it for patch history that far back. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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
