Hi, this afternoon I attempted to upgrade NetBSD from 7.1_STABLE to 8.0_BETA on an amd64-running machine in our lab. It has an aac controller, probed like so:
aac0 at pci6 dev 0 function 0: IBM ServeRAID 8k aac0: interrupting at ioapic0 pin 17 aac0: Enabling 64-bit address support aac0: Enable 64-bit array support aac0: New comm. interface enabled aac0: MIPS 5KC at 250MHz, 32MB mem (16MB cache), optional battery not installed ld0 at aac0 unit 0: RAID 1 (Mirror) ld0: 232 GB, 30378 cyl, 255 head, 63 sec, 512 bytes/sect x 488036352 sectors ld1 at aac0 unit 1: RAID 10 ld1: 465 GB, 60757 cyl, 255 head, 63 sec, 512 bytes/sect x 976072704 sectors Apparently, somewhere between those two kernel versions, the 'ld' driver was MPified, while the aac driver was not. The symptom I noticed this with was that I managed to unpack the 'base' set from the 8.0_BETA build, but 29% into the 'comp' set, the machine decided to panic with a rather mysterious null pointer de-reference inside the aac driver, pointing (by the looks of it) to the SIMPLEQ_FIRST macro use inside aac_ccb_enqueue(). By this time I had a machine with an 8-based user-land but with a brittle 8 kernel, and of course the 7-based kernel doesn't want anything to do with the 8-based ifconfig, so by the looks of it, the machine is going to need me to physically visit it to rescue it out of this bind, even though I have remote serial console. I don't know the MPify-state for the other sub-drivers under 'ld' (I see aac, cac, icp, mlx and nvme), but this should probably get some proper attention before 8.0 is released... And, I have it on good authority that simply replacing splbio() / splx() with mutex_enter() / mutex_exit() isn't going to work, because there are a number of things which are not permitted in a mutex-based critical section which are perfectly fine in an splbio()-protected section, such as doing malloc(), using bus_* functions etc. etc. So the conversion is decidedly not trivial, and certainly above my current skill level. So, "Help!" Regards, - HÃ¥vard