From Bugzilla Helper: User-Agent: Mozilla/4.75 [ja] (WinNT; U) Description of problem: Many insmod and rmmod qla1280 driver causes hanging up of system. We discovered it on "shutdown and reboot" test. We have qla12160, on kernel 2.4.3-12smp. How reproducible: Sometimes Steps to Reproduce: 1.Make shellscript like below: #!/bin/sh while [ 1 ]; do insmod qla1280 if [ $? != 0 ]; then exit 1 fi rmmod qla1280 if [ $? != 0 ]; then exit 1 fi done 2.Run it. 3.Wait for 24 hr or so. Very rare case, but you must see this. Actual Results: Stopped at the message below: Loading qla1280 module qla1x160:Surported Device Found VIO=1077 DID=1216 SSVID=1077 SSDID=7 SCSI(0)=Determing if RISC is loaded ... SCSI(0)=Verifying chip.... Expected Results: The shellscript works good forever. Additional info: The stopped function is in qla1280_debounce_register() called from qla_chip_diag(). do { ret = RD_REG_WORD(addr); ret2 = RD_REG_WORD(addr); } while (ret != ret2); This might be infinite loop. So, we guess this is just a issue of read/write register timing. if we add usleep() function into this loop, the problem won't appear no more. And more, if we compile the module without -O2 switch, hard to reproduce it. We can see this issue on both up/smp kernel.
We confirmed that the qla1280 driver which we patched cleared the test of insmod/rmmod loop for 48hours. The patch is very easy and sily, just add the lines which contain routine similar to usleep(), into qla1280_chip_diag() function. We suppose this is just a timing issue. Writing/reading data to/from chip, the driver must wait until the chip is ready.
This bug appears to be slightly different. The qla1280 driver does not use the ioremap() and readl()/writel() functions but tries to access PCI space directly, bypassing the architecture access functions. This breaks on IA64 in subtle ways due to caching/bursting effects of the PCI controller (which is a good thing in itself, but only if you use the proper access methods)
7.1 ia64 is no longer supported. Closing