Bug 231699
Summary: | Problem with Adaptec AHA-2940U2/U2W module | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Wil Harris <mosinu> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7 | CC: | chris.brown |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-01-09 00:11:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Wil Harris
2007-03-10 08:24:50 UTC
Problem still exists with 2.6.20(2933). Appears like aic7xxx driver isn't creating my scsi devices on boot. Trying to mount the drives or fsck them after the system is up and running results in an error that /dev/sda1 doesn't exist. Still works with 2.6.18(2869). Problem persists into Fedora 7. Turning off parity checks in the adapter results in the drives showing up, but with no partition tables and not able to hold any partition information (eg fdisk the drive, partition it, exit, fdisk -l...no partition). Install any of the 2.6.18 kernels and reenable parity checking and problem goes away. Hello Will, I'm reviewing this bug as part of the kernel bug triage project. http://fedoraproject.org/wiki/KernelBugTriage You might want to try some of the following: # For boot related issues we need as much info as possible, so removing quiet from the boot flags should be the first thing to ask for. # Slowing down the speed of text output with boot_delay=1000 (the number may need to be tweaked higher/lower to suit) may allow the user to take a digital camera photo of the last thing on screen. # Booting with vga=791 (or even just vga=1 if the video card won't support 791) will put the framebuffer into high resolution mode to get more lines of text on screen, allowing more context for bug analysis. # initcall_debug will allow to see the last thing the kernel tried to initialise before it hung. # There are numerous switches that change which at times have proven to be useful to diagnose failures by disabling various features. * acpi=off is a big hammer, and if that works, narrowing down by trying pci=noacpi instead may yield clues * nolapic and noapic are sometimes useful * Given it's new and still seeing quite a few changes, nohz=off may be worth testing. (Though this is F7 and above only) # If you get no output at all from the kernel, sometimes booting with earlyprintk=vga can sometimes yield something of interest. # If the kernel locks up with a 'soft lockup' report, booting with nosoftlockup will disable this check allowing booting to continue. As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. |