Summary: | sys-kernel/*-sources - arcmsr2: wait 'get adapter firmware miscellaneous data' timeout1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SigHunter <sighunter> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | linux-bugzilla-pending | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
Full dmesg with modprobe -r arcmsr && modprobe arcmsr
lsmod after boot lsmod after modprobe -r && modprobe debug dmesg |
Description
SigHunter
2012-10-21 20:43:17 UTC
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? |