Created attachment 327100 [details] Full dmesg with modprobe -r arcmsr && modprobe arcmsr I'm running gentoo as a VM in VMware ESXi 5.0u1 with sys-kernel/hardened-sources-3.6.2. I configured my RAID HBA (Areca 1120) as exclusive passthrough device for this VM. Booting hangs with a little delay when loading the arcmsr module but it seems to get loaded eventually. lsmod confirms it is loaded, however no blockdevice is showing up. modprobe -r arcmsr && modprobe arcmsr is the only way to make the blockdevices show up. dmesg shows "arcmsr2: wait 'get adapter firmware miscellaneous data' timeout" on boottime. this doesnt happen when loading the module at later time. I haven't testet if vanilla or the normal sources have this regression too. This also happens with kernel 3.5 and 3.4, didn't test others. This issue derived from my forum post here: http://forums.gentoo.org/viewtopic.php?p=7167816 This is my first bug report so please don't be too hard on me, i probably did something wrong.
Created attachment 327102 [details] lsmod after boot
Created attachment 327104 [details] lsmod after modprobe -r && modprobe
You mentioned this would be a regression, so I assume you mean it didn't happen before, then do you know for which kernel version this still worked? The freeze should be about 20 seconds according to the function called from the if that you can find on https://patchwork.kernel.org/patch/75997/ this function can be found in drivers/scsi/arcmsr/arcmsr_hba.c: static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock *acb) { struct MessageUnit_A __iomem *reg = acb->pmuA; int i; for (i = 0; i < 2000; i++) { if (readl(®->outbound_intstatus) & ARCMSR_MU_OUTBOUND_MESSAGE0_INT) { writel(ARCMSR_MU_OUTBOUND_MESSAGE0_INT, ®->outbound_intstatus); return true; } msleep(10); } /* max 20 seconds */ return false; } This function (which has a hbb equivalent, this one is hba) waits for outbound / message0 to be initialized and thus probably waits till the firmware has done initializing miscellaneous data. As this only happens in the kernel and not when you try to load it again later might have to do something with that you are perhaps loading firmware differently or its waiting for *something* to complete. So, first make sure you have emerged the right firmware and whether you need to explicitly include it in your kernel (or whether firmware is actually being included in your kernel at all). So, it would be handy if you: 1. Find (or mention and test) a kernel for which this still worked, find the subsequent first version that is broken. 2. Check whether you have the firmware and whether firmware related options in the kernel are correct. 3. After step 3, try to boot with the following kernel options so we can see the first part of the dmesg as well as more details: initcall_debug printk.time=y debug ignore_loglevel
Created attachment 327180 [details] debug dmesg in advance, heres the debug dmesg. ill check with what kernels this doesnt happen. i don't think that this controller needs a firmware in kernel. i havent found anything about that in source either
I'm sorry i was confused about the meaning of the word regression, I think this didn't work for me ever. i tested hardened (3.6.4), vanilla and gentoo sources, happened with every kernel i tried, tested the last few major releases back. (till 3.0) i still don't know anything about a firmware or wether i need one. how can i find that out? i don't think i need some firmware if it loads after the system fully booted up. to rule out missconfiguration on my (gentoo) end: this thing also happens with gentoo minimal livecd. delay on boot when loading arcmsr and no blockdevice ever shows up
Okay, re-assigned the bug because this has nothing to do with hardened then. [ 5.794552] calling arcmsr_module_init+0x0/0x1a [arcmsr] @ 5604 [ 51.251758] arcmsr2: wait 'get adapter firmware miscellaneous data' timeout1 [ 51.252583] initcall arcmsr_module_init+0x0/0x1a [arcmsr] returned 0 after 44461982 usecs Okay, that didn't yield us more information. A temporary workaround could be to not let the kernel automatically load the module (disable autoload on it by removing it from /etc/modules.autoload.d/kernel-<your kernel version>) and instead use something like an initscript that modprobes it instead. You could then change the runlevels and dependencies in a way that this modprobe doesn't stall your boot. Can you report your bug upstream at http://bugzilla.kernel.org and leave a link to your upstream bug here for reference?
