I've proven that on boot, as a module, the aic7xxx_mod (new driver) oopses the kernel on SMP alpha and not uniprocessor alpha. The older aic7xxx driver continues to fuction normally for SMP and UNIP Alpha's. This looks identical to http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=32041 This is not a HW problem (I've since discounted that) Code: f440000a bge t1,.+44 a02a01e0 x y a46a01e8 x y 219f0002 x y 482050c1 x y 40610403 x y *2c430000 x y 484300c2 x y Trace:8161b4 8172a4 825ee4 817af8 810c38 8128b0 82a900 812890 810044 853d3c 810e48 8543dc 82f524 82f548 (I'd to scribble that down,.. no save to disk thank you very much 8/ ) Which yields this 8161b4 - handle_IRQ_event 8172a4 - handle_irq 825ee4 - dp264_srm_device_interrupt 817af8 - do_entInt 810c38 - ret_from_sys_call 8128b0 - cpu_idle 82a900 - do_check_pgt_cache 812890 - cpu_idle 810044 - __smp_callin 853d3c - kmem_cache_grow 810e48 - ret_from_smp_fork 8543dc - kmem_cache_alloc 82f524 - do_fork 82f548 - do_fork which is identical to the old bug report which at this time I'll have to say was a big bogus because I'd too many things going on similtanously to make a good bug report. As the older driver *does* still work, and as you're probably under time pressure would the recommendation be (at this time) to simply go with the older driver and leave the newer one for harsher scruteny in a couple of weeks time? Phil =--=
This looks like something I've recently fixed. The past driver releases have been a bit lax in ensuring that they don't generate interrupts until the driver is fully setup. I still have to test the code on my EISA box (will do so today) and the code should be released in 6.1.8 of the aic7xxx driver.
Merged 6.1.11